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

141–150 of 161 posts

Re: 0.1 and 0.2 Returns 0.30000000000000004 (2018)

#141

Post by dataflow »

crazygringo wrote: post #135
dataflow wrote: post #134

Earlier quoted context omitted.

No, but I'm out of ideas for how to explain it any more clearly. If you really think this is all correct behavior and IA is going to make your life better, start using it in production and you'll learn it the hard way.

I guess I just don't see why it's worse than FP. I mean, you said: > Contrast this with just leaving it as a float instead of an interval, where you would've gotten the correct answer. But if I type into my console: var a = 0.1; var b = a + 0.2; b -= 0.2; b == a; I get false. That's not correct. Whereas if "==" checked for overlap between intervals, it would be true. Which would be correct. Heck, to use your own divi…

Turns out Wikipedia has a decent article on this; you might want to check it out: https://en.wikipedia.org/wiki/Interval_arithmetic#Dependency...

Re: 0.1 and 0.2 Returns 0.30000000000000004 (2018)

#142

Post by eithed »

enriquto wrote: post #86
crazygringo wrote: post #76

Earlier quoted context omitted.

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…

> But if the intervals are growing to infinity, then should you be trusting your result at all? 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…

With large integers - no, ie:

`Math.pow(2, 55)+1 === Math.pow(2, 55)` returning true

Re: 0.1 and 0.2 Returns 0.30000000000000004 (2018)

#143

Post by soegaard »

neilv wrote: post #105
vincent-manis wrote: post #100

Earlier quoted context omitted.

A Scheme system that implemented exact reals as unnormalized floating decimal (IEEE 754-2008), coupled with a directive that said `numbers with a decimal point should/should not be read as exact' would be wonderful, not just for financial things, but also for teaching students.

It's actually easy to implement that slight variation in Racket, as a `#lang` or reader extension. As an example of a Scheme-ish `#lang`, here's a Racket `#lang sicp` that I made to mimic MIT Scheme, as well as add a few things needed for SICP: https://github.com/sicp-lang/sicp/blob/master/sicp/main.rkt It would be even easier to make a `#lang better-scheme`, by defining just a few changes relative to `racket-base`,…

The reader even has a parameter `read-decimal-as-inexact` that controls how to read decimal numbers.

Re: 0.1 and 0.2 Returns 0.30000000000000004 (2018)

#144

Post by slavik81 »

worik wrote: post #140
caf wrote: post #92

Earlier quoted context omitted.

I understand the confusion. It occurs when people haven't fully grokked that floating point numbers generally use binary representation, and that the set of numbers that can be represented with a finite number of decimal digits is distinct from the set of numbers that can be represented with a finite number of binary digits . People generally know that they can't write down the decimal value of 1÷3 exactly - they jus…

Sigh The representation means that 2.9999999999 = 3.00000000 I am not confused. You cannot use equality in floating point. Why is anybody surprised by that? That is my point (I did say floating point before when I ment real. A bit confused!)

> You cannot use equality in floating point.

Sure you can. 1.0 + 2.0 == 3.0. There's a lot of gotchas, but it is possible to make useful comparisons.

Re: 0.1 and 0.2 Returns 0.30000000000000004 (2018)

#145

Post by caf »

worik wrote: post #140
caf wrote: post #92

Earlier quoted context omitted.

I understand the confusion. It occurs when people haven't fully grokked that floating point numbers generally use binary representation, and that the set of numbers that can be represented with a finite number of decimal digits is distinct from the set of numbers that can be represented with a finite number of binary digits . People generally know that they can't write down the decimal value of 1÷3 exactly - they jus…

Sigh The representation means that 2.9999999999 = 3.00000000 I am not confused. You cannot use equality in floating point. Why is anybody surprised by that? That is my point (I did say floating point before when I ment real. A bit confused!)

Don't sigh melodramatically at me.

I wasn't saying you were confused, I was saying I believe I understand how the general confusion around the whole issue arises.

(If decimal floating point had been commonly used instead of binary, the same class of issues would still exist, but I don't think people would be nearly so surprised by them).

Re: 0.1 and 0.2 Returns 0.30000000000000004 (2018)

#146

Post by ChrisLomont »

OskarS wrote: post #28
ChrisLomont wrote: post #22

Earlier quoted context omitted.

Because that syntax in raku uses rational type, which fails for many other uses, and by using the syntax most languages use for a floating type, makes it harder to spot these issues, just like here. For example, 0.1e0 + 0.2e0 yields 0.30000000000000004. Your example also fails 1.1e0 + 2.2e0 == 3.3e0 returns false.

I mean, yeah, if you force the numbers to be floats, then of course it's going to fail. I personally think Raku's way of defaulting to floats is the better way to go for a scripting language like this, and I disagree that "it fails for many other uses". It works just fine (like, it doesn't break if you pass it to sqrt() or whatever), it's just less performant. It's the exact same kind of tradeoff that Python's implic…

>I disagree that "it fails for many other uses"

Having developed a significant amount of perfect precision math libs over the years, rationals do explode for lots of common computations. That is the main reason they are not standard in all computing. They also cannot represent a lot of desired results.

The problem is rational number performance slows exponentially (or uses large amounts of RAM) for many common uses, which will kill scripts, unless they suddenly fix precision (i.e., no longer exact) or change to float (also a surprise for people).

Setting them as floats has the odd numerical issue, which is not that bad, but doesn't require a host of other mitigations to prevent other bad surprises.

For example, summing 1/n^2 for n=1 to 100000 as floats runs quickly and is very close to the exact answer. As rationals the numerator and denominator require working with 86000 digit numbers.

Also, does raku still do this?

say (1/6+1/6).raku #

say (1/10+1/10).raku #0.2

That seems surprising, does it not?

Re: 0.1 and 0.2 Returns 0.30000000000000004 (2018)

#147

Post by crazygringo »

dataflow wrote: post #141
crazygringo wrote: post #135

Earlier quoted context omitted.

I guess I just don't see why it's worse than FP. I mean, you said: > Contrast this with just leaving it as a float instead of an interval, where you would've gotten the correct answer. But if I type into my console: var a = 0.1; var b = a + 0.2; b -= 0.2; b == a; I get false. That's not correct. Whereas if "==" checked for overlap between intervals, it would be true. Which would be correct. Heck, to use your own divi…

Turns out Wikipedia has a decent article on this; you might want to check it out: https://en.wikipedia.org/wiki/Interval_arithmetic#Dependency...

Ah, thanks for that, I finally understand what you were getting at. I see now what you mean about intervals growing larger than they actually need to in formulas that use the same variable more than once, that is an unfortunate drawback.

Now you've got me learning about how affine arithmetic can help with the dependency problem but has its own drawbacks. Thanks for pointing me in that direction!

Re: 0.1 and 0.2 Returns 0.30000000000000004 (2018)

#148

Post by neilv »

soegaard wrote: post #143
neilv wrote: post #105

Earlier quoted context omitted.

It's actually easy to implement that slight variation in Racket, as a `#lang` or reader extension. As an example of a Scheme-ish `#lang`, here's a Racket `#lang sicp` that I made to mimic MIT Scheme, as well as add a few things needed for SICP: https://github.com/sicp-lang/sicp/blob/master/sicp/main.rkt It would be even easier to make a `#lang better-scheme`, by defining just a few changes relative to `racket-base`,…

The reader even has a parameter `read-decimal-as-inexact` that controls how to read decimal numbers.

Good point. For exacts in `#lang`, I realized afterwards that it's not just literals/self-evals: there's some "standard library" functions you'd probably want to wrap, to force them to produce exact numbers. And maybe check that there's nothing in standard library that does inexacts internally in a way that would be unpredictable to a programmer who expects exact number behavior.

Re: 0.1 and 0.2 Returns 0.30000000000000004 (2018)

#149

Post by Dylan16807 »

wruza wrote: post #108
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…

What makes you think that everyone around is concerned with efficiency? With FP as the only syntactically sound number system in a language, you basically lose a == operator, as well as an ability to check if your job was finished. Or you use ints and carry fixed points around, which is viable only in few types of languages with operator overloading, like c++. Edit: even when using FP you have to carry initial precis…

Fixed point doesn't do any better than floating point at holding infinite fractions. It won't solve this problem at all.

(While decimal fixed point does solve this particular problem, the part that solves it is the decimal, not the fixed point. Decimal floating point is equally capable of adding 0.1 to 0.2)

Re: 0.1 and 0.2 Returns 0.30000000000000004 (2018)

#150

Post by Dylan16807 »

lifthrasiir wrote: post #121
lmilcin wrote: post #99

Earlier quoted context omitted.

I work on financial risk calculations during day and embedded control devices after my official work hours. My controller running moving horizon estimator to simulate thermal system of the espresso machine and Kalman filters to correct model parameters against measurements runs 50 times a second and works fine for days, thank you, using floats on STM32. I have written huge amount of embedded software over past 20 yea…

Maybe I should have directly mentioned that "some guard against FP errors" includes a generic guard against errors. If your system processes messy data then you probably want some guards anyway and FP errors are just one (relatively small) class of errors. In fact I would be more worried if embedded devices don't have such guards than if they do faulty FP calculations. There are also many classes of softwares where F…

Floating point works just fine for lockstep simulation!

What you need to avoid using is special functions that can vary based on your CPU model. Once you do that, integer lockstep and floating point lockstep are of similar difficulty.

Post reply on HN