Subject: Re: [Json] I-JSON Topic #5: Numbers

From: "Joe Hildebrand (jhildebr)" <[email-masked]>
Date: Thu, 1 May 2014 18:19:47 +0000

Subnormals are allowed in JSON, I believe.  They probably don't interop
quite as expected if you're using C and have -O1 or higher turned on (for
example).

On 4/28/14, 3:11 PM, "Tim Bray" <[email-masked]> wrote:

>Well, they’re disallowed in JSON let alone i-json so I’d have hoped we
>can ignore them.
>
>On Mon, Apr 28, 2014 at 1:52 PM, Joe Hildebrand (jhildebr)
><[email-masked]> wrote:
>
>Will we need to talk about subnormals, -0, NaN, Infinity, and the like?

-- 
Joe Hildebrand

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 1 May 2014 14:40:45 -0400

On Mon, Apr 28, 2014 at 5:11 PM, Tim Bray <[email-masked]> wrote:
> Well, they’re disallowed in JSON let alone i-json so I’d have hoped we can
> ignore them.

Actually, they are not. Since null is a valid value.

If you are writing in C or C# and parsing JSON rather than using spray
and pray scripting approaches, using null to represent NaN makes
perfect sense.

I don't think it really matters though since I haven't ever written a
network application that used floating point values as protocol data.

What I have done is to use decimal fractions 0.2222 etc. But even
then, precision has not been a major concern.

Right now I map those values to 64 bit integers with a 2^32 offset. It
works well enough.

It would be a good idea to have a JSON style format for encoding
scientific data. But JSON isn't that format right now.

-- 
Website: http://hallambaker.com/

---

From: Matt Miller <[email-masked]>
Date: Mon, 19 May 2014 13:30:40 -0600

On 5/1/14, 12:19 PM, Joe Hildebrand (jhildebr) wrote:
> Subnormals are allowed in JSON, I believe.  They probably don't
> interop quite as expected if you're using C and have -O1 or higher
> turned on (for example).
> 
>> Well, they?re disallowed in JSON let alone i-json so I?d have
>> hoped we can ignore them.
>> 

Hello Joe,

could you provide more detail of what the concern here is?  I suspect
you have been too terse so far.

- -- 
- - m&m

Matt Miller < [email-masked] >
Cisco Systems, Inc.

---

From: "Joe Hildebrand (jhildebr)" <[email-masked]>
Date: Mon, 19 May 2014 22:00:59 +0000

>you have been too terse so far.

You're likely correct.

> interop quite as expected if you're using C and have -O1 or higher

Here's an example of a number that is allowed in JSON, but in some
implementations would lead to a subnormal number:

4e-324

You'll note that (at least in a couple of the browsers that I checked, as
well as node.js):

JSON.parse("4e-324") == 5e-324

The reason for this is that the minimum "normal" IEEE754 double-precision
floating point number is represented in hex as: 0010 0000 0000 0000, which
corresponds to roughly 2.2250738585072014e−308.  For numbers smaller than
this, precision gets thrown away intentionally, in order to represent
numbers closer to zero.  For example, the smallest number you can
represent this way is 0000 0000 0000 0001 (hex), which corresponds to
roughly 4.94e-324 ... which lets you understand why 5e-324 might be a
reasonable way to render this number as a string.

For some computations, the loss of precision is nice.  For others, you'd
just as soon have zero than a really tiny number.  IEEE-compliant hardware
will set an underflow flag when you get a subnormal result as the output
of a calculation.  However many languages (including C) don't give you
access to this flag.

This problem is exacerbated by the fact that different C compilers at
different optimization settings, at different usages of SSE processor
extensions will either "flush to zero" (FTZ) or not.  If FTZ is enabled,
your JSON parser is likely going to return 0 for JSON.parse("4e-324").

As such, there will be a loss of interoperability for very small numbers
(either positive or negative), and I think we should mention what the
smallest safely-interoperable numbers are.  10^-308 and -10^-308 seem like
reasonable limits in decimal-land.

-- 
Joe Hildebrand

---

From: John Cowan <[email-masked]>
Date: Mon, 19 May 2014 18:18:07 -0400

> reasonable limits in decimal-land.

This should have gone into the JSON (as opposed to I-JSON) spec as an
i14y warning.  Since it didn't, let's mention it here.

-- 
John Cowan          http://www.ccil.org/~cowan        [email-masked]
No man is an island, entire of itself; every man is a piece of the
continent, a part of the main.  If a clod be washed away by the sea,
Europe is the less, as well as if a promontory were, as well as if a
manor of thy friends or of thine own were: any man's death diminishes me,
because I am involved in mankind, and therefore never send to know for
whom the bell tolls; it tolls for thee.  --John Donne

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 20 May 2014 00:54:42 +0200

> 4e-324

That is a bad number for interop not because it is out of range, but because it is not something you can get from converting a binary64 into decimal, so it is somewhat arbitrary what happens on the way back.

I would be surprised if there are actual interop problems with 5e-324.
Consequently, I don’t quite buy a range limit at 1e-308 yet.
(It’s a precision limit, in any case.)

Grüße, Carsten

---

From: "Joe Hildebrand (jhildebr)" <[email-masked]>
Date: Tue, 20 May 2014 17:46:45 +0000

On 5/19/14, 4:54 PM, "Carsten Bormann" <[email-masked]> wrote:

>That is a bad number for interop not because it is out of range, but
>because it is not something you can get from converting a binary64 into
>decimal, so it is somewhat arbitrary what happens on the way back.
>

That was just an easy-to-see example.  Longer numbers less than 1e-308
will also have less precision than you expect for a double, or get rounded
to zero unexpectedly.

-- 
Joe Hildebrand

---

From: "Manger, James" <[email-masked]>
Date: Wed, 21 May 2014 11:36:15 +1000

>will also have less precision than you expect for a double, or get rounded

Less precision than an "average" double maybe,
but not less than you *expect* for a double.

The 1e-308 and 1e308 limits for full precision are a key part (and an expected part) of a double.

What isn’t explicitly stated about numbers in I-JSON is a 2^53 limit for integers. I’m not sure how to phrase it. It would have been nice to say "an I-JSON message MUST NOT include a number with only an integer part (no fraction or exponent part) that is greater than 9007199254740992 (2^53)". Unfortunately I don’t think that is viable. The best we can probably do is say that "an I-JSON message MUST NOT expect a receiver to treat an integer as the exact value given (distinct from integers differing by 1) if it is greater than 9007199254740992". 

Are either or both of the following valid I-JSON messages? Do they comply with "SHOULD NOT include numbers which express greater magnitude or precision than a [double]"?

  {"x":123456789012345680000}

  {"y":123456789012345678901}

ECMAScript (at least 5.1) writes numbers in JSON with up to 21 "significant" decimal digits [http://www.ecma-international.org/ecma-262/5.1/#sec-9.8.1]. It can produce the first example (x) so I hope that is valid. 

--
James Manger

---

From: John Cowan <[email-masked]>
Date: Tue, 20 May 2014 22:07:31 -0400

> but not less than you *expect* for a double.

It's the "chop to zero" that's a problem for i14y.

> expected part) of a double.

+1

> The best we can probably do is say that "an I-JSON message
> MUST NOT expect a receiver to treat an integer as the exact value
> given (distinct from integers differing by 1) if it is greater than
> 9007199254740992".

Almost.

"An I-JSON sender MUST NOT expect a receiver to treat a non-zero number
whose absolute value is greater than 1e308 or less than 1e-308
as an exact value.  Furthermore, an I-JSON sender MUST NOT expect a
receiver to treat an integer whose absolute value is greater than
9007199254740992 as an exact value."

>   {"y":123456789012345678901}

This is a special case of the above rules: these are both mathematically
1.2345678901234568e+20.

-- 
John Cowan          http://www.ccil.org/~cowan        [email-masked]
By Elbereth and Luthien the Fair, you shall have neither the Ring nor me!
                --Frodo

---

From: "Joe Hildebrand (jhildebr)" <[email-masked]>
Date: Wed, 21 May 2014 14:59:43 +0000

>9007199254740992 as an exact value."

+1.  Succinct and captures the issues.

-- 
Joe Hildebrand

---

From: Tim Bray <[email-masked]>
Date: Wed, 21 May 2014 10:19:01 -0500

I’ll go with the flow, but I’m wondering if it might not be better to just
call out to IEEE 754’s semantics, since that is well understood and widely
described; take a call-by-reference approach.

On Wed, May 21, 2014 at 9:59 AM, Joe Hildebrand (jhildebr) <
[email-masked]> wrote:

> _______________________________________________
> json mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/json
>

-- 
- Tim Bray (If you’d like to send me a private message, see
https://keybase.io/timbray)

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 21 May 2014 17:19:56 +0200

On 21 May 2014, at 04:07, John Cowan <[email-masked]> wrote:

> as an exact value

What is your definition of this term here?

The meaning I’m used to for “exact value” implies you shouldn’t expect a binary64-based implementation to treat 1.1 as an exact value.

(Or, more specifically, expect an implementation to internalize this representation as the identical value that would be implied by interpreting 1.1 as an ISO 6093 NR2 floating point number.
Actually, most implementations I’m aware of will internalize 1.1 as something like 2476979795053773/2251799813685248 and not the exact 2476979795053772.8/2251799813685248 = 11/10.)

> Furthermore, an I-JSON sender MUST NOT expect a
> 9007199254740992 as an exact value.

I’m with you on that one.

Grüße, Carsten

---

From: Tim Bray <[email-masked]>
Date: Wed, 21 May 2014 10:20:09 -0500

Probably worth mentioning that 9007199254740992 is 2**53.

---

From: Nico Williams <[email-masked]>
Date: Wed, 21 May 2014 11:19:13 -0500

+1

If we're going to be making reference to limits derived from IEEE754,
then we should be referencing IEEE754.

Nico
--

---

From: John Cowan <[email-masked]>
Date: Wed, 21 May 2014 14:32:27 -0400

Carsten Bormann scripsit:

> The meaning I’m used to for “exact value” implies you shouldn’t
> expect a binary64-based implementation to treat 1.1 as an exact value.

There is a binary64 number which differs from 1.1 by less than an ulp,
and may be identified with it.  This is distinct from the fact
that 1.1 + 1.1 + ... + 1.1 (ten times) is not equal to 11.

-- 
John Cowan          http://www.ccil.org/~cowan        [email-masked]
Newbies always ask:
  "Elements or attributes?
Which will serve me best?"
  Those who know roar like lions;
  Wise hackers smile like tigers.         --a tanka, or extended haiku

---

From: "Manger, James" <[email-masked]>
Date: Thu, 22 May 2014 10:45:33 +1000

>as an exact value.

This is wrong (in its implication that other numbers are exact).
Neither I-JSON nor JSON requires numbers to be held internally as a double. I-JSON simply recognizes that doubles are common so you can expect at least the precision & range of a double. You cannot expect values between 1e-308 and 1e308 to be treated exactly. One receiver might round it to the nearest double, another might use a BigDecimal class (treating it exactly). The non-exactness doesn't change abruptly at 1e308 or 1e-308 either.

--
James Manger

---

From: Tim Bray <[email-masked]>
Date: Thu, 22 May 2014 10:47:51 -0500

​Since I don’t pretend to much expertise in the finer points of numeric
representation, let me play referee.  I draw your attention to
http://tools.ietf.org/html/draft-bray-i-json-01#section-2.2 which is what
we’re trying to improve here.
- I think the second para, saying “Use strings if your numbers are too
big/precise”, is uncontroversial.
- I think the current first paragraph is also reasonably OK in the sense
that what it says is in fact correct.
- There is also a substantial body of knowledge around the number-wrangling
facts such as that there are lots of nice simple short decimally-expressed
numbers that are not going to round-trip.
- Also, the language in RFC7159 makes useful points such as what range of
integers will successfully round-trip and it is effectively included by
reference.

My take-away is that leaving the text as in i-json-01 would not be
terrible.  On re-reading this thread, I’m not sure I see any single
suggestion for expanding that text that someone else hasn’t successfully
nit-picked, except for John’s

And I'm not even sure that really adds much value.  If we start enumerating
all the gotchas that can getcha when you’re converting textual and binary
representations of numeric quantities back and forth, this is gonna be a
big long text.

On Wed, May 21, 2014 at 7:45 PM, Manger, James <
[email-masked]> wrote:

> Neither I-JSON nor JSON requires numbers to be held internally as a
> double. I-JSON simply recognizes that doubles are common so you can expect
> at least the precision & range of a double. You cannot expect values
> between 1e-308 and 1e308 to be treated exactly. One receiver might round it
> to the nearest double, another might use a BigDecimal class (treating it
> exactly). The non-exactness doesn't change abruptly at 1e308 or 1e-308
> either.
>
> --
> James Manger
>

---

From: Nico Williams <[email-masked]>
Date: Thu, 22 May 2014 11:14:59 -0500

My proposal is to reference IEEE 754 and perhaps have some informative
references to various web pages detailing the limitations of IEEE 754
doubles.  Then state that any numbers which cannot be represented -by
JSON implementations that use IEEE 754 doubles- with sufficient
precision/accuracy/fidelity SHOULD NOT (MUST NOT?) be sent as JSON
numbers.

Alternatively, find a suitable external, informative reference to the
limitations of IEEE 754, get permission to copy its text, then paste
it in.

Or, if IEEE 754 covers these issues in sufficient detail, then just
normatively reference IEEE 754 and call it a day.

If IEEE 754 does not cover these issues in sufficient detail then we
probably could do with a generic RFC on the matter...

Nico
--

---

From: Matt Miller <[email-masked]>
Date: Tue, 27 May 2014 10:45:12 -0600

On 5/22/14, 10:14 AM, Nico Williams wrote:
> My proposal is to reference IEEE 754 and perhaps have some
> informative references to various web pages detailing the
> limitations of IEEE 754 doubles.  Then state that any numbers which
> cannot be represented -by JSON implementations that use IEEE 754
> doubles- with sufficient precision/accuracy/fidelity SHOULD NOT
> (MUST NOT?) be sent as JSON numbers.
> 
> Alternatively, find a suitable external, informative reference to
> the limitations of IEEE 754, get permission to copy its text, then
> paste it in.
> 
> Or, if IEEE 754 covers these issues in sufficient detail, then
> just normatively reference IEEE 754 and call it a day.
> 
> If IEEE 754 does not cover these issues in sufficient detail then
> we probably could do with a generic RFC on the matter...
> 
> Nico --
> 

Nico, do you have any concrete suggestions of text?  It would appear
that John Cowan's is very close; what changes would you propose over that?

I've been told off-list that IEEE 754 (which is referenced from RFC
7159, in case we've all forgotten) doesn't cover this topic at all,
and my own superficial review leads me to concur.

- -- 
- - m&m

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 27 May 2014 19:27:26 +0200

> and my own superficial review leads me to concur.

IEEE Std 754-2008 describes a number of formats, and binary64 (the one that JavaScript and thus many JSON implementations uses) is just one of them.  You need to combine some basic CS knowledge with the specific constants for binary64 inserted into the generic formulae given before you can derive much meaningful information from IEEE Std 754-2008.

An obvious reference (heed the title!) is

David Goldberg: What Every Computer Scientist Should Know About Floating-Point Arithmetic, Computing Surveys, March, 1991.

(reprint available from: http://docs.oracle.com/cd/E19957-01/806-3568/ncg_goldberg.html ).
That does discuss binary64 (not under this name), but does not benefit from the recent changes to IEEE 754.
It is also probably more accessible to CS people than to the general public.

“95% of the folks out there are completely clueless about floating-point.” 
(James Gosling 1998-02-28, as attributed by William Kahan)

We cannot fix this in this draft.

What we can do is warn that the only numbers that have a good chance to be taken as exact numbers are the integers in [-2**53, 2**53], and that all numbers in many implementations are subject to the whims of floating point arithmetic as defined for binary64 in IEEE Std 754-2008.
I wouldn’t try to go beyond that.  (In particular I’d not single out denorms, but I think I said that already.)

Grüße, Carsten

---

From: Tim Bray <[email-masked]>
Date: Tue, 27 May 2014 12:44:39 -0500

Just to make it clear. The WG is looking at three options:

- leave it like it is in draft-i-json-01
- Add John’s paragraph: "An I-JSON sender MUST NOT expect a receiver to
treat a non-zero number whose absolute value is greater than 1e308 or less
than 1e-308 as an exact value.  Furthermore, an I-JSON sender MUST NOT
expect a receiver to treat an integer whose absolute value is greater than
9007199254740992 as an exact value."
- Add some more text; there’s been some arm-waving on the mailing list, but
no actual proposals that I could crystallize into spec text.

On Tue, May 27, 2014 at 12:27 PM, Carsten Bormann <[email-masked]> wrote:

> IEEE Std 754-2008 describes a number of formats, and binary64 (the one
> that JavaScript and thus many JSON implementations uses) is just one of
> them.  You need to combine some basic CS knowledge with the specific
> constants for binary64 inserted into the generic formulae given before you
> can derive much meaningful information from IEEE Std 754-2008.
>
> David Goldberg: What Every Computer Scientist Should Know About
> Floating-Point Arithmetic, Computing Surveys, March, 1991.
>
> (reprint available from:
> http://docs.oracle.com/cd/E19957-01/806-3568/ncg_goldberg.html ).
> What we can do is warn that the only numbers that have a good chance to be
> taken as exact numbers are the integers in [-2**53, 2**53], and that all
> numbers in many implementations are subject to the whims of floating point
> arithmetic as defined for binary64 in IEEE Std 754-2008.
> I wouldn’t try to go beyond that.  (In particular I’d not single out
> denorms, but I think I said that already.)
>
> Grüße, Carsten
>
>

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 27 May 2014 19:48:06 +0200

On 27 May 2014, at 19:44, Tim Bray <[email-masked]> wrote:

> An I-JSON sender MUST NOT expect a receiver to treat a non-zero number whose absolute value is greater than 1e308 or less than 1e-308 as an exact value.  

I think James and I have successfully argued that this sentence is broken.

I have just argued that this gives a false sense of covering the issues.
Just to throw in one more issue if we want to go that far: maybe we want to mention that lots of fun can be had by interchanging 2.2250738585072011e-308 or 2.2250738585072012e-308?

Grüße, Carsten

---

From: Matt Miller <[email-masked]>
Date: Tue, 27 May 2014 11:52:02 -0600

On 5/27/14, 11:48 AM, Carsten Bormann wrote:
>> An I-JSON sender MUST NOT expect a receiver to treat a non-zero
>> number whose absolute value is greater than 1e308 or less than
>> 1e-308 as an exact value.
> 
> I have just argued that this gives a false sense of covering the
> issues. Just to throw in one more issue if we want to go that far:
> maybe we want to mention that lots of fun can be had by
> interchanging 2.2250738585072011e-308 or 2.2250738585072012e-308?
> 
> Grüße, Carsten
> 

Carsten,

Is your suggestion then to leave the text as-is?  Or can you provide
specific text to include?

- -- 
- - m&m

---

From: John Cowan <[email-masked]>
Date: Tue, 27 May 2014 14:43:42 -0400

Carsten Bormann scripsit:

> > An I-JSON sender MUST NOT expect a receiver to treat a non-zero number
> > whose absolute value is greater than 1e308 or less than 1e-308 as
> > an exact value.
> 

I agree.

-- 
John Cowan          http://www.ccil.org/~cowan        [email-masked]
You are a child of the universe no less than the trees and all other acyclic
graphs; you have a right to be here.  --DeXiderata by Sean McGrath

---

From: Tim Bray <[email-masked]>
Date: Tue, 27 May 2014 13:59:57 -0500

​You guys are convincing me we should leave the text the way it is.

Except for maybe add a sentence along the lines of “Implementors are
advised that the conversion between textual and binary representation of
numeric quantities is known to be a source of difficulties and, in certain
circumstances, data loss.”  A suitable read-more-here reference would be
welcome; Maybe that Goldberg reference Carsten mentioned?

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 27 May 2014 21:17:21 +0200

> specific text to include?

As I said, the second half of the proposed addition does add clarity:

»Furthermore, an I-JSON sender MUST NOT expect a receiver to treat an integer whose absolute value is greater than 9007199254740992 as an exact value.«

To be able to attach this right to the first paragraph of 2.2, maybe s/Furthermore/In particular/.
Also add the suggestion to call out that 9007199254740992 is 2**53:

   Software which implements IEEE 754-2008 binary64 (double precision)
   numbers [IEEE754] is generally available and widely used.
   Implementations which generate I-JSON messages MUST NOT assume that
   receiving implementations can process numeric values with greater
   magnitude or precision than provided by those numbers.  I-JSON
   messages SHOULD NOT include numbers which express greater magnitude
   or precision than an IEEE 754 double precision number provides, for
   example 1E400 or 3.141592653589793238462643383279.
   ➧ In particular, an I-JSON sender MUST NOT expect a receiver to treat
   an integer whose absolute value is greater than 9007199254740992 (i.e., 
   that is outside the range [-2**53, 2**53], where ** stands for exponentiation)
   as an exact value.

This then leads well into the next paragraph:

   For applications such as cryptography, where much larger numbers are
   reasonably required, it is RECOMMENDED to encode them in JSON string
   values.  This requires that the receiving program understand the
   intended semantic of the value.

Maybe s/where…are/where exact interchange of…is/ in there for even more clarity.

Grüße, Carsten

---

From: John Cowan <[email-masked]>
Date: Tue, 27 May 2014 15:26:25 -0400

Carsten Bormann scripsit:

>    or precision than an IEEE 754 double precision number provides,
>    for example 1E400 or 3.141592653589793238462643383279.  In
>    particular, an I-JSON sender MUST NOT expect a receiver to treat
>    an integer whose absolute value is greater than 9007199254740992
>    (i.e., that is outside the range [-2**53, 2**53], where ** stands
>    for exponentiation) as an exact value.
> 
>    For applications such as cryptography, where exact interchange
>    of much larger numbers is reasonably required, it is RECOMMENDED to
>    encode them in JSON string values.  This requires that the receiving
>    program understand the intended semantic of the value.

+1

-- 
John Cowan          http://www.ccil.org/~cowan        [email-masked]
So they play that [tune] on their fascist banjos, eh?
        --Great-Souled Sam

---

From: "Manger, James" <[email-masked]>
Date: Wed, 28 May 2014 09:31:54 +1000

+1 to Carsten's text.

-----

Grüße, Carsten

---

From: Tim Bray <[email-masked]>
Date: Fri, 30 May 2014 14:38:40 -0700

On Tue, May 27, 2014 at 12:17 PM, Carsten Bormann <[email-masked]> wrote:

> ​​
> ​​
> ​​
> ​​

​BTW, RFC7159 says: Note that when such software is used, numbers which are
integers and are in the range [-(2**53)+1, (2**53)-1] are interoperable in
the sense that implementations will agree exactly on their numeric values.​
 So for consistency we should adjust this language to use this range and
the absolute value of 9007199254740991 - right?
​​

​​

​​

---

From: John Cowan <[email-masked]>
Date: Fri, 30 May 2014 18:04:16 -0400

> the absolute value of 9007199254740991 - right?

Yes.

-- 
John Cowan          http://www.ccil.org/~cowan        [email-masked]
But the next day there came no dawn, and the Grey Company passed on
into the darkness of the Storm of Mordor and were lost to mortal sight;
but the Dead followed them.          --"The Passing of the Grey Company"

---

From: Carsten Bormann <[email-masked]>
Date: Sat, 31 May 2014 07:22:45 +0200

On 30 May 2014, at 23:38, Tim Bray <[email-masked]> wrote:

> ​​   ➧ In particular, an I-JSON sender MUST NOT expect a receiver to treat
> ​​   an integer whose absolute value is greater than 9007199254740992 (i.e.,
> ​​   that is outside the range [-2**53, 2**53], where ** stands for exponentiation)
> ​​   as an exact value.
> 
> ​BTW, RFC7159 says: Note that when such software is used, numbers which are integers and are in the range [-(2**53)+1, (2**53)-1] are interoperable in the sense that implementations will agree exactly on their numeric values.​  So for consistency we should adjust this language to use this range and the absolute value of 9007199254740991 - right?

Consistency is good.

The new text makes use of the fact that 2**53+1 is the first integer that cannot be represented in binary64.
2**53 itself is a bit of an edge case because it can be represented exactly, but carries the uncertainty whether 2*53+1 was meant instead.
So if an implementation checks exactness only after conversion, it can only accept [-(2**53)+1, (2**53)-1].

Indeed, let’s stick with the narrower range [-(2**53)+1, (2**53)-1].

Grüße, Carsten