4 ms·
I feel like that bug has more to do with Javascript's (and clearly Crockford's) inane desire to pretend it is the case that all numeric types are the same. Nob
by tel 13y ago
I feel like that bug has more to do with Javascript's (and clearly Crockford's) inane desire to pretend it is the case that all numeric types are the same.
Nobody who does anything with numbers believes that! Even if all you can do is count your fingers you believe in the difference between integers and floats. They have different algebraic properties entirely and it takes a whole hell of a lot of work to get from one to the other---there's even a whole class (fractions) in between.
- haberman 13y agoI'm not sure what that has to do with it. Even if you are ok with the idea that integers and "decimal numbers" are different, it's still confusing that 0.1 + 0.2 != 0.3. It's confusing because it is very difficult to look at a decimal number and know whether it can be represented exactly as base-2 floating point. It's especially confusing because you get no feedback about it! Here is a Ruby session: irb(main):001:0> 0.1 => 0.1 irb(main):002:0> 0.2 => 0.2 irb(main):003:0> 0.3 => 0.3 irb(main):004:0> 0.4 => 0.4 irb(main):005:0> 0.5 => 0.5 They all look exact, right? Well actually only 0.5 is (IIRC?). All the others are actually approximations internally.
- StefanKarpinski 13y agoThe problem here is that Ruby is lying to you – if you enter 0.3 as a literal, you will not get that value.
- haberman 13y agoI would challenge you to name any software system that reliably shows you the precise value of a floating point number. I couldn't find any (like not a single one), so I wrote a program myself to do it: http://blog.reverberate.org/2012/11/dumpfp-tool-to-inspect-floating-point.html http://blog.reverberate.org/2012/11/dumpfp-tool-to-inspect-f...
- StefanKarpinski 13y agoPython, JavaScript V8, Julia, Java.
- giovannibajo1 13y agoPython doesn't: rasky at monocle in ~ ↪ python Python 2.7.5 (default, Sep 2 2013, 05:24:04) [GCC 4.2.1 Compatible Apple LLVM 5.0 (clang-500.0.68)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> 0.1 0.1 >>> ^D rasky at monocle in ~ ↪ python3 Python 3.3.3 (default, Dec 24 2013, 13:54:32) [GCC 4.2.1 Compatible Apple LLVM 5.0 (clang-500.2.79)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> 0.1 0.1 It used to, but it was changed to reduce users' confusion.
- StefanKarpinski 13y agoWe may be speaking across each other here. Ruby is lying in the sense that there are multiple distinct float values that it will print as 0.3 – in particular, confusion ensues when two values look the same but are unequal. These other languages print each distinct float value differently, using just enough decimal digits to reconstruct the exact binary value. Ruby doesn't give you enough digits to reconstruct the value you have. Nobody actually prints the full correct value because it's fifty digits long and is completely redundant given that you know you're dealing with a 64-bit float.
- kzrdude 13y agoYou're right. Python 3.3.5rc1 (default, Feb 23 2014, 17:44:29) >>> 0.3 == 0.2 + 0.1 False >>> 0.2 + 0.1 0.30000000000000004 >>> 0.3 0.3
- haberman 13y agoThe precise value of double(0.1) is 0.1000000000000000055511151231257827021181583404541015625. That is precise, not an approximation. If you know of a program in any of these languages that will print this value for "0.1" using built-in functionality, please let me know because I would love to know about it. Likewise the precise value of double(1e50) is 100000000000000007629769841091887003294964970946560. Anything else is an approximation of its true value. In another message you said that what's really important is that the string representation uniquely identifies the precise value. While that will help you reconstruct the value later, it does not help you understand why 0.1 + 0.2 != 0.3.
- tel 13y agoYeah, that's my point. 0.1 and 0.2 do add exactly to 0.3, but in any finite representation of real numbers you'll get rounding errors on some equations like this. If you use an infinite representation then equality is no longer computable.