[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:29:40 +0900
- Authentication-Results: postfix;
- Cc: coreCIFchem@iucr.org
- In-Reply-To: <279aad2a0902280432w194042f5j5859d58ac1ad41cc@mail.gmail.com>
A quick response to David's original post is "there is no identifiable problem" in what David has written. The interim data items, many of which are the actual legitimate crystallographic objects, like the cell vectors rather than their scalar dimensions and hence I personally believe they should be part of the dictionary, don't have to be exported. They are in our prototype parser because I am too lazy to clean up the output, I simply dump the in memory Python dictionary. This aspect of what David sees as a problem, can be made to go away by using DDLm's import facility. That is, the parser reads in the core dictionary (with only the data items David/community would like to see in a submission file) and import a "fuller" dictionary to handle everything. On output the parser can be restricted to only exporting the data items in the core dictionary. Problem solved. The user would never see or know about the extra data items. James' idea of creating functions would work also, but there are to quite different classes of items here. Those which are truly library/utility functions like those that strip the ortep like object 2_567 in to a symmetry pointer 2, and a cell displacement vector [0, 1, 2]. That is a function. The other type of items are legitimate crystallographic items that merit definition and should not be obfuscated in code. For instance the cell displacement vector is a legitimate item and merits definition. Crystallographically [0, 1, 2] is meaningful whereas _567 is actually syntactic rubbish - albeit popular syntactic rubbish. You may insist on only seeing _567 but to deny the ability to define a truly crystallographic object like [0, 1, 2] is not sensible. Especially when it can be hidden using an importing functionality. The solution I describe by using importation will solve any perceived problem and is the very basis on which DDLm had an importing functionality created. Finally the _matrix_beta item is an item that does warrant definition and as Doug states is a true tensorial form of ADPs. David alludes to another problem that does not exist - there can be NO confusion in the definition of the individual off-diagonal beta terms (historically the is a factor of 2 confusion). Why? Because the individual off diagonal terms can never accessed because there is no definition for them. There is never an error in building the _matrix_beta because it is constructed directly from the U or B matrices (where there is no confusion). Finally, finally David suggests there is a problem with the fact that different evaluation pathways exist to obtaining an value for an item. That multiple paths is problematic whereas it is the expressed design in dREL. The beta->Uani->Bani->Uiso->Biso pathway David describes is not correct, and Doug makes an attempt to clarify (and gets closer). The actual calculation pathway is |->Uani |->Bani Beta| |->Uiso |->Biso Which seems perfectly logical to me. dREL is a Turing complete language and while there is one evaluation method in an item definition you can create a multitude of paths to the answer - and that is a GOOD THING. 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: Re: A DDLm problem
- Prev by thread: Re: A DDLm problem
- Next by thread: Re: A DDLm problem
- Index(es):