Discussion List Archives

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


  • Subject: RE: The CIF BNF
  • From: Nick Spadaccini <nick@xxxxxxxxxxxxx>
  • Date: Tue, 26 Sep 2000 05:15:23 +0100 (BST)
On Mon, 25 Sep 2000, ROBIN SHIRLEY (USER) wrote:

> That's not quite right: I actually said that, while I accepted that
> the *restriction* was arbitrary, in effect I endorsed the practical
> usefulness of *convention(s)* concerning line length (80 chars -
Sorry, my misinterpretation. Yes if we are talking about *conventions* of
practice then there should be some convenient number. But I don't see it
(and I believe you don't either) as formally part of a specification. Nor
should any *inconveniently* laid out CIF file be excluded. Any CIF can be
made *convenient* with a pretty printing application.

Perhaps the view to be put to COMCIF is to drop the 80 limit from the
specification and to emphasise a convenient convention would be try to
keep files within an X character record length, X to be agreed upon in
some way.

> Thus this would not be an issue that affected the programming of the
> *reading* of CIF files, which would need to cater for the maximum 
> line length (if any) allowed, but one of customary usage and hence 
> the programming of their *writing*, so as to be courteous to the 
> community of CIF users.

I must admit I tend to think in terms of *input* when I talk of these
things. The star_base software acts also as a pretty printer, and
restricts its output buffer to 512 chars. Its view of "courteous" output
is not so much a restricted record length, but it reads in the file,
determines all of the different data loop depths and sizes and then
outputs these such that data at the same loop level and packet appear
"together". This may exceed 80 characters, especially if you consider a
loop containing the CIF items, x, y, z, pop, Uijs etc.

Example - if this is what is input
    A1 B1 1  2 sin stop_
    A2 B2 1  6 dou 30 40 trip stop_
    A3 B3 1  7 sin stop_
    A4 B4 2  3 dou stop_
    A5 B5 3  4 sin stop_
    A6 B6 3 10 sin stop_
    A7 B7 4  5 dou stop_
    A8 B8 5  6 sin stop_
    A9 B9 7  8 sin stop_
this is what comes out as

    A1 B1
        1 2 sin

    A2 B2
        1 6 dou
        30 40 trip

    A3 B3
        1 7 sin

    A4 B4
        2 3 dou

    A5 B5
        3 4 sin

    A6 B6
        3 10 sin

    A7 B7
        4 5 dou

    A8 B8
        5 6 sin

    A9 B9
        7 8 sin

A consequence of its view of "pretty" is that you get a far greater number
of records (lines) but each is less wide. I appreciate that some may find
the original file layout far more appealing, but when you are dealing with
nested loops the layout adopted by star_base makes it easier to follow the
current nesting level, and data packet.



Dr Nick Spadaccini
Department of Computer Science              voice: +(61 8) 9380 3452
University of Western Australia               fax: +(61 8) 9380 1089
Nedlands, Perth,  WA  6907                 email: nick@cs.uwa.edu.au
AUSTRALIA                        web: http://www.cs.uwa.edu.au/~nick

Reply to: [list | sender only]
International Union of Crystallography

Scientific Union Member of the International Science Council (admitted 1947). Member of CODATA, the ISC Committee on Data. Partner with UNESCO, the United Nations Educational, Scientific and Cultural Organization in the International Year of Crystallography 2014.

International Science Council Scientific Freedom Policy

The IUCr observes the basic policy of non-discrimination and affirms the right and freedom of scientists to associate in international scientific activity without regard to such factors as ethnic origin, religion, citizenship, language, political stance, gender, sex or age, in accordance with the Statutes of the International Council for Science.