Discussion List Archives

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

Re: [ddlm-group] Removing Octal,Hexadecimal and Binary as DDLm types

There seem to be no in-principle objections to removing Hex/Binary/Octal types from the dictionary. The separate question is then whether or not a hex/binary/octal representation of an integer should be available in a CIF data file and if so what would the syntax be?

Upon consideration, I would agree with Simon and be quite happy to drop the whole idea.  Any integer can be represented in a CIF file already (using base 10). Reasons for preferring hex/binary/octal might be when cutting and pasting integers presented in that form, or perhaps meanings might be more obvious to a human CIF reader (binary flags) (although really the meaning of the flags should be explicated anyway). Neither of these scenarios seem particularly common or compelling.  On the other hand, the rather impressive cost of allowing hex/binary/octal is that we render all current CIF reading programs non-conformant as they will not necessarily recognise hex/binary/octal representations.

By the way, I believe Saulius was referring to the 0x/0.. syntax recognised by the strtol() libc call (0x at the beginning = hexadecimal, leading 0 = octal).  CPython adds 0o and 0b for octal and binary, and as far as I can tell Perl has something similar, but these implementations do not rely on libc.  *If* we were to allow such syntax, allowing 0x to introduce hexadecimal would seem to involve minimum effort, and programmers who didn't explicitly ask for base 10 conversion when coding their CIF reading software would need do nothing.


On 20 February 2018 at 10:03, Simon Westrip <simonwestrip@btinternet.com> wrote:
Hi Saulius

Perhaps I misunderstood, but parsing e.g.

_some_unknown_data_item 11\h

could be interpreted as 11 followed by Greek eta if established semantics are followed,
or the decimal integer 17 if  \h is to be interpreted as indicating hexadecimal in this case
(bearing in mind that none of the documented semantics need be followed in any case).

Regardless of software libraries, there would be a burden on making this distinction when parsing a CIF
beyond just syntax?


From: Saulius Gražulis <grazulis@ibt.lt>
To: Simon Westrip <simonwestrip@btinternet.com>; Group finalising DDLm and associated dictionaries <ddlm-group@iucr.org>
Sent: Monday, 19 February 2018, 11:26
Subject: Re: [ddlm-group] Removing Octal, Hexadecimal and Binary as DDLm types

On 2018-02-19 13:13, Simon Westrip wrote:

> Hi James - I'd be inclined just to drop the types in DDLm.
> Extending the semantics used for presenting numbers
> seems like placing an unnecessary burden on CIF application developers
> (obliged to look out for octal, hexadecimal, binary ...)

May I chime in as an implementer:

actually, burden is not so large; if standard (libc-compatible)
representations are used, all these cases are handled by standard
libraries, no extra coding is necessary.


Dr. Saulius Gražulis
Vilnius University Institute of Biotechnology, Saulėtekio al. 7
LT-10257 Vilnius, Lietuva (Lithuania)
fax: (+370-5)-2234367 / phone (office): (+370-5)-2234353
mobile: (+370-684)-49802, (+370-614)-36366

ddlm-group mailing list

T +61 (02) 9717 9907
F +61 (02) 9717 3145
M +61 (04) 0249 4148
ddlm-group 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.