Discussion List Archives

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

Re: [ddlm-group] CIF-2 changes

The move away from [] lists to {} lists (thus overlapping with {}
associative arrays) had to do with cleaning up the syntax under CIF-2.

There are legacy issues with existing CIF data names with embedded [] which
meant that using [ to initiate a list would come unstuck.

Accordingly to simplify matters and to move forward, I proposed using {} to
define lists or associative arrays. The complication to the parser is that
you must start to look inside the object to determine which it is.

That is CIF. dREL is a different matter but consistency is a good thing, so
that it makes sense to keep the syntax the same as a CIF data file. Hence
your transcription of the dREL code is correct. It makes my work a lot more
difficult of course because until now I just called up a Python parser to
handle almost all of dREL.

Such is life.


On 25/10/09 10:24 PM, "Herbert J. Bernstein" <yaya@bernstein-plus-sons.com>
wrote:

> Dear Colleagues,
> 
>    Please take a look at the dictionaries I have drafted at
> 
>    http://vcif.sf.net/cif2_dicts
> 
> and tell me if I am on the right track in trying to convert to CIF-2
> format dictionaries.  I have taken all the August 2008 () style tuples in
> the upper level and converted them to October 2009 CIF-2 {} style lists.
> I have not changed any array dimension specifications, e.g. [*], nor the
> innards of any methods.
> 
>    Questions:
> 
>    1.  Should the dimensions be changed, e.g. from [3] to {3}?
>    2.  Should there be any changes in dREL methods themselves?
> 
> For example consider:
> 
> ======
> save_function.SymEquiv
>      _definition.id              'function.SymEquiv'
>      _definition.update           2007-10-11
>      _description.text
> ;
>       The function
>                       xyz' =  SymEquiv( symop, symcat, xyz )
> 
>       returns a fractional coordinate vector xyz' which is input vector
>       xyz transformed by the input symop 'n_pqr' applied to the symmetry
>       equivalent matrix extracted from the category symcat.
> ;
>      _name.category_id            function
>      _name.object_id              SymEquiv
>      _type.purpose                Assigned
>      _type.container              Array
>      _type.contents               Real
>      _type.dimension              [3]
>       loop_
>      _method.purpose
>      _method.expression
>       Evaluation
> ;
>       Function SymEquiv( c :[Single, Symop],    # symop string n_pqr
>                          l :[Category, Tag],    # loop of symmetry matrices
>                          x :[Array, Real]    )  # fract coordinate vector
>       {
>               s = l [ SymKey( c ) ]
> 
>               SymEquiv = s.R * x + s.T + SymLat( c )
>       }
> ;
>      save_
> ======
> 
> Should that remain the same, or should it be as follows
> 
> ======
> save_function.SymEquiv
>      _definition.id              'function.SymEquiv'
>      _definition.update           2007-10-11
>      _description.text
> ;
>       The function
>                       xyz' =  SymEquiv( symop, symcat, xyz )
> 
>       returns a fractional coordinate vector xyz' which is input vector
>       xyz transformed by the input symop 'n_pqr' applied to the symmetry
>       equivalent matrix extracted from the category symcat.
> ;
>      _name.category_id            function
>      _name.object_id              SymEquiv
>      _type.purpose                Assigned
>      _type.container              Array
>      _type.contents               Real
>      _type.dimension              {3}
>       loop_
>      _method.purpose
>      _method.expression
>       Evaluation
> ;
>       Function SymEquiv( c :{Single, Symop},    # symop string n_pqr
>                          l :{Category, Tag},    # loop of symmetry matrices
>                          x :{Array, Real}    )  # fract coordinate vector
>       {
>               s = l { SymKey( c ) }
> 
>               SymEquiv = s.R * x + s.T + SymLat( c )
>       }
> ;
>      save_
> ======
> 
> Regards,
>    Herbert
> 
> 
> =====================================================
>   Herbert J. Bernstein, Professor of Computer Science
>     Dowling College, Kramer Science Center, KSC 121
>          Idle Hour Blvd, Oakdale, NY, 11769
> 
>                   +1-631-244-3035
>                   yaya@dowling.edu
> =====================================================
> 
> _______________________________________________
> ddlm-group mailing list
> ddlm-group@iucr.org
> http://scripts.iucr.org/mailman/listinfo/ddlm-group

cheers

Nick

--------------------------------
Associate Professor N. Spadaccini, PhD
School of Computer Science & Software Engineering

The University of Western Australia    t: +61 (0)8 6488 3452
35 Stirling Highway                    f: +61 (0)8 6488 1089
CRAWLEY, Perth,  WA  6009 AUSTRALIA   w3: www.csse.uwa.edu.au/~nick
MBDP  M002

CRICOS Provider Code: 00126G

e: Nick.Spadaccini@uwa.edu.au




_______________________________________________
ddlm-group mailing list
ddlm-group@iucr.org
http://scripts.iucr.org/mailman/listinfo/ddlm-group

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.

Useful links