Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

0.1 and 0.2 Returns 0.30000000000000004 (2018)

qntm.org

Post reply on HN
Print view View original

71–80 of 161 posts

Re: 0.1 and 0.2 Returns 0.30000000000000004 (2018)

#71

Post by klyrs »

crazygringo wrote: post #53
OskarS wrote: post #42

Earlier quoted context omitted.

Yeah, you call tan() on that number, and suddenly your interval is like most of the number line. Actually, you don't even have to be that fancy: if the number is close to epsilon, the error bars on 1/x would be huge.

But isn't that a feature, rather than a bug? It prevents you from getting "false accuracy".

Yes, that's a feature. If you're using interval arithmetic and your result is an unreasonably large interval, then there's a good chance the algorithm in use is numerically unstable.

Re: 0.1 and 0.2 Returns 0.30000000000000004 (2018)

#72

Post by [deleted] »

yarg wrote: post #67
OskarS wrote: post #42

Earlier quoted context omitted.

Yeah, you call tan() on that number, and suddenly your interval is like most of the number line. Actually, you don't even have to be that fancy: if the number is close to epsilon, the error bars on 1/x would be huge.

Sure, but what's the use case for mathematics where you don't know what side of an asymptote you're on?

[deleted]

Re: 0.1 and 0.2 Returns 0.30000000000000004 (2018)

#74

Post by lmilcin »

lifthrasiir wrote: post #63
lmilcin wrote: post #12

Earlier quoted context omitted.

"People repeating stuff without understanding it considered harmful." Floating point is extremely useful. Too bad so many people have no idea how and when to use it. Including some people that design programming languages. Please, tell me, mister, how would you perform complex numerical calculations efficiently? I guess we should just forget about drones and bunch other stuff because 90% of developers have no clue ho…

> 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 available as FP to cause couple centimeters of error at the orbit of Pluto, or something like that.

(Edit: found it: https://kottke.org/16/03/how-many-digits-of-pi-does-nasa-use)

Most of the time floating point input is already coming with its own error, you are just adding calculation error to the input uncertainty. But the calculation error is so much smaller than in most cases it is safe to ignore it.

For example, if you program a drone, you have readings from IMU which have not nearly the precision of the double or even float you will be working on.

There is also various techniques of ordering the operations to minimize the resulting error. If you are aware which kinds of operations in which situations can cause huge resulting error it is usually very easy to avoid it.

Only very special case is if you try to subtract two values calculated separately and matching almost exactly. This should be avoided.

Re: 0.1 and 0.2 Returns 0.30000000000000004 (2018)

#75

Post by teachingassist »

arduinomancer wrote: post #25

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?

You can likely do better than this within rational numbers by working with integer numerator and denominator; you'll still have to make compromises for irrational numbers.

Re: 0.1 and 0.2 Returns 0.30000000000000004 (2018)

#76

Post by crazygringo »

enriquto wrote: post #66
crazygringo wrote: post #52

Earlier quoted context omitted.

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

> 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 that the case?

Wouldn't the "niche" case be the opposite -- that interval arithmetic is the general-purpose safe choice, while FP algorithms without it should be reserved for those which have been mathematically proven not to accumulate FP error? (And would ideally output their own bespoke, proven, interval?)

Re: 0.1 and 0.2 Returns 0.30000000000000004 (2018)

#77

Post by crazygringo »

gugagore wrote: post #65
crazygringo wrote: post #52

Earlier quoted context omitted.

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

Interval arithmetic certainly has its place. However, you don't find it used more often because a naive implementation results in intervals that are often uselessly huge. Consider x in [-1, 1], and y in [-1, 1]. x*y is also in [-1,1], and x-y in [-2, 2]. But now consider actually that y=x. That's consistent, but our intervals could be smaller than what we've computed.

Sure, but wouldn't realistic intervals be more like x in [0.29999999999999996, 0.30000000000000004]?

I mean, intervals as large as whole numbers might make sense if your calculations are dealing with values in the trillions and beyond... but isn't the point of interval arithmetic to deal with the usually tiny errors that occur in FP representation?

Re: 0.1 and 0.2 Returns 0.30000000000000004 (2018)

#78

Post by lifthrasiir »

young_unixer wrote: post #69
lifthrasiir wrote: post #57

Earlier quoted context omitted.

It is the shortest decimal number that converts back to that exact FP number. There are tons of complex algorithms for that [1]. [1] See my past comment for the overview: https://news.ycombinator.com/item?id=26054079

Isn't that essentially lying to the user?

0.299999999999999988897769753748434595763683319091796875 suggests 54 fractional digits of precision, which is misleading.

0.29999999999999998 or 0.29999999999999999 are less misleading but wasteful. Remember they are not only visible to users but can be serialized in decimal representations (thanks to, e.g. JSON).

In fact, most uses of FP are essentially lies, providing an illusion of real numbers with a limited storage. It is just a matter of choosing which lie to keep.

Re: 0.1 and 0.2 Returns 0.30000000000000004 (2018)

#80

Post by spicybright »

jeffbee wrote: post #29
arduinomancer wrote: post #25

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?

Yes, and it would be inexcusable malpractice to implement a calculator using the native floating-point type.

lol, malpractice. What if you want a calculator that specifically uses native floating point math, like to aid in programming, or just playing with the datatype?
Post reply on HN