81–90 of 161 posts
HN is more and more like first semester coding class where the professor always tells the "fun facts" but we have to be in the same class every year
>>> 0.1 + 0.2
0.30000000000000004
If you don't want this to happen, use fixed-point numbers, if they're supported by your language, or integers with a shifted decimal point.
Personally, I think if you don't know this, it's not safe for you to write computer programs professionally, because this can have real consequences when dealing with currency.
Earlier quoted context omitted.
Interval arithmetic is what you're looking for, and there's an IEEE standard and many implementations.
Thank you!! Yes, that turns out to be exactly it [1]. Looks like there's even at least one JavaScript library for it [2]. It seems like such a useful and intuitive idea I have to wonder why it isn't a primitive in any of the common programming languages. [1] https://en.wikipedia.org/wiki/Interval_arithmetic [2] https://github.com/mauriciopoppe/interval-arithmetic
With interval arithmetic, either a programmer would understand that floating point numbers are not actually numbers but intervals... or they wouldn't, and get surprised.
So I don't really see much upside. If you know that you need interval arithmetic, chances are that you're already using it.
Indeed, 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…
The equality test in floating point numbers is comparing against the epsilon.
Math.abs(0.3 - (0.1 + 0.2)) Using the epsilon for comparison is not mentioned in the article. Floating point absorption is also not mentioned in the article.
This entire discussion and the fact this is on the front page of HN is pretty disappointing and sad.
Is this really a surprise for you? if it is... have you ever implemented any logic involving currency? You may want to take another look at it.
Earlier quoted context omitted.
> It seems like such a useful and intuitive idea I have to wonder why it isn't a primitive in any of the common programming languages. It is basically useless for numerical computation when you perform iterations. Even good convergent algorithms can diverge with interval arithmetic. As you accumulate operations on the same numbers, their intervals become larger and larger, growing eventually to infinity. It has some…
But if the intervals are growing to infinity, then should you be trusting your result at all? Are there really cases where current FP arithmetic gives an accurate result, but where the error bounds of interval arithmetic would grow astronomically? It seems like you'd have to trust FP rounding to always cancel itself out in the long run instead of potentially accumulating more and more bias with each iteration. Is tha…
Most often, yes; the probability distribution of your number inside that interval is not uniform, it is most likely very concentrated around a specific number inside the interval, not necessarily its center. After a few million iterations, the probability of the correct number being close to the boundary of the interval is smaller than the probability of all your atoms suddenly rearranging themselves into an exact copy of Julius Caesar. According to the laws of physics, this probability is strictly larger than zero. Would you think it "unsafe" to ignore the likelihood of this event? I'm sure you wouldn't, yet it is certainly possible. Just like the correct number being near the boundaries of interval arithmetic.
Meanwhile, the computation using classical floating point, typically produces a value that is effectively very close to the exact solution.
> It seems like you'd have to trust FP rounding to always cancel itself out in the long run instead of potentially accumulating more and more bias with each iteration. Is that the case?
The whole subject of numerical analysis deals with this very problem. It is extremely well known which kinds of algorithms can you trust and which are dangerous (the so-called ill-conditioned algorithms).
Earlier quoted context omitted.
> Please, tell me, mister, how would you perform complex numerical calculations efficiently? If your calculation turned out to be incorrect it doesn't matter if it's efficient. Correct FP calculation requires error analysis, which is a concrete definition of "how to use it". If you mostly use packaged routines like LAPACK, then you don't exactly need FP; you need routines that internally use FP.
> Correct FP calculation requires error analysis No, it does not. Please, don't make it seem harder than it needs to. 99% applications, if you don't do anything stupid you are completely fine. If you care for precision so much the last digit make difference for you you are probably one of very few cases. I remember somebody giving an example circumference of solar system showing uncertainty of the value of Pi availab…
This is a common misconception. Or "anything stupid" is quite broader than you think.
The main issue with FP arithmetic is that effectively every calculation incurs an error. You seem to aware of catastrophic cancellation, but it is problematic not because of the cancellation but because the error is proportional to the input, which can wildly vary after the cancellation. Non-catastrophic cancellation can still cause big errors in a long run for a large range of magnitudes. A long-running process thus requires some guard against FP errors, even if it's just a reality check (like, every object in the game should be in a skybox).
Alternatively you do not run a long-running process. I don't think you fly a drone for days? Probably you won't fly a drone that long even without FP, but using FP does prohibit many things and thus affects your decision. For example game simulations tend to avoid FP because it can accumulate errors and it is also hard to do FP calculation in a repeatable way (in typical environments). If I chose to use FP for simulations I effectively give up running simulations both in servers and clients---that kind of things.
HN is more and more like first semester coding class where the professor always tells the "fun facts" but we have to be in the same class every year
Specifically I'm thinking about python, the literal x.x should be for Decimal and float should have to be imported to be used as an optimization if you need it.