2

It seems like Lua addition is not working when dealing with large numbers (64bit values). I have tried to compute the following:

71776119061217280 + 281474976710655

or in hexa

  0x00FFFFFFFFFFFF‬
+ 0x‭FF000000000000

Lua 5.1, 5.2, and 5.3 all return

72057594037927936 (= 0x‭100000000000000)

No need to take out your calculator to see that this is wrong. An even number added to an odd number is not an even number. As a matter of fact, it seems to be off by 1 (the right result is 72057594037927935). In hexa the problem is even more obvious since the result should be 0xFFFFFFFFFFFFFF. Anyone knows what's happening, or what I would be doing wrong here?

Update:

For info, I am seeing this with ZeroBrane Studio on Windows 10.

Community
  • 1
  • 1
MarkoPaulo
  • 474
  • 4
  • 19
  • I also encounter this large number bug when using Lua on Windows. But if I'm using Cygwin Lua, it return the correct number. I think it may has something to do with the build flag that can support large integer. – dns Jun 14 '18 at 07:29

2 Answers2

2

What subversion of Lua 5.3? As on a linux (amd64) machine, I get: 

$ lua
Lua 5.3.4  Copyright (C) 1994-2017 Lua.org, PUC-Rio
> 71776119061217280 + 281474976710655
72057594037927935
>
Timothy Brown
  • 2,220
  • 18
  • 22
  • Very interesting. I am using [Zerobrane Studio](https://studio.zerobrane.com) to work with Lua. And from there I am not able to run the lua command. So I opened the lua53.exe directly, tried to compute 71776119061217280 + 281474976710655 and it gave me the right answer. I'm starting to suspect there's a bug in Zerobrane Studio. – MarkoPaulo Mar 04 '18 at 18:16
  • Very strange indeed. Not too sure how an IDE can give you the error. – Timothy Brown Mar 04 '18 at 18:24
1

These are the results that I get using Lua interpreters included with ZeroBrane Studio for this script:

print(("%.17g"):format(71776119061217280 + 281474976710655))
print(71776119061217280 + 281474976710655)

Lua 5.1 (it's actually LuaJIT interpreter):

72057594037927936
7.2057594037928e+016

Lua 5.2:

72057594037927936
7.2057594037928e+016

Lua 5.3

72057594037927936
72057594037927935

If you run this in the Local console in the IDE, then you'll see 72057594037927936, as it's using %.17g format during serialization of the results.

The local console always uses the interpreter the IDE is executed with, which is Lua 5.1 (actually LuaJIT) on all platforms, so this is maybe where the confusion about the results is coming from. Setting the interpreter only changes what's used for Running and Debugging scripts, but not the Local console (at least in the current version, as there are tickets that may change that). This should not affect the tooltip and stack/watch windows, as they use %.16g format, which can be changed using debugger.numformat setting; the console is the only place where %.17g format is used as it's the one recommended to avoid losing precision.

Paul Kulchenko
  • 25,884
  • 3
  • 38
  • 56
  • Hi Paul thanks a lot for the quick reply. I didn't think you'd catch up on the zerobrane tag this fast! I get the same results as you do there. However the problem is that if you open C:\Program Files (x86)\ZerobraineStudio\bin\lua53.exe (windows 10 case) and run the same commands, the results are correct. If the interpreter of the IDE is set to lua 5.3, wouldn't it be using the executable I mentioned to do the computation? If so, how would the results be any different in the IDE as opposed the the lua 53 executable? – MarkoPaulo Mar 04 '18 at 19:03
  • 1
    The local console always uses the interpreter the IDE is executed with, which is Lua 5.1 (actually LuaJIT) on all platforms, so this is maybe where the confusion is coming from. Setting the interpreter only changes what's used for Running and Debugging scripts, but not the Local console (at least in the current version, as there are tickets that may change that). – Paul Kulchenko Mar 04 '18 at 19:24
  • Paul if you wanna write this as an answer, I'll mark the question as answered. One thing I would like to mention is that if I am in the middle of a script and look at the value of a variable that is large enough, the value will also appear wrong in the tooltip. With the answers you've provided I realize that all this is due to serialization, and the value stored in memory is actually correct. – MarkoPaulo Mar 04 '18 at 19:29