Discussion List Archives

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