Hacker News Reader

Comment by chongli | Hacker News Reader

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.

View on HN

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

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

Reply on news.ycombinator.com