On Friday, 22 August 2014 at 20:02:41 UTC, Sönke Ludwig wrote:
Am 22.08.2014 21:48, schrieb Christian Manning:
On Friday, 22 August 2014 at 17:45:03 UTC, Sönke Ludwig wrote:
Am 22.08.2014 19:27, schrieb "Marc Schütz"
<schue...@gmx.net>":
On Friday, 22 August 2014 at 16:56:26 UTC, Sönke Ludwig
wrote:
Am 22.08.2014 18:31, schrieb Christian Manning:
It would be nice to have integers treated separately to
doubles. I
know
it makes the number parsing simpler to just treat
everything as
double,
but still, it could be annoying when you expect an integer
type.
That's how I've done it for vibe.data.json, too. For the new
implementation, I've just used the number parsing routine
from
Andrei's std.jgrandson module. Does anybody have
reservations about
representing integers as "long" instead?
It should automatically fall back to double on overflow.
Maybe even use
BigInt if applicable?
I guess BigInt + exponent would be the only lossless way to
represent
any JSON number. That could then be converted to any desired
smaller
type as required.
But checking for overflow during number parsing would
definitely have
an impact on parsing speed, as well as using a BigInt of
course, so
the question is how we want set up the trade off here (or if
there is
another way that is overhead-free).
You could check for a decimal point and a 0 at the front
(excluding
possible - sign), either would indicate a double, making the
reasonable
assumption that anything else will fit in a long.
Yes, no decimal point + no exponent would work without overhead
to detect integers, but that wouldn't solve the proposed
automatic long->double overflow, which is what I meant. My
current idea is to default to double and optionally support any
of long, BigInt and "Decimal" (BigInt+exponent), where integer
overflow only works for long->BigInt.
It might be the right choice anyway (seeing as json/js do
overflow to double), but fwiw it's still atrocious.
double a = long.max;
assert(iota(1, 1000000).map!(d => (a+d)-a).until!"a !=
0".walkLength == 1024);
Yuk.
Floating point numbers and integers are so completely different
in behaviour that it's just dishonest to transparently switch
between the two. This especially the case for overflow from long
-> double, where by definition you're 10 bits past being able to
reliably accurately represent the integer in question.
