Discussion List Archives

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

Re: [ddlm-group] CIF-2 changes

Dear Coleagues,

   To make sure we are all on the same page, let's review the various 
containers in 2007, 2008, and 2008

   2007:
       Single 'a single value'
       Multiple 'values related by boolean ',|&!*' or range ":" ops'
       List 'list of values bounded by []; separated by commas'
       Array 'list of fixed length and dimension'
       Tuple 'immutable List bounded by (); nested tuples allowed'
       Table 'key:value elements bounded by {}; separated by commas'
       Implied 'implied by type.container of associated value

       imports are given as a list
             _import_list.id ['att','atom_site_label','com_att.dic']
       or as separate tags


   2008:

       Single 'a single value'
       Multiple 'values related by boolean ',|&!*' or range ":" ops'
       List 'list of values bounded by []; separated by commas'
       Array 'list of fixed length and dimension'
       Tuple 'immutable List bounded by (); nested tuples allowed'
       Table 'key:value elements bounded by {}; separated by commas'
       Implied 'implied by type.container of associated value'

       imports are given as a tuple
             _import_list.id (('Sta','units_code','com_val.dic'))

If I understand correctly, the new list will be

   2009:

       Single 'a single value'
       Multiple 'values related by boolean ',|&!*' or range ":" ops'
       List 'list of values bounded by {}; separated by commas'
       Array 'list of fixed length and dimension'
       Table 'list of key:value elements bounded by {};
          separated by commas'
       Implied 'implied by type.container of associated value'
       Tuple 'immutable List bounded by {}; nested

removing the term "Tuple", instead just referring to a list with
nesting as in

            _import_list.id {{'Sta','units_code','com_val.dic'}}

In other words -- everthing uses the list syntax.

Is this right?

   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
                  [email protected]
=====================================================

On Fri, 30 Oct 2009, James Hester wrote:

> As the syntax that we have been developing now stands, the only reason
> for not using square brackets is so that it will be possible to
> correctly parse a CIF in which a space is accidentally missing between
> a dataname and a bracketed list.  This seems to me to be a pretty
> minor reason to fiddle with the bracket syntax, but having got that
> off my chest I don't have any objections to the revised syntax.
>
> NB I believe Nick would like to drop the concept of tuples in DDLm and
> dREL altogether, with which I also agree.
>
> On Thu, Oct 29, 2009 at 10:31 PM, Herbert J. Bernstein
> <[email protected]> wrote:
>> I have no objection to Nick's approach. �I would suggest a straw vote as
>> soon as possible, so that we can have move forward on coding. �So to be as
>> specific as possible, here is what I think Nick is proposing:
>>
>> � 1. �All the bracketed constructs in a CIF be delimited by {}:
>> � � � �Lists: �{ ..., ... }
>> � � � �Tuples: { ..., ... }
>> � � � �Arrays: { ..., ... }
>> � � � �Tables: { key:value, key:value } with the distinctions among them
>> made primarily by the type specifications. Note that the key in a table
>> should be a quoted string.
>>
>> � 2. �That array dimensions in a CIF also be delimited by {} as in
>> {3} or {3,4}
>>
>> � 3. �That the same changes be made in dREL
>>
>> (Nick, did I get that right?)
>>
>> I can work with all of the above, and I suspect Nick is right about the
>> long-term value of consistency here, and reasonably strong typing does
>> tend to reduce coding errors. �What do other people think?
>>
>> 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
>> � � � � � � � � �[email protected]
>> =====================================================
>>
>> On Wed, 28 Oct 2009, Nick Spadaccini wrote:
>>
>>> 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" <[email protected]>
>>> 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
>>>> � � � � � � � � � [email protected]
>>>> =====================================================
>>>>
>>>> _______________________________________________
>>>> ddlm-group mailing list
>>>> [email protected]
>>>> 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: [email protected]
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> ddlm-group mailing list
>>> [email protected]
>>> http://scripts.iucr.org/mailman/listinfo/ddlm-group
>>>
>> _______________________________________________
>> ddlm-group mailing list
>> [email protected]
>> http://scripts.iucr.org/mailman/listinfo/ddlm-group
>>
>
>
>
> -- 
> T +61 (02) 9717 9907
> F +61 (02) 9717 3145
> M +61 (04) 0249 4148
> _______________________________________________
> ddlm-group mailing list
> [email protected]
> http://scripts.iucr.org/mailman/listinfo/ddlm-group
>
_______________________________________________
ddlm-group mailing list
[email protected]
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