41–50 of 161 posts
> all.equal(0.1+0.2,0.3)
[1] TRUE
> identical(0.1+0.2,0.3)
[1] FALSEIndeed, and therefore: 0.1 + 0.2 != 0.3 You can check it in the JavaScript console. This actually makes me wonder if anyone's ever attempted a floating-point representation that builds in an error range , and correctly propagated/amplified error over operations. E.g. a simple operation like "1 / 10" (to generate 0.1) would be stored not as a single floating-point value, but really as the range between the closest rep…
That sounds interesting, but I would imagine it would become very complicated once you start applying nontrivial functions (discontinuous functions, for example). In that case the range of possible values could actually become discontinuous. I would imagine accounting for that is actually more computationally expensive than just using arbitrary precision decimals.
Does this mean I could write a calculator in JavaScript which is more accurate than the language but not as fast? For example: just treat numbers as strings and write code that adds the digits one by one and does the right carries Now that I think about it, is this the whole point of the Java BigDecimal class?
Floating point considered harmful Edit: this is not a blanket statement. It was meant in the context.
This just has to do with printing. This is the TXR Lisp interactive listener of TXR 256. Quit with :quit or Ctrl-D on an empty line. Ctrl-X ? for cheatsheet. TXR works even if the application surface is not free of dirt and grease. 1> (+ 0.1 0.2) 0.3 OK, so then: 2> (set *print-flo-precision* 17) 17 3> (+ 0.1 0.2) 0.30000000000000004 But: 4> 0.1 0.10000000000000001 5> 0.2 0.20000000000000001 6> 0.3 0.2999999999999999…
I think the problem is the act of caring for the least significant bits.
If you care for least significant bits of a floating point number it means you are doing something wrong. FP numbers should be treated as approximations.
More specifically, the problem above is assuming that floating point addition is associative to the point of giving you results that you can compare. In floating point order of operations matters for the least significant bits.
FP operations should be treated as incurring inherent error on each operation.
IEEE standard is there to make it easier to do repeatable calculations (for example be able to find regression in your code, compare against another implementation) and for you to be able to reason about the magnitude of the error.
Golly. Surprised by floating point arithmetic? 1.99999999.... == 2.0 There are limits to computer representation of floating point numbers. Computers are finite state, floating point numbers are not. sigh
Floating point numbers are one way of approximating real numbers on computers.
Golly. Surprised by floating point arithmetic? 1.99999999.... == 2.0 There are limits to computer representation of floating point numbers. Computers are finite state, floating point numbers are not. sigh
You mean "real numbers". Floating point numbers are one way of approximating real numbers on computers.
Earlier quoted context omitted.
Floating point is fine. Non-integers are inherently tricky to represent, especially when you have to pack it into 32 bits. You could maybe quibble with some of the decisions around NaN and denormals and things like that, but mostly IEEE-754 got it right. There's a reason it's been the standard for three and a half decades now, and it's served the computer industry very well. Incidentally: the fact that 0.1+0.2 does n…
I think one of the problems today is that floating point remains the default even for scripting languages like python. I'd wager that the huge majority of users of floating point arithmetic in their programs actually want correct math rather than efficient operations. This feels a bit like Random vs SecureRandom. So many people use the default and then accidentally shoot themselves in the foot. IMO, for scripting lan…
- Keep rational numbers; you also have an unbounded integer so that's to be expected. (Well, unbounded integers are visible, while unbounded denominators are mostly invisble. For example it is very rare to explicitly test denominators.)
- Use decimal types with precision controlled in run time, like Python `decimal` module. (That's still inexact, also we need some heavy language and/or runtime support for varying precision.)
- Use interval arithmetic with ordinary floating point numbers. (This would be okay only if every user knows pitfalls of IA: for example, comparison no longer returns true or false but also "unsure". There may be some clever language constructs that can make this doable though.)
- You don't have real numbers, just integers. (I think this is actually okay for surprisingly large use cases, but not all.)
[1] https://python-history.blogspot.com/2009/02/early-language-d... (search for "anecdote")
Earlier quoted context omitted.
I think one of the problems today is that floating point remains the default even for scripting languages like python. I'd wager that the huge majority of users of floating point arithmetic in their programs actually want correct math rather than efficient operations. This feels a bit like Random vs SecureRandom. So many people use the default and then accidentally shoot themselves in the foot. IMO, for scripting lan…
What precise number representation do you want that's free of such "surprises"?
The closest you can get is some systems like Matlab/Octave that specialize in working with numbers.