[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Reply to: [list | sender only]
Re: [ddlm-group] CIF-2 changes
- To: Group finalising DDLm and associated dictionaries <ddlm-group@iucr.org>
- Subject: Re: [ddlm-group] CIF-2 changes
- From: James Hester <jamesrhester@gmail.com>
- Date: Fri, 30 Oct 2009 07:42:51 +1100
- In-Reply-To: <20091029071133.T55986@epsilon.pair.com>
- References: <C70E140F.12220%nick@csse.uwa.edu.au><20091029071133.T55986@epsilon.pair.com>
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]
- Follow-Ups:
- Re: [ddlm-group] CIF-2 changes (Joe Krahn)
- Re: [ddlm-group] CIF-2 changes (Herbert J. Bernstein)
- References:
- Re: [ddlm-group] CIF-2 changes (Nick Spadaccini)
- Re: [ddlm-group] CIF-2 changes (Herbert J. Bernstein)
- Prev by Date: Re: [ddlm-group] Triple-quoted strings
- Next by Date: Re: [ddlm-group] CIF-2 changes
- Prev by thread: Re: [ddlm-group] CIF-2 changes
- Next by thread: Re: [ddlm-group] CIF-2 changes
- Index(es):