[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: A DDLm problem

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





_______________________________________________
comcifs mailing list
comcifs@iucr.org
http://scripts.iucr.org/mailman/listinfo/comcifs


Reply to: [list | sender only]