• Subject: Re: Lua minus null (-0)
• From: David Kastrup <dak@...>
• Date: Thu, 09 Jun 2011 17:03:09 +0200

```Roberto Ierusalimschy <roberto@inf.puc-rio.br> writes:

>> Huh?  Lua is _not_ C.  The above definitions are _internals_ of Lua.  C
>> does not even _have_ a generic tostring function, so it is nonsensical
>> to talk about "Lua behaves differently from C".
>
> Just to focus the discussion, the point is not about Lua being or not
> different from C, but about Lua being or not different from IEEE 754.

Unless we are outputting a number representation guaranteed to yield an
identical value when read back in, I don't see how IEEE754 comes into
play.  Seriously: most of the time tonumber(tostring(x)) ~= x anyway, so
it seems strange to demand tostring(-0) ~= tostring(0) when we have
-0 == 0.

> The IEEE 754 standard is quite respected. It was written by people
> that understands much more than us (or at least than me) about the
> nuances of number representations. If they decided that there should
> be a -0, that 0 == -0 but 1/0 ~= 1/-0, and that -0 should print as -0,
> I see no reason to disagree.

When did they decide that -0 should print as 0?

> Seriously, I do not see what is the big problem. Those that know about
> the realities of IEEE 754 already know about 0 x -0. Those that don't
> should know (from basic math) that 0 == -0.

That's not much of a help if you have code like

local id
x = math.floor(x)
if x >= 0 then
id = "ident"..x
else
id = "ident_"..-x
end
print(string.format("  %s = %s + 1\n", id, id))

producing output like (when run after x = -0)

ident-0 = ident-0 + 1

which is a plain nuisance.  We are not talking about the situation where
a human reads some output and sees a "-0".  Much more important is the
situation where the computer tries doing something sensible with a
result.

> (And integer types would only make things worse from this point of
> view, as hardware-supported integer representations have even stranger
> behavior.)

Hm?  "hardware-supported integer representations" are usually at least a
commutative ring, having exactly one neutral element for addition,
whereas with floating point, you don't even get the associative law.

It is also extremely surprising that x == y does not imply
tostring(x) == tostring(y) when both x and y have been arrived
at using only operators with integer operands and integer results.

--
David Kastrup

```