[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: Lua minus null (-0)
- From: Martin Guy <martinwguy@...>
- Date: Mon, 6 Jun 2011 01:47:09 +0200
On 5 June 2011 23:43, Dirk Laurie <firstname.lastname@example.org> wrote:
> On Sun, Jun 05, 2011 at 10:44:24PM +0200, Henk Boom wrote:
>> If I understand the Sebastian properly, he is not complaining that lua
>> doesn't differentiate between them, but that these two numbers which
>> are not normally differentiated do not print the same:
>> On Sun, Jun 05, 2011 at 12:47:39PM +0200, Sebastian wrote:
>> > The problem of the output from -0 is that -0 does'nt look good.
>> > The user (for example a wow addon user) can be disoriented,
>> > when he read the addon output: "(-20) * 0 = -0.
> That, too, is not a bug, it's a feature. Reuben's point applies:
> Lua relies on the host C compiler and its libraries. Since C converts
> a negative zero to the string -0, so does Lua.
printf("%f\n", -20.0 * 0.0);
with GNU libc.
> It is a good thing, not a bad thing.
It's bizarre to expose such an esoteric implementation detail so
baldly. Only an IEEE validation suite specialist would be worried
about seeing the "-"; for normal people, the "-" contains no
information and is just surprising/worrying.
I suppose the workaround is to redefine tostring so that it checks for
numeric x == 0 (which also succeeds when x has the IEEE value -0) and
return "0" in that case.
local old = tostring
tostring = function(x) return (x == 0) and "0" or old(x) end
It's still bizarre though, whether glibc thinks so or not.
tostring() is not constrined to follow what glibc does. Already it
does a range of different things according to the type and value of x.
In this case, printing "0" is obviously the right thing to do.
There may be an argument that printing -0.0000001 to five digits'
precision could return -0.00000 but even that is debatable.