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

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

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

Reply to: [list | sender only]