0

127.0.0.1:7501> eval "return {1,2,9223372036854775807}" 0
1) (integer) 1
2) (integer) 2
3) (integer) -9223372036854775808

Please help this weird behaviour. I knew that lua can only represent large number beyond 10^15 , by losing some precision. I would have expected a return value as "9.2233720368548e+18" but not a negative number.

Also fyi 127.0.0.1:7501> eval "return {1,2,tostring(9223372036854775807)}" 0
1) (integer) 1
2) (integer) 2
3) "9.2233720368548e+18"

127.0.0.1:7501> eval "return {1,2,tonumber(9223372036854775807)}" 0
1) (integer) 1
2) (integer) 2
3) (integer) -9223372036854775808

sumanth232
  • 587
  • 7
  • 20

1 Answers1

5

Taken from the doc pages (https://redis.io/commands/eval):

Lua has a single numerical type, Lua numbers. There is no distinction between integers and floats. So we always convert Lua numbers into integer replies, removing the decimal part of the number if any. If you want to return a float from Lua you should return it as a string, exactly like Redis itself does (see for instance the ZSCORE command).

The number you're using (~10^19) is too big to be represented in Lua as an integer, so it becomes a float. When it is translated to an integer by the Redis type conversion, it overflows and becomes an negative value.

Itamar Haber
  • 47,336
  • 7
  • 91
  • 117
  • May I know, why it overflows, when the sign bit is positive in the double, when it is returned to redis. – sumanth232 Dec 18 '17 at 05:15
  • 1
    Integer and floating point encodings are different and this type conversion defaults to integer unless explicitly using `tostring`. Using an FP encoding as a representation for a signed integer has unexpected results. – Itamar Haber Dec 18 '17 at 17:52
  • updated link to that paragraph : https://redis.io/docs/manual/programmability/lua-api/ – Bruno Degomme Oct 21 '22 at 06:49