[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Reply to: [list | sender only]
Re: Specifying values 'less than something' in CIFs?. .
- To: "Discussion list of the IUCr Committee for the Maintenance of the CIF Standard (COMCIFS)" <email@example.com>
- Subject: Re: Specifying values 'less than something' in CIFs?. .
- From: Nick Spadaccini <firstname.lastname@example.org>
- Date: Tue, 01 May 2012 12:15:33 +0800
- In-Reply-To: <8F77913624F7524AACD2A92EAF3BFA544EB7DD5E2D@11.stjude.org>
On 30/04/12 11:15 PM, "Bollinger, John C" <John.Bollinger@STJUDE.ORG> wrote: > > On Sunday, April 29, 2012 11:02 AM, Nick Spadaccini wrote: > >> OFFICIALLY - >> ? means the data value is unknown and the default defined in the dictionary >> for that data item can be used. >> . means the value has no meaning in the current context, more often used in >> loops. > > At the risk of exhibiting ignorance, that answer seems not entirely consistent > with CIF usage as I understand it. Is it what you meant to say? Has there > been a shift in opinion down in Oz as to how these values should be used? > Does that vary from dictionary to dictionary? What I have written dates back to the early 90s and the original STAR specification I think. Maybe the older gents can wade in on opinion on origin. > Yes, the value ? is a placeholder representing an unknown value, and yes, . is > a placeholder for a value that is undefined or not applicable in context. But > a dictionary-defined default value is not in general a safe estimate for an > unknown value; at best, that would depend on the definition of the item in > question. > > In practice, it is the other place-holder, ., that by CIF convention is > overloaded with the meaning "default value". The canonical example is > symmetry codes in the _geom_* categories of Core CIF, such as > _geom_bond_site_symmetry_2. A . as the value of that item is conventionally > interpreted as the default value, 1_555. That particular value should never > be recorded as ?, because (1) if the _geom_bond_* packet is in any way > meaningful then both site symmetry codes are certainly known, and (2) existing > CIF software may rely on . being used to designate the default value in this > case. There is a contradiction in this approach. Firstly as above you accept ... "and yes, . is a placeholder for a value that is undefined or not applicable in context." which means a value is undefined or meaningless, but you overload it with the local convention "I actually know the exact value but I couldn't be fagged to tell you, so interpret . as such and such in this particular case, and by the way there are many other data items where I may use a . and there will a different interpretation but I won't tell you what, I'll leave you to flounder in the dark". Yes a very long winded convention and difficult to express with a tongue planted in one's cheek. I will accept that in some cases substitution of a default makes more sense in the case of "." than in the case of "?". I have no problem there. And I agree depending on what the program is going to do with it, different things will happen. I however have difficulty in accepting "." to mean I am being lazy. Of course much of this is a moot point in the case of STAR/DDLm/dREL where when I request from my parser the Uij matrix for H1 below I get the matrix because dREL has trawled through to generate it from what is in the data. If it finds a Uoverall or a Uiso it generates an appropriate diagonal matrix, otherwise a matrix of zeros (I actually haven't bothered to implement the last bit - lazy). The latter adds to the calculation time for a structure factor say because there is a lot of evaluation going on just to generate a 1 for thermal displacement factor but the dREL engine was never pitched as a fast system, just a correct one. Note that if the item in question was _attached_atom the "." would be returned by dREL as a NULL indicating there is no attached atom. > That does not in any way invalidate the thermal parameter example, however: > >> For example if you have a loop of atomic data, >> >> _id _x _y _z _u11 _u22 _u33 _u12 _u13 _u23 >> C1 .5 .4 .6 .03 .02 .03 .001 .002 -.002 >> O1 .1 .2 .3 .02 .02 .02 .001 ? ? >> H1 .5 .4 .8 . . . . . . >> >> In O1 the values u13, u23 are missing and unknown. >> In H1 the values u11-u23 have no meaning because it was isotropically refined >> OR no thermals were refined. > > In the end, how a program should deal with the placeholder values depends on > multiple factors, such as the program's purpose, the definition (if any) of > the item for which a placeholder value is recorded, and the particular > placeholder value used. For example, a semantic validation program > encountering CIF site occupancies given as ? should at least flag them as > questionable, a CIF pretty printer ought to accept them and leave them > unchanged, and a crystallographic refinement program might choose to > substitute a default value such as 1.0. > > [...] > >> Once you are able to include evaluation and validation methods within the >> domain dictionary most bases are covered. > > I look forward to hearing about that. I am sure Syd will wow you with his presentation, once I have written it :) cheers Nick -------------------------------- Associate Professor N. Spadaccini, PhD. Adjunct Research Fellow The University of Western Australia 35 Stirling Highway CRAWLEY, Perth, WA 6009 AUSTRALIA MBDP M002 CRICOS Provider Code: 00126G e: Nick.Spadaccini@uwa.edu.au _______________________________________________ comcifs mailing list email@example.com http://mailman.iucr.org/mailman/listinfo/comcifs
Reply to: [list | sender only]
- RE: Specifying values 'less than something' in CIFs?. . (Bollinger, John C)
- Prev by Date: RE: Specifying values 'less than something' in CIFs?. .
- Next by Date: Re: Draft namespace recommendations
- Prev by thread: RE: Specifying values 'less than something' in CIFs?. .
- Next by thread: Re: Specifying values 'less than something' in CIFs?