[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: why tostring for number use LUA_NUMBER_FMT "%.14g", not "%.16g" ?
- From: Coda Highland <chighland@...>
- Date: Sun, 8 Sep 2013 09:41:58 -0700
On Sun, Sep 8, 2013 at 8:58 AM, Dirk Laurie <firstname.lastname@example.org> wrote:
> 2013/9/8 Coda Highland <email@example.com>:
>> So there IS a valid question to be asked here: Why SHOULDN'T
>> tostring() use %.16g?
> What are you using tostring() for?
> (1) To give something that satisfies tonumber(tostring(x)) == x.
> (2) To print out only correct digits of the number that x is supposed
> to represent.
> Now, log(2^53,10)=15.95... I.e. almost, but not quite, 16 digits.
> Close enough, though, that tha vagaries of decimal notation
> don't allow you to distinguish in all cases between two different
> values. I.e. you can't even achieve (1) with "%g.16".
Okay, fine, 17 digits. That was simply a mistake on the part of my
memory; I hadn't gone and looked up the right answer and I remembered
While it's true that not all numbers printed with 17 decimal digits
can be accurately represented by a double, the converse is false --
that is, while tostring(tonumber(x)) can't be a guaranteed round-trip,
tonumber(tostring(x)) CAN be, by making tostring() output enough
> The valid question, IMHO, should rather be: why does Lua not
> have a variable called say 'string.numformat' which is initialiized
> to "%.15g" but over which the user has control? But to this
> question the answer is easy: because Lua already allows
> local oldtostring = tostring
> tostring = function(x) if type(x)=='number'
> then return string.format("%.16g".x)
> else return oldtostring(x)
> end end
And this is of course a perfectly valid concept, but that doesn't
change the fact that tostring() really OUGHT to output enough digits
to ensure a clean round trip. Since it's not only possible but trivial
to do so, and since tostring() is the closest thing Lua has to
built-in serialization, doesn't it stand to reason that it SHOULD?