Live data from Hacker News

0.1 and 0.2 Returns 0.30000000000000004 (2018)

qntm.org

151–160 of 161 posts

Re: 0.1 and 0.2 Returns 0.30000000000000004 (2018)

#151
post #94

One of the many reasons I think we all would've been better off, had Brendan Eich decided he'd been able to simply use Scheme within the crazy time constraint he'd been given, rather than create JavaScript, :) is that Scheme comes with a distinction between exact and inexact numbers, in its numerical tower: https://en.wikipedia.org/wiki/Numerical_tower One change I'd consider making to Scheme, and to most high-level…

Scheme did not "look like Java" so was ruled out on that basis (also on others which I have discussed at length in several interviews, most recently with Lex Fridman).

Re: 0.1 and 0.2 Returns 0.30000000000000004 (2018)

#152

Earlier quoted context omitted.

Well, that was trivially easy to disprove with a little jiggling of numbers in the console: Math.abs(1.8 - (0.1 + 0.2 + 0.9 + 0.6)) returns false. Also, you generally really shouldn't be implementing any currency logic using floating point numbers, yikes. Stick to integers that represent the value in cents, or tenths of cents, or similar. Or, even better, a DECIMAL data type if your platform supports it. I genuinely…

I never said you should use floating-point numbers for currency. I said that if you are not aware of the shortcomings of floating-point numbers (the only numeric type in JavaScript, not counting workarounds like typed arrays) you should not be working with values representing currencies until you do. Fixed-point numbers (aka "decimal" type in Java, C# and others) are the preferred way to deal with this problem as I m…

^ And of course a comment mentioning the correct way of doing things got downvoted.

Re: 0.1 and 0.2 Returns 0.30000000000000004 (2018)

#153

Earlier quoted context omitted.

You cannot compare floating point numbers like that. The equality test in floating point numbers is comparing against the epsilon. Math.abs(0.3 - (0.1 + 0.2)) Which is the same you other languages. 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…

rounding error after multiple operations can be more than just epsilon

That's why there are algorithms to do those multiple operations.

Re: 0.1 and 0.2 Returns 0.30000000000000004 (2018)

#154
post #140

Earlier quoted context omitted.

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.

No it does not, no it is not possible to use equality comparisons usefully in FP arithmetic

Re: 0.1 and 0.2 Returns 0.30000000000000004 (2018)

#156
post #154

Earlier quoted context omitted.

> 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.

No it does not, no it is not possible to use equality comparisons usefully in FP arithmetic

If that were true, they wouldn't have defined the equality operators for floating point types. Some numbers are exactly representable and some numbers are not [1]. It's difficult, but you can in fact reason about the exact results of floating point calculations. https://news.ycombinator.com/item?id=1847462

Re: 0.1 and 0.2 Returns 0.30000000000000004 (2018)

#157
post #28

Earlier quoted context omitted.

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,…

say (1/10+1/10).WHAT; say (1/6+1/6).WHAT;

both are Rats, they just get stringified differently

Re: 0.1 and 0.2 Returns 0.30000000000000004 (2018)

#158
post #94

One of the many reasons I think we all would've been better off, had Brendan Eich decided he'd been able to simply use Scheme within the crazy time constraint he'd been given, rather than create JavaScript, :) is that Scheme comes with a distinction between exact and inexact numbers, in its numerical tower: https://en.wikipedia.org/wiki/Numerical_tower One change I'd consider making to Scheme, and to most high-level…

Scheme did not "look like Java" so was ruled out on that basis (also on others which I have discussed at length in several interviews, most recently with Lex Fridman).

Thanks for that interview; very interesting, and I also appreciate your words for Scheme.

For HN, I'd like to point out that it was a historical accident that Java looked like it did, as far as the Web was concerned.

IIRC, Java looked like it did to appeal to technical and shrinkwrap developers, who were using C++ or C. (When I was lucky to first see Java, then called Oak, they said it was for embedded systems development for TV set-top boxes. I didn't see Java applets until a little later.)

But the Web at the time was intended to be democratizing/inclusive (like BASIC, HyperCard, and Python). And the majority of the professional side was closer to what used to be called "MIS" development (such as 4GLs, but not C/C++). And in practice, HTML-generating application backends at the time were mostly written in languages other than C/C++.

I'm sympathetic to the rebranding of the glue language for Java applets (and for small bits of dynamic), to be named like, and look like, Java. That made sense at the time, when we thought Java was going to be big for Web frontend (and I liked the HotJava story for a thin-client browser extended on-demand with multimedia content handlers). And before the browser changed from hypertext navigator to GUI toolkit.

But it's funny that we're all using C-descendant syntax only through a series of historical accidents, when that wasn't even what the programmers at punctuated points in its adoption actually used (we only thought it would be, at the time the decisions were made).

Re: 0.1 and 0.2 Returns 0.30000000000000004 (2018)

#159
post #67

Earlier quoted context omitted.

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

>> 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? Knowing which side of the asymptote you're on does not solve this problem or even ameliorate it.

That's not what I'm saying - it seems to me to be programmer error that such a question is being asked (an exception should be thrown regardless, since the result is not of a usable quality).

Re: 0.1 and 0.2 Returns 0.30000000000000004 (2018)

#160

Earlier quoted context omitted.

>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,…

say (1/10+1/10).WHAT; say (1/6+1/6).WHAT; both are Rats, they just get stringified differently

They stringify differently because 2/10 can be expressed exactly in NNN.MMM format, whereas 1/3 can not.
Post reply on HN