A DDLm problem
Nick Spadaccini
nick at csse.uwa.edu.au
Sun Mar 1 03:30:44 GMT 2009
Correct any function definition can be handled by the "functions" category.
On 28/02/09 9:32 PM, "James Hester" <jamesrhester at 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 at 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 at 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 at 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 at iucr.org
>>> http://scripts.iucr.org/mailman/listinfo/comcifs
>>
>> _______________________________________________
>> comcifs mailing list
>> comcifs at 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 at uwa.edu.au
More information about the comcifs
mailing list