[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: Nick Spadaccini <nick@csse.uwa.edu.au>
- Date: Sun, 01 Mar 2009 12:30:44 +0900
- Authentication-Results: postfix;
- Cc: coreCIFchem@iucr.org
- In-Reply-To: <279aad2a0902280432w194042f5j5859d58ac1ad41cc@mail.gmail.com>
Correct any function definition can be handled by the "functions" category. On 28/02/09 9:32 PM, "James Hester" <jamesrhester@gmail.com> wrote: > 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 >> >> > > cheers Nick -------------------------------- Dr N. Spadaccini School of Computer Science & Software Engineering The University of Western Australia t: +(61 8) 6488 3452 35 Stirling Highway f: +(61 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
Reply to: [list | sender only]
- References:
- Re: A DDLm problem (James Hester)
- Prev by Date: Re: A DDLm problem
- Next by Date: DDLm implementation discussion
- Prev by thread: Re: A DDLm problem
- Next by thread: As per your email
- Index(es):