[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Reply to: [list | sender only]
Re: A DDLm problem
- To: "Discussion list of the IUCr Committee for the Maintenance of the CIFStandard (COMCIFS)" <comcifs@iucr.org>
- Subject: Re: A DDLm problem
- From: James Hester <jamesrhester@gmail.com>
- Date: Sat, 28 Feb 2009 23:32:11 +1100
- Cc: coreCIFchem@iucr.org
- In-Reply-To: <20090227182925.B25474@epsilon.pair.com>
- References: <49A44CAB.4030502@mcmaster.ca><279aad2a0902261950s4e18a5acs5570757e1c5b16b9@mail.gmail.com><20090227182925.B25474@epsilon.pair.com>
Yes. Currently all dREL functions (and one hopes builtin functions in the final standard) belong to DDLm category 'Function'. We could usefully sketch out a hierarchy of subcategories here when putting together the final DDLm standard, or alternatively/additionally the standard DDLm importation mechanism when importing other dictionaries could resolve name conflicts. On Sat, Feb 28, 2009 at 10:31 AM, Herbert J. Bernstein <yaya@bernstein-plus-sons.com> wrote: > I like the idea of defining useful functions in the dictionary that > will not in and off themselves generate tags, but we need to > provide some control over scope and namespaces to make it easy to > combine useful functions from multiple dictionaries -- perhaps > adopting python's module based dotted notation to resolve > conflicts. > > ===================================================== > 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 Fri, 27 Feb 2009, James Hester wrote: > >> Dear David, >> >> I agree with your diagnosis of the problem, and, rather than clutter >> the dictionary with unnecessary baggage as solutions 1 and 2 do, I >> would suggest a variant of your 3rd solution: >> >> Solution 4: As beta is used primarily for calculational convenience, a >> dREL function 'beta()' is defined which calculates the beta value. >> The structure factor calculation is rewritten to call this function. >> A given dREL implementation can choose to cache values returned by >> this function to improve efficiency. >> >> Best wishes, >> James. >> >>> POSSIBLE SOLUTIONS >>> Tree 3 above can be made to work if the beta form can be made invisible. >>> It >>> cannot be completely invisible as it must appear in the appropriate CIF >>> dictionary, and its text description will be displayed by any CIF editor >>> such as publCIF or enCIFer. >> >> >>> One possible solution is to include a flag in the dictionary definition >>> to >>> indicate that the item should be hidden from the user or deleted after >>> the >>> calculation is complete. >> >> Invisibility can only be maintained if everyone respects the new DDLm >> attribute that will be created to flag it. The value will leak out. >> >>> >>> A second possibility is to give the item a dataname that disguises its >>> identity, e.g., a name such as _atom_site_aniso.intermediate1. The >>> dictionary would contain the .description 'This item is an intermediate >>> in >>> an ADP calculation and is not to be used for archival or retrieval >>> purposes'. >> >> Better than the first solution, but I believe an unnecessary >> cluttering of the dictionary >> >>> A third solution would be to rearrange the method for calculating the >>> structure factors so that it works with directly with Uaniso and does not >>> generate beta as an intermediate. In this case there is no need to >>> define >>> beta in the dictionary. >> >> Indeed, and if the rewriting >> >>> >>> THE SOLUTION I PROPOSE TO ADOPT >>> I propose that we adopt the second solution, i.e., we agree to use >>> datanames >>> and descriptions that indicate that the item is not to be used for >>> archival >>> purposes. There will of course be many intermediates that are perfectly >>> acceptable for archiving. For example, when Uaniso is calculated from >>> Biso, >>> Uiso and Baniso are generated along the way and there is no need to hide >>> them. Calculation of structure factors would also generate >>> atom_site.intermediate1 items containing the ADPs in the beta form, so >>> the >>> CIF may end up being a bit cluttered, but it should be possible to write >>> a >>> program that would clean up the CIF by removing any unwanted intermediate >>> items. In any case since external programs only need search for Uaniso, >>> the >>> presence of the other items will be of no concern. >>> >>> I am looking for feed back. However if I receive none, I will assume >>> that >>> you agree that unwanted intermediates should be hidden by giving them >>> meaningless datanames and text definitions that conceal their content. >>> >>> Please circulate your thoughts on this problem to the whole discussion >>> list. >>> >>> David Brown >>> >>> _______________________________________________ >>> comcifs mailing list >>> comcifs@iucr.org >>> http://scripts.iucr.org/mailman/listinfo/comcifs >>> >>> >> >> >> >> -- >> T +61 (02) 9717 9907 >> F +61 (02) 9717 3145 >> M +61 (04) 0249 4148 >> _______________________________________________ >> comcifs mailing list >> comcifs@iucr.org >> http://scripts.iucr.org/mailman/listinfo/comcifs > > _______________________________________________ > comcifs mailing list > comcifs@iucr.org > http://scripts.iucr.org/mailman/listinfo/comcifs > > -- T +61 (02) 9717 9907 F +61 (02) 9717 3145 M +61 (04) 0249 4148
Reply to: [list | sender only]
- Follow-Ups:
- Re: A DDLm problem (Nick Spadaccini)
- Re: A DDLm problem (Nick Spadaccini)
- References:
- A DDLm problem (David Brown)
- Re: A DDLm problem (James Hester)
- Re: A DDLm problem (Herbert J. Bernstein)
- Prev by Date: Re: A DDLm problem
- Next by Date: Re: A DDLm problem
- Prev by thread: Re: A DDLm problem
- Next by thread: Re: A DDLm problem
- Index(es):