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

Re: Specifying values 'less than something' in CIFs?. .

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:
>> ? 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

> 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

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 :)



Associate Professor N. Spadaccini, PhD.
Adjunct Research Fellow
The University of Western Australia
35 Stirling Highway
MBDP  M002

CRICOS Provider Code: 00126G

e: Nick.Spadaccini@uwa.edu.au

comcifs mailing list

Reply to: [list | sender only]