[Date Prev][Date Next][Thread Prev][Thread Next]
[Date Index]
[Thread Index]
- 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
- References:
- Re: Lua minus null (-0), Dirk Laurie
- Re: Lua minus null (-0), Henk Boom
- Re: Lua minus null (-0), Dirk Laurie
- Re: Lua minus null (-0), Everett L Williams II
- Re: Lua minus null (-0), Dirk Laurie
- Re: Lua minus null (-0), David Kastrup
- Re: Lua minus null (-0), Dirk Laurie
- Re: Lua minus null (-0), David Kastrup
- Re: Lua minus null (-0), Dirk Laurie
- Re: Lua minus null (-0), David Kastrup
- Re: Lua minus null (-0), Roberto Ierusalimschy