tostring and 0

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

tostring and 0

Valeriy Skurikhin
Hi, list!

Recently I found, that results of tostring(0) and tostring(-0) may
depend on call order.

Lua 5.1.4  Copyright (C) 1994-2008 Lua.org, PUC-Rio
> return (tostring(0) .. tostring(-0))
00
> return (tostring(-0) .. tostring(0))
-0-0

A bit confusing behaviour. And it was chnanged in Lua 5.2:

Lua 5.2.0  Copyright (C) 1994-2011 Lua.org, PUC-Rio
> return (tostring(0) .. tostring(-0))
0-0
> return (tostring(-0) .. tostring(0))
-00

I believe this feature is known to the community, but I didn't manage
to find any clear anwser, whether it should be considered as a bug or
not. Could someone give me any reference, please?

Regards,
Valeiry

Reply | Threaded
Open this post in threaded view
|

Re: tostring and 0

Drake Wilson
Quoth Valeriy Skurikhin <[hidden email]>, on 2012-04-27 16:57:42 +0700:
> Recently I found, that results of tostring(0) and tostring(-0) may
> depend on call order.
>
> Lua 5.1.4  Copyright (C) 1994-2008 Lua.org, PUC-Rio
> > return (tostring(0) .. tostring(-0))
> 00
> > return (tostring(-0) .. tostring(0))
> -0-0

It looks like Lua is merging positive and negative zero in the
constant vector:

| $ cat negzero.lua
| print(tostring(0)..tostring(-0))
| print(tostring(-0)..tostring(0))
| $ lua negzero.lua
| 00
| 00
| $ luac -v
| Lua 5.1.5  Copyright (C) 1994-2012 Lua.org, PUC-Rio
| $ luac -l negzero.lua
|
| main <negzero.lua:0,0> (19 instructions, 76 bytes at 0x17ce530)
| 0+ params, 4 slots, 0 upvalues, 0 locals, 3 constants, 0 functions
|         1       [1]     GETGLOBAL       0 -1    ; print
|         2       [1]     GETGLOBAL       1 -2    ; tostring
|         3       [1]     LOADK           2 -3    ; 0
|         4       [1]     CALL            1 2 2
|         5       [1]     GETGLOBAL       2 -2    ; tostring
|         6       [1]     LOADK           3 -3    ; 0
|         7       [1]     CALL            2 2 2
|         8       [1]     CONCAT          1 1 2
|         9       [1]     CALL            0 2 1
|         10      [2]     GETGLOBAL       0 -1    ; print
|         11      [2]     GETGLOBAL       1 -2    ; tostring
|         12      [2]     LOADK           2 -3    ; 0
|         13      [2]     CALL            1 2 2
|         14      [2]     GETGLOBAL       2 -2    ; tostring
|         15      [2]     LOADK           3 -3    ; 0
|         16      [2]     CALL            2 2 2
|         17      [2]     CONCAT          1 1 2
|         18      [2]     CALL            0 2 1
|         19      [2]     RETURN          0 1

Whether this is incorrect depends on whether Lua numbers are
semantically required to have positive and negative zero be distinct
when using doubles underneath.  A Lua with a different numeric type
might well have only a single zero anyway.

   ---> Drake Wilson

Reply | Threaded
Open this post in threaded view
|

Re: tostring and 0

Tony Finch
In reply to this post by Valeriy Skurikhin
Valeriy Skurikhin <[hidden email]> wrote:
>
> Recently I found, that results of tostring(0) and tostring(-0) may
> depend on call order.

Actually what you are observing is the way Lua stores literal constants.
Since +0 and -0 compare equal, only one of them is retained when the
script is compiled.

Tony.
--
f.anthony.n.finch  <[hidden email]>  http://dotat.at/
West Bailey: Northerly 4 or 5, becoming variable 3 or 4, then southwesterly 4
or 5, occasionally 6 later. Rough becoming moderate. Fair. Good.

Reply | Threaded
Open this post in threaded view
|

Re: tostring and 0

Luiz Henrique de Figueiredo
In reply to this post by Drake Wilson
> It looks like Lua is merging positive and negative zero in the  constant vector:

That is correct. It has been reported here before.

Reply | Threaded
Open this post in threaded view
|

Re: tostring and 0

Valeriy Skurikhin
2012/4/27 Luiz Henrique de Figueiredo <[hidden email]>:
>> It looks like Lua is merging positive and negative zero in the  constant vector:
>
> That is correct. It has been reported here before.
>

I found the post, where it was mentioned. Not an obvious behaviour.  Thank you.

Regards,
Valeriy