[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
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.
--
Reply to: [list | sender only]
Re: [ddlm-group] Removing Octal,Hexadecimal and Binary as DDLm types
- To: Simon Westrip <simonwestrip@btinternet.com>, Group finalising DDLm and associated dictionaries <ddlm-group@iucr.org>
- Subject: Re: [ddlm-group] Removing Octal,Hexadecimal and Binary as DDLm types
- From: James Hester <jamesrhester@gmail.com>
- Date: Tue, 20 Feb 2018 14:49:48 +1100
- DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;h=mime-version:in-reply-to:references:from:date:message-id:subject:to;bh=V6VasA9Prrt06VeLy3W+MzgKtX4AK7lBeW6HS6drOtQ=;b=ROii/aHCwTyhkgelflExb46JNf3FA8REHi5M8eIsI1mlMl/c4SKEB8u2m+NAgWK5HUgNxo+m2P5eSuSpJ6Nubv31Ct4e8ny8dTojraTxPSdY9LNN5J4mfKFUAdGF024mO0kU28WdvX8aXUeqW5SlS+3OJaUSXmxji+VbgjSJdnxd5ZIB68oRkjxFrPtROZz/u0kpxERmOSSifprppMv1e7EwbssAe2xCROxkYP2YAaUpMLxtd3BoKvjvMkT3Sg2JcxeOujOWAGhhVPqtTlsFdLM5GQfo8Tdq5ROBC0IIyy/NFm3rzCifoWzLMgO6mJXI+SRSDY6APRBxABIVRdlvow==
- In-Reply-To: <45623507.2670596.1519081414440@mail.yahoo.com>
- References: <CAM+dB2dN7PGp+ZTBHYaOqGgSKb0urGYsCcu2oLk8XhzU9WeDcQ@mail.gmail.com><249013478.1798230.1519038802428@mail.yahoo.com><2f58731e-cd18-23ce-a5af-718055199f1b@ibt.lt><45623507.2670596.1519081414440@mail.yahoo.com>
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.
James.
On 20 February 2018 at 10:03, Simon Westrip <simonwestrip@btinternet.com> wrote:
Hi SauliusPerhaps I misunderstood, but parsing e.g._some_unknown_data_item 11\hcould 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 CIFbeyond just syntax?CheersSimon
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.
Regards,
Saulius
--
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
ddlm-group@iucr.org
http://mailman.iucr.org/cgi-bin/mailman/listinfo/ddlm- group
--
T +61 (02) 9717 9907
F +61 (02) 9717 3145
M +61 (04) 0249 4148
F +61 (02) 9717 3145
M +61 (04) 0249 4148
_______________________________________________ ddlm-group mailing list ddlm-group@iucr.org http://mailman.iucr.org/cgi-bin/mailman/listinfo/ddlm-group
Reply to: [list | sender only]
- References:
- [ddlm-group] Removing Octal, Hexadecimal and Binary as DDLm types (James Hester)
- Re: [ddlm-group] Removing Octal,Hexadecimal and Binary as DDLm types (Simon Westrip)
- Re: [ddlm-group] Removing Octal,Hexadecimal and Binary as DDLm types (=?UTF-8?Q?Saulius_Gra=c5=beulis?=)
- Re: [ddlm-group] Removing Octal,Hexadecimal and Binary as DDLm types (Simon Westrip)
- Prev by Date: Re: [ddlm-group] Removing Octal,Hexadecimal and Binary as DDLm types
- Next by Date: Re: [ddlm-group] Removing Octal,Hexadecimal and Binary as DDLm types
- Prev by thread: Re: [ddlm-group] Removing Octal,Hexadecimal and Binary as DDLm types
- Next by thread: Re: [ddlm-group] Removing Octal,Hexadecimal and Binary as DDLm types
- Index(es):