29

There doesn't seem to be a clear answer to this in the documentation.

I'm interested in incrementing a variable time that counts the seconds since the program started. If the maximum value can count far into the future, like 100 years, then I don't care about letting the variable increment forever. Otherwise I'm going to have to think of a good point to reset time back to 0.

Kai
  • 9,444
  • 6
  • 46
  • 61

6 Answers6

41

as compiled by default, the Number is a double, on most compilers that's an IEEE 64-bit floating point. that means 10bit exponent, so the maximum number is roughly 2^1024, or 5.6e300 years. that's a long time.

now, if you're incrementing it, you might be more interested in the integer range. the 52-bit mantissa means that the highest number that can be used with integer precision is 2^52, around 4.5e15. At 31'557,600 seconds/year, that's 1.427e8, almost 150 million years. still a very long uptime for any process

update 2014-12-30: Lua 5.3 (to be released any moment now) adds support for integer values, either 32 or 64 bits chosen via compile flags.

Javier
  • 60,510
  • 8
  • 78
  • 126
  • 40
    Thanks, I can stand being hated by a few programmers 150 million years from now. – Kai Jun 03 '09 at 17:18
  • 4
    By the way, although it's a 52bit mantissa, there's an "extra" implicit bit of precision, so the highest you can increment by one is around 2^53. – Eloff Aug 11 '13 at 20:39
  • 2
    2^53 *is* the first number that will not increment. This is because the IEEE-754 mantissa has a "hidden" most significant bit that is assumed to be 1 if the exponent is not zero and is not the maximum exponent. When the value is 2^53, only that hidden bit is set, and the least significant bit is not stored, but its value is zero, so the value is still exactly correct. Incrementing that value increments that bit that is not stored, so there is no effect on the result. Note that higher values can be stored, but only the high 53 bits of them will be stored, lower bits will be zeroed. – doug65536 May 03 '16 at 07:52
12

Although tydok's reference to PiL 2.3 is both correct and apropos, and Javier's answer is in practice correct, I thought the discussion of numbers in Lua should be rounded out with a couple of other details.

The Lua interpreter is designed to be embedded in an application typically as a configuration and/or scripting language. When built for an application, it is common to configure some of its features to suit.

The exact numeric type to use for numbers is available for configuration. When compiling for a platform without hardware floating point where loading third-party modules is not important (especially in an embedded system or set-top box game console application) then it is reasonable to pick an integral type instead of the default double. Occasionally, switching to float is reasonable also.

However, there are applications where 64-bit integers are needed, or most numbers can be integers but occasional floating point arithmetic is required. For those cases, there is the LNUM patch to the Lua core.

LNUM changes the core so that numbers are stored as either integers or floating point, and allows several configurable selections for the precision of each.

So the bottom line answer to the question of the maximum value of a Lua number is that it depends on the configuration of the interpreter chosen at compile time, and whether you are worried about the maximum magnitude representable or the maximum integer. And even then, work has been done to make large integers play well with floating point representations.

Community
  • 1
  • 1
RBerteig
  • 41,948
  • 7
  • 88
  • 128
  • 3
    LNUM is great, both for speed on non-FPU processors (some ARMs go there), and for those rare occasions you really need 64-bit integer math. – Javier Jun 15 '09 at 16:08
4

This is the highest value mentioned in a few other answers. This is where the 1.8e308 comes from:

HighestNumber = 0
for i = 971, 1024 do
    HighestNumber = HighestNumber + (2 ^ i)
    print(HighestNumber)
end

LuaJIT result

Kokizzu
  • 24,974
  • 37
  • 137
  • 233
Niles S
  • 41
  • 1
1

Using Lua5.1 or Lua5.2

Maximum formatted number:

179769313486231570814527423731704356798070567525844996598917476803157260780028538760589558632766878171540458953514382464234321326889464182768467546703537516986049910576551282076245490090389328944075868508455133942304583236903222948165808559332123348274797826204144723168738177180919299881250404026184124858368

If you change the 68 to 69 at the end it still only shows 68. A number larger than the number above returns math.huge aka inf.

Which is equal to: 1.8x10^308 or just south of 2^1024.

Try it yourself:

print(string.format("%.0f",number))
Mossarelli
  • 319
  • 2
  • 8
1

I found this email on the lua users site

The Lua core does not make use of 64 bit datatypes, except implicitly through size_t or ptrdiff_t (which happen to be 64 bit on a 64 bit box).

sizeof( float ) == 4
sizeof( double) == 8

You can define lua_Number to be a double (default), float or any integer with at least 32 bits. There are side effects though and some extensions may cease to work due to the limited range of floats or ints. The core should be fine, though.

Ólafur Waage
  • 68,817
  • 22
  • 142
  • 198
0

I stumbled on this question since I had a very similar problem myself. I am currently programming with LÖVE2D, which uses LuaJIT that is based on Lua 5.1, hence no integers. My personal question was: can I use a single variable to track time?

For time, more than knowing which is the top value, you should ask yourself, first of all, what is the required level of precision, say down to milli-, centi- or deciseconds (1, 10 or 100 ms). Or even seconds. Why?

See, even though you can theoretically sum up thousands of years in seconds using the Lua 5.1 number limits, which are around 2^1024, the problem is that after some very long time (but it all depends which are your boundaries, what if you are dealing with an astronomy app?) your discrimination between moments will fall dramatically...

> t = 2^1023
> print(t)
8.9884656743116e+307
> print(t+1) -- let's assume your dt is of 1 second
8.9884656743116e+307

So at some point, even delta of seconds become meaningless. Therefore my suggestion is to check directly your limit with your required level of precision...

> a,b = 0,0.1 -- the precision is 100 ms
> while a~=b do a,b = b,b+1 end
interrupted!

I did not even wait to find up the limit, I just interrupted the loop, while still adding 0.1 to the previous moment changed the base value a.

> print(a/60/60/24/365) -- check current limit in years!
251.54387084919

So it is definitely safe to use a single variable to track time using Lua 5.1 and LuaJIT. Personally, since I am programming a general purpose framework, I preferred to divide seconds from smaller fractions to guarantee the maximum precision.

joricomico
  • 1
  • 1