As far as I remember myself programming I was taught not to compare floating point numbers for equality. Now, while reading Programming in Lua about Lua number type, I found following:

The number type represents real (double-precision floating-point) numbers. Lua has no integer type, as it does not need it. There is a widespread misconception about floating-point arithmetic errors and some people fear that even a simple increment can go weird with floating-point numbers. The fact is that, when you use a double to represent an integer, there is no rounding error at all (unless the number is greater than 100,000,000,000,000). Specifically, a Lua number can represent any long integer without rounding problems. Moreover, most modern CPUs do floating-point arithmetic as fast as (or even faster than) integer arithmetic.

Is that true for all languages? Basically if we don't go beyond floating point in doubles, we are safe in integer arithmetic? Or, to be more in line with question title, is there anything special that Lua does with its number type so it's working fine as both integer and float-point type?


2 Answers 2


Lua claims that floating point numbers can represent integer numbers just as exactly as integer types can, and I'm inclined to agree. There's no imprecise representation of a fractional numeric part to deal with. Whether you store an integer in an integer type, or store it in the mantissa of a floating point number, the result is the same: that integer can be represented exactly, as long as you don't exceed the number of bits in the mantissa, + 1 bit in the exponent.

Of course, if you try to store an actual floating-point number (e.g. 12.345) in a floating point representation, all bets are off, so your program has to be clear that the number is really a genuine integer that doesn't overflow the mantissa, in order to treat it like an actual integer (i.e. with respect to comparing equality).

If you need more integer precision than that, you can always employ an arbitrary-precision library.

Further Reading
What is the maximum value of a number in Lua?

  • What about their second argument, i.e. that floating point is as fast or faster than integer arithmetic in modern CPUs? Sounds dubious to me, even when using floating point numbers to perform integer arithmetic.
    – Andres F.
    Jul 29, 2013 at 15:44
  • 2
    @AndresF. I don't see how it's faster, unless you're eliminating a cast by using a single numeric type instead of two. Jul 29, 2013 at 15:45
  • Agreed. Doesn't make any sense to me. I wonder if it's taken out of context...
    – Andres F.
    Jul 29, 2013 at 17:32
  • 1
    Sufficiently big integers can't be stored exactly in a floating-point object. A 64-bit double has about 51 or so mantissa bits; odd integers bigger than about 2**51 will have roundoff errors. A 64-bit integer can store larger integer values exactly, since it doesn't devote any bits to an exponent. Jul 29, 2013 at 19:16
  • @KeithThompson: I thought that was implied in my answer when I said "stored in the mantissa." However, I'll edit the answer to clarify. Jul 29, 2013 at 19:18

Doubles are stored as a mantissa and an exponent. See the format for more information. Basically, all numbers are of the form: mantissa * 2exponent. For any integer smaller than 252, the exponent will be zero, making the mantissa bit-for-bit equivalent to a 52-bit unsigned integer. A separate sign bit is used to indicate negative numbers.

In fact, even some integers larger than 252 can be represented exactly, as long as all the digits past the 52nd are zeros. Also, some fractions, like 0.5, can be represented exactly. It's only when the fraction is continuously repeating (like 1/3) in base 2, or otherwise requires too many bits past the radix point that you lose precision.

  • It's not because of continuously repeating decimals. It's because many decimal (base ten) numbers cannot be represented exactly as a power of two. Jul 29, 2013 at 15:48
  • 3
    In base 2, numbers that can't be represented exactly would be continuously repeating. For example, 0.1 decimal becomes 0.0(0011) in binary, with the 0011 continuously repeating. Jul 29, 2013 at 15:57
  • 3
    Yes, exactly. But not repeating in base 10. Repeating in base 2. Jul 29, 2013 at 16:02

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.