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.
7 Answers 7
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.
-
43Thanks, I can stand being hated by a few programmers 150 million years from now.Kai– Kai2009年06月03日 17:18:48 +00:00Commented Jun 3, 2009 at 17:18
-
4By 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– Eloff2013年08月11日 20:39:36 +00:00Commented Aug 11, 2013 at 20:39
-
22^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– doug655362016年05月03日 07:52:19 +00:00Commented May 3, 2016 at 7:52
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.
-
3LNUM 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– Javier2009年06月15日 16:08:34 +00:00Commented Jun 15, 2009 at 16:08
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
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
orptrdiff_t
(which happen to be 64 bit on a 64 bit box).sizeof( float ) == 4
sizeof( double) == 8You 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.
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))
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.
To find the highest loopable number 9007199254740991, here is the code:
local nextHighestNumber
local highestNumber = (2 ^ 53) - 3
for i = 1, 1024 ^ 10 do
nextHighestNumber = highestNumber + 1
if highestNumber >= nextHighestNumber then
highestNumber = highestNumber - 1
print(string.format("break at loop %d, highest number: %.0f, next highest number: %.0f", i, highestNumber, nextHighestNumber))
break
end
highestNumber = nextHighestNumber
end
-- highestNumber = 9007199254740991
highestNumber = highestNumber - 3
local prevHighestNumber = highestNumber - 1
print(string.format("%.0f", highestNumber))
while highestNumber > prevHighestNumber do
prevHighestNumber = highestNumber
highestNumber = highestNumber + 1
print(string.format(" %.0f", highestNumber))
end
print(string.format("highest loopable number: %.0f", prevHighestNumber - 1))