Discussion List Archives

[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.
>>>> 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
>>>> 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



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

Reply to: [list | sender only]
International Union of Crystallography

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

International Science Council 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.