Discussion List Archives

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

Re: A DDLm problem

A quick response to David's original post is "there is no identifiable
problem" in what David has written.

The interim data items, many of which are the actual legitimate
crystallographic objects, like the cell vectors rather than their scalar
dimensions and hence I personally believe they should be part of the
dictionary, don't have to be exported. They are in our prototype parser
because I am too lazy to clean up the output, I simply dump the in memory
Python dictionary.

This aspect of what David sees as a problem, can be made to go away by using
DDLm's import facility. That is, the parser reads in the core dictionary
(with only the data items David/community would like to see in a submission
file) and import a "fuller" dictionary to handle everything. On output the
parser can be restricted to only exporting the data items in the core
dictionary. Problem solved. The user would never see or know about the extra
data items.

James' idea of creating functions would work also, but there are to quite
different classes of items here. Those which are truly library/utility
functions like those that strip the ortep like object 2_567 in to a symmetry
pointer 2, and a cell displacement vector [0, 1, 2]. That is a function.

The other type of items are legitimate crystallographic items that merit
definition and should not be obfuscated in code. For instance the cell
displacement vector is a legitimate item and merits definition.
Crystallographically [0, 1, 2] is meaningful whereas _567 is actually
syntactic rubbish - albeit popular syntactic rubbish.

You may insist on only seeing _567 but to deny the ability to define a truly
crystallographic object like [0, 1, 2] is not sensible. Especially when it
can be hidden using an importing functionality.

The solution I describe by using importation will solve any perceived
problem and is the very basis on which DDLm had an importing functionality
created.

Finally the _matrix_beta item is an item that does warrant definition and as
Doug states is a true tensorial form of ADPs. David alludes to another
problem that does not exist - there can be NO confusion in the definition of
the individual off-diagonal beta terms (historically the is a factor of 2
confusion). Why? Because the individual off diagonal terms can never
accessed because there is no definition for them. There is never an error in
building the _matrix_beta because it is constructed directly from the U or B
matrices (where there is no confusion).

Finally, finally David suggests there is a problem with the fact that
different evaluation pathways exist to obtaining an value for an item. That
multiple paths is problematic whereas it is the expressed design in dREL.

The beta->Uani->Bani->Uiso->Biso pathway David describes is not correct, and
Doug makes an attempt to clarify (and gets closer). The actual calculation
pathway is

    |->Uani
    |->Bani
Beta|
    |->Uiso
    |->Biso

Which seems perfectly logical to me. dREL is a Turing complete language and
while there is one evaluation method in an item definition you can create a
multitude of paths to the answer - and that is a GOOD THING.

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







Reply to: [list | sender only]