On Sun, Sep 5, 2010 at 13:29, varol kaptan <
varol.kaptan@gmail.com> wrote:
>
> On Sun, Sep 5, 2010 at 3:42 PM, Andre Leiradella <
andre@leiradella.com>
> wrote:
>>
>> On 05/09/2010 03:15, Florian Weimer wrote:
>>>
>>> * Rob Kendrick:
>>>
>>>> On Sat, Sep 04, 2010 at 10:54:59PM +0200, Florian Weimer wrote:
>>>>
>>>>> It could be argued that tostring is lossy for tables, so it can be
>>>>> lossy for numbers, too.
>>>>
>>>> Surely converting a floating point number to a string like this is
>>>> never not going to be lossy?
>>>
>>> The default conversion in Lua (that is, tostring) is lossy,
>>> unfortunately.
>>>
>> I'm having exactly the same problem with the serialization of floats and
>> doubles to JSON (C++, not Lua.)
>>
>> If the numbers are not supposed to be hand edited, the %a format specifier
>> creates a lossless (depending on the precision used) hexadecimal ASCII
>> representation of doubles that can be transformed back to double by strtod.
>> It's a one line change in lstrlib.c, function str_format:
>>
>> case 'e': case 'E': case 'f':
>> case 'g': case 'G': case 'a': { // %a format specifier added
>> sprintf(buff, form, (double)luaL_checknumber(L, arg));
>> break;
>> }
>>
>> Lua 5.1.4 Copyright (C) 1994-2008 Lua.org, PUC-Rio
>> > print(string.format('%.13a', 0.1)) -- 13 is large enough to represent
>> > all significand bits
>> 0x1.999999999999ap-4
>>
>> Which is 1.999999999999a * 2^-4. And tonumber already converts it back to
>> double:
>>
>> > print(tonumber('0x1.999999999999ap-4'))
>> 0.1
>>
>> Unfortunately the lexer doesn't like the hexadecimal point but patching it
>> must be easy:
>>
>> > a=0x1.999999999999a0p-4
>> stdin:1: malformed number near '.999999999999a0p'
>
> I am attaching a patch for anyone interested that does just that. Apply
> against stock 5.1.4.
>
>>
>> Doubles have 52 bits to represent the significand, so 52/4=13 in the %a
>> specifier is enough to represent all of its bits. The implicit 1 before the
>> significand (0 in denormals) is not part of the fraction so it does not
>> count in the 13 digits after the point.
>>
>> It's a shame I can't use this format in JSON, its specification doesn't
>> allow hexadecimal numbers.
>>
>> Cheers,
>>
>> Andre
>>
>
>
