IEEE754 · HackerTrans

Correct.

> does not interpret the 0.1 as the real number

The focus should be on _rational_ numbers. This particular example is all about representation error - precision is implicated, but not the cause.

Ignore precision for a second: The inputs 0.1 and 0.2 are intended to be _rational_. This means they can be accurately represented finitely (unlike an irrational number like PI). Now when using fractions they can _always_ be accurately represented finitely in any base:

  1/10=
  base 10: 1/10
  base  2: 1/1010

  2/10=
  base 10:  2/10
  base  2: 10/1010

The neat thing about rationals, is that when using the four basic arithmetic operations: two rational inputs will always produce one rational output :) this is relevant: 1/10 and 2/10 are both rationals, there is no fundamental reason that addition cannot produce 3/10. When using a format that has no representation error (i.e fractions) the output will be rational for all rational inputs (given enough precision, which is not a realistic issue in this case). When we add these particular numbers in our heads however, almost everyone uses decimals (base 10 floating point), and in this particular case that doesn't cause a problem, but what about 1/3?

This is the key: rationals cannot always be represented finitely in floating point formats, but this is merely an artifact of the format and the base. Different bases have different capabilities:

  1/10=
  base 10: 0.1
  base  2: 0.00011001100110011r

  2/10=
  base 10: 0.2
  base  2: 0.00110011001100110r

  1/3=
  base 10: 0.33333333333333333r
  base  2: 0.01010101010101010r

IEEE754 format is a bit more complicated than above, but this is sufficient to make the point.

If you can grok that key point (representation error), here's the real understanding of this problem:

Deception 1: The parser has to convert '0.1' decimal into base 2, which will cause the periodic significand '1001100110011' (not accurately stored at any precision)... yet when you ask for it back, the formater magically converts it to '0.1' why? because the parser and formater have symmetrical error :) This is kinda deceptive, because it makes it look like storage is accurate if you don't know what's going on under the hood.

Deception 2: Many combinations of arithmetic on simple rational decimal inputs also have rational outputs from the formatter, which furthers the illusion. For example, nether 0.1 or 0.3 are representable in base 2, yet 0.1 + 0.3 will be formatted to '0.4' why? It just happens that the arithmetic on those inaccurate representations added up to the same error that the parser produces when parsing '0.4', and since the parser and formatter produce symmetric error, the output is a rational decimal.

Deception 3: Most of us grew up with calculators, or even software calculator programs. All of these usually round display values to 10 significant decimals by default, which is quite a bit less than the max decimal output of a double. This always conceals any small representation errors output by the formatter after arithmetic on rational decimal inputs - which makes calculators look infallible when doing simple math.

IEEE754

7 anni fadiscuss

> Over the past 50 years, my computer has adapted to how humans normally operate in nearly every other way. Why do they continue to use this system which produces results different from what any normal person expects?

If you look at any low level hardware it's behavior will be alien and unintuitive to most end-users, your computer has not adapted, only it's ability to support sophisticated high level software that abstracts these things away from end users has improved.

FPUs are no different, calculators round output to 10sf, and as a result most users think calculators are perfect, and that's usually fine... it's not fine when you do programming, because eventually you will need to understand the fundamental limitations of the hardware and more generally finite numerical computation regardless of implementation.

IEEE754

7 anni fadiscuss

FWIW, their "basic answer" page is the simplest i've seen that neither lies or omits critical factors in the 0.1 + 0.2 problem. It's probably a good starting point that induces some lingering questions tempting you to find out more.

If you want a thorough understanding you will want to look at representation-error, rounding-error, error-propagation, why they exist and how they interact.

The interplay between those three forms of numerical error in floating point numbers will also allow you to more easily see the world of limitations of fp beyond 0.1 + 0.2 for yourself.

IEEE754

7 anni fadiscuss

> 1. Replace the default format for numbers with a decimal point in suitably high level languages with a infinite precision format.

Unlimited precision in any radix point based format does not solve representation error. If you don't understand why:

  - How many decimal places does it take to represent 1/3 (infinite, AKA out of memory)

  - Now how many places does it take to represent 1/3 in base3? (1)

If you are truly only working with rational numbers and only using the four basic arithmetic operations, then only a variable precision fractional representation (i.e a numerator and demonstrator, which is indifferent to underlying base) will be able to store any number without error (if it fits in memory). Of course if you are using transcendental functions or want to use irrational numbers e.g PI then by definition there is no numerical solution to avoid error in any finite system.

IEEE754

7 anni fadiscuss

> Most think of it as base-10 [...] I'm surprised nobody has made a decent fixed point lib that is widely used already.

Note that fixed radix point does not solve the common issues with representing rational base 10 fractions. A base10 fixed radix solution would, but so would IEEE754's decimal64 spec, which would eliminate representation error when working exclusively in the context of base10 e.g finance, but these are not found in common hardware and do not help reduce propagation of error due to compounding with limited precision in any base.

comments