Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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?

share|improve this question
    
See also stackoverflow.com/questions/1848700/… –  Joonas Pulakka Jul 29 '13 at 6:33
    
@JoonasPulakka thanks, that is quite valuable addition. –  Petr Abdulin Jul 29 '13 at 14:58

2 Answers 2

up vote 9 down vote accepted

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?

share|improve this answer
    
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 '13 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. –  Robert Harvey Jul 29 '13 at 15:45
    
Agreed. Doesn't make any sense to me. I wonder if it's taken out of context... –  Andres F. Jul 29 '13 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. –  Keith Thompson Jul 29 '13 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. –  Robert Harvey Jul 29 '13 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.

share|improve this answer
    
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. –  Robert Harvey Jul 29 '13 at 15:48
2  
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. –  Karl Bielefeldt Jul 29 '13 at 15:57
2  
Yes, exactly. But not repeating in base 10. Repeating in base 2. –  Robert Harvey Jul 29 '13 at 16:02

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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