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

Re: A DDLm problem

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
_______________________________________________
comcifs mailing list
comcifs@iucr.org
http://scripts.iucr.org/mailman/listinfo/comcifs


Reply to: [list | sender only]