Discussion List Archives

[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]
International Union of Crystallography

Scientific Union Member of the International Council for Science (admitted 1947). Member of CODATA, the ICSU Committee on Data. Member of ICSTI, the International Council for Scientific and Technical Information. Partner with UNESCO, the United Nations Educational, Scientific and Cultural Organization in the International Year of Crystallography 2014.

ICSU Scientific Freedom Policy

The IUCr observes the basic policy of non-discrimination and affirms the right and freedom of scientists to associate in international scientific activity without regard to such factors as ethnic origin, religion, citizenship, language, political stance, gender, sex or age, in accordance with the Statutes of the International Council for Science.