Hacker News Reader

Comment by wwright | Hacker News Reader

Pedantic nitpick on floats: floats are exact. The issues with them are:

- they are binary rather than decimal, so rounding behavior doesn’t match what humans expect

- some floating point operations have rounding/error accumulation

You can multiply and divide a float by 2 all day long and every result will be exact, with no error accumulation. However, adding floats together is a different story :-)

That said, decimal types are still much preferable for anything that needs to be “exact” for human usage. It’s very easy to make a mistake with floats, even if they could support your use case.

View on HN

> Pedantic nitpick on floats: floats are exact.

I think you're meaning 'exact' as in they're deterministic. I don't know anyone who knows what they're talking about that argues against this, so I think you're not disagreeing with anyone.

Other people mean 'not exact' as in they can't represent all real numbers. Which is true.

Integers can't represent all real numbers either. Integers can represent more decimal numbers, which tends to be what humans use. But that doesn't make integers more exact. It does mean that integers will probably more accurately reflect the precision of your inputs. (But that presumes that your inputs are entered by humans, and not floats coming out of a sensor that produces readings as floats.)

careful with your terminology there: integers are by definition not real numbers. All ints are reals, but only an infinitely small proportion of reals are ints.

If, however, you meant "the integer datatypes can't represent all integers", then you probably want to say that instead of mixing maths terminology. And you'll also have to back up that claim because bigintegers are as accurate as you have space to store them in; their limitation is not imposed by their spec, but by your hardware.

Unlike IEEE floating point decimal numbers, where the limitation is explicitly part of the spec itself. That limitation is literally why floats even work at all.

Oh I thought thread was contrasting floats with fixnums, I was very confused and wrong.

That's too pedantic. Floats are not exact real numbers because they cannot represent most reals exactly.

There's no need to use a float operation to see this inexact behaviour - floats cannot even represent most reals that humans can write in a computer program. If you write `0.1` in your programming language of choice such that it gets treated as a float, the result is not, in any way, exactly 0.1.

But the reals that they can represent are represented exactly. 0.5 + 0.5 = 1.

If that's your criteria, then neither are BigDecimals exact real numbers.

That's certainly true. The rationals (of which BigDecimal cannot represent the whole space) are a 0-measure part of the reals. I would not claim that BigDecimal is an exact representation, which is a fact that should be clear to anyone that tries to calculate 2 * PI in arbitrary-precision finite decimals. Even not considering irrational numbers, BigDecimal cannot handle 1/3 + 1/3 + 1/3 = 1 correctly.

It might be fair to claim that floats are more inexact - certainly moreso than Rational, but probably moreso than BigDecimal for the numbers that programmers tend to care about.

I didn’t claim they are _any_ exact real number or that they are _exactly_ the same as the decimal literal they are conveyer from. I said they are exact, which they are. (And further, that they are binary and not decimal.)

> floats are exact

It's not clear what you're getting at here. Are you just saying that each floating-point value precisely represents a real number? Or are you saying that floating-point arithmetic is often exact? [0]

My own pedantic nitpick: the article states that but BigDecimals are [exact]. BigDecimal is only exact in the way floats are exact. BigDecimal has arbitrary precision, but is not able to precisely represent every real. There's no way to come up with a system that would be capable of doing this. No matter how much memory you throw at BigDecimal, you can't precisely represent pi.

[0] Sterbenz Lemma, on which there are surprisingly few good sources. See page 45 of (PDF) http://lyoncalcul.univ-lyon1.fr/ed/DOCS_2012-2013/FloatingPo...

I don't think that's a very useful definition of exactness. The article is quoting the Ruby float documentation itself, for one thing.

Perhaps it would be clearer to say that floats and floating point operations are deterministic, so you don't have to convince someone that 0.30000000000000004 is the exact answer to 0.1 + 0.2

Thanks for you feedback, you're right I should have mention that you can of course make right calculation with floats :)

If ruby's float's are exact, how do they translate arbitrary literals to IEEE 754? Surely the vast majority of literals are not representable with IEEE 754, so any exactness of these floats would solely exist in comparison between floats, not with literals.

I made no claims about literals, though perhaps I should have been explicit.

I expect that many use cases for floats do not involve any literals at all, of course.

Reply on news.ycombinator.com