Hacker News Reader

Comment by saagarjha | Hacker News Reader

> JavaScript, on Twitter, gets a lot of heat for this behavior

  0.1 + 0.2 = 0.30000000000000004

I mean, there’s a lot of things JavaScript should get heat for, but this really shouldn’t be one of them. This is inherently an issue with any language that has floating point numbers.

> And this is the way that compiled languages have always worked: when you compile a C program, the methods you import from math.h are included in the compiled binary.

Depends on your inlining level and choice of linking.

View on HN

> I mean, there’s a lot of things JavaScript should get heat for, but this really shouldn’t be one of them. This is inherently an issue with any language that has floating point numbers.

It is inherently an issue with binary floating point[1]. It is not an issue with decimal floating point. In decimal floating point, 0.1 + 0.2 = 0.3 exactly.

JavaScript could have used decimal floating point instead – but that would be slower, since it usually has to be emulated in software – mainstream platforms like x86 and ARM lack decimal floating point hardware, it is only found on rare platforms such as POWER, System z, and Fujitsu SPARC – and even with hardware acceleration it is still going to be slower. JavaScript, like most languages, prioritises speed over obviousness in this area.

Alternatively, JavaScript could have supported both decimal and binary floating point, and beginners could stick to the more obvious former, and those needing high performance could switch to the later – but its designers decided (probably correctly) that the added complexity wasn't worth it. (Also, having two types of floating point numbers in a language would likely confuse beginners just as much as binary floating point does.)

[1] And hexadecimal floating point too, but that is rarely encountered outside of IBM mainframes, and also various other obscure obsolete systems such as Interdata 8/32 minicomputers

> It is inherently an issue with binary floating point[1]. It is not an issue with decimal floating point. In decimal floating point, 0.1 + 0.2 = 0.3 exactly.

Decimal floating point doesn't fix the problem, it just makes the simplest example work. If you did ⅓ + ⅓ + ⅓ in decimal floating point, you'd still get 0.99999 instead of 1.

It doesn't completely fix the problem, but it makes the problem smaller.

The gap between naive expectations of how it should work, and how it actually works, exists for both binary and decimal floating point, but the gap is bigger in the case of binary than it is in the case of decimal.

Also, the problem that ⅓ + ⅓ + ⅓ < 1 is not unique to floating point – the same issue occurs with fixed point arithmetic (unless your scale factor is a multiple of 3, which is not a common choice). In the general case, if one wants to avoid this problem, one needs to use rationals.

I think the issue with ⅓ + ⅓ + ⅓ is easier to explain to beginners – it requires an understanding of rounding and that ⅓ cannot be represented exactly as a decimal, which in many countries the school curriculum pays more attention to than it does to other number bases, so many people have a better intuitive understanding of the former than the later.

The solution is to either provide a Rational type that doesn't uses fixed values instead of floating point or to have programmers understand how floating point works and why you shouldn't compare them by absolute equality.

> I mean, there’s a lot of things JavaScript should get heat for, but this really shouldn’t be one of them. This is inherently an issue with any language that has floating point numbers.

This is mentioned in the paragraph that is immediately after the text you excerpted.

I'm calling out Twitter explicitly, not the author, because I don't think he does so enough.

This is inherently an issue with any language that has floating point numbers.

It's not an issue for languages that have floating point numbers, it's an issue for languages that make them the default (or worse, the only option). There are plenty of other languages that let you use arbitrary-precision integers or decimals as well as the usual fixed-size floats and integers.

When you're writing a program intended to provide calculations to the end user (such as a calculator) you really ought to use arbitrary-precision decimals so that you never run into this problem.

> (such as a calculator)

I'd be interested in a calculator that used arbitrary-precision decimals to compute arcsines, logs, etc. But I wouldn't recommend anyone create or use one.

The default calculator on Android since Marshmallow apparently uses arbitrary precision arithmetic: https://m-cacm.acm.org/magazines/2017/8/219594-small-data-co...

That was a great read.

The purity of the approach is tainted (in a helpful way, not a bad way) by a note at the end:

> The most recent versions of our calculator explicitly track rational multiples of π and some other common irrational constants. This allows us to compute a rational result for sin(π/6) in radian mode, as we already did for sin(30°).

When I mentioned arcsines above, that wasn't a coincidence -- radians are convenient, but they're also impossible to measure exactly, and when your computation goes through a trig function, you may unavoidably lose the ability to state your results exactly (except by invoking a function name like "arcsine").

That isn't as much of a theoretical obstacle as it might sound like -- you can't state square roots exactly either, except by referring to the concept "square root". But they can be a little more conceptually direct -- trig functions are inextricably bound up with pi, and it's hard -- impossible -- to recognize pi when it appears in your input, unless it appears as the symbol π.

The use of arbitrary-precision decimals instead of floats comes with a very severe performance penalty. And for what benefit? So you can represent values to a greater precision than your ability to measure them accurately?

Almost anything you'd want to use a non-integer number for is going to be difficult to nail down to 5 or 6 decimal digits of precision on (honestly, even 3 is pushing it). Double-precision floats gives you 11 decimal digits of precision--ample room for accumulated round-off error to not affect the final result, unless you've got numerical instabilities.

Doubles give you around 15-16 (according to DBL_DIG) digits of precision, don't they?

You're right, I mixed it up with the 11 bits of exponent.

To your point, I think one of the places where you see 6 decimal places actually put to use is with latitude and longitude, where 6 decimal digits gets you to 11cm of precision. (11 digits gets you to a micrometer.)

IMO Racket pedagogically does the right thing by first exposing users to arbitrary precision numbers by default.

> I mean, there’s a lot of things JavaScript should get heat for, but this really shouldn’t be one of them. This is inherently an issue with any language that has floating point numbers.

They address that in the very next sentence...

https://news.ycombinator.com/item?id=22344164

Reply on news.ycombinator.com