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

Re: [ddlm-group] CIF-2 changes

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
<yaya@bernstein-plus-sons.com> 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
>                  yaya@dowling.edu
> =====================================================
>
> 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" <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
>>
> _______________________________________________
> ddlm-group mailing list
> ddlm-group@iucr.org
> 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
ddlm-group@iucr.org
http://scripts.iucr.org/mailman/listinfo/ddlm-group


Reply to: [list | sender only]