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