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

RE: The CIF BNF

• 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
-------------------------
loop_
    _atom_identity_node
    _atom_identity_symbol
loop_
    _atom_bond_node_1
    _atom_bond_node_2
    _atom_bond_order
    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
-------------------------
loop_
    _atom_identity_node
    _atom_identity_symbol
    loop_
        _atom_bond_node_1
        _atom_bond_node_2
        _atom_bond_order
    stop_

    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

    A7 B7
        4 5 dou
        stop_

    A8 B8
        5 6 sin
        stop_

    A9 B9
        7 8 sin
        stop_
-------------------------

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.

cheers

Nick

--------------------------------
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]

• Prev by Date: Brian T's queries
• Next by Date: Re: Powder CIF Proposals
• Prev by thread: RE: The CIF BNF
• Next by thread: Two-dimensional chemical structure diagrams
• Index(es):
  • Date
  • Thread