[rrss]

Replacing all the IEEE 754 hardware with posits won't fix this, though.

If you don't care about performance, then the actual solution has no dependency on hardware:

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

2. Teach people using other languages about floating point and how they may want to use integers instead.

The end. No multi-generation hardware transition required.

IMO, IEEE 754 is an exceptionally good format. It has real problems, but they aren't widely known to people unfamiliar with floats (e.g. 1.0 + 2.0 != 3.0 isn't one of them).

[IEEE754]

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

[dmd]

I'm pretty sure that 1.0 + 2.0 == 3.0 in IEEE 754. :) Now, 0.1 ...

[ethbro]

For reference to what they're talking about, the helpful https://0.30000000000000004.com/

[mark-r]

One of the great qualities of IEEE 754 is its ability to represent many integers and operate on them without rounding errors.

[rrss]

Yep, sorry, meant to put 0.1 ...

Thanks!

[piadodjanho]

They are not the same thing, but they are close enough most of the time.

The issue with floating point arrises when comparing very close numbers.

[antonyme]

Great points. I agree - the performance hit is simply the cost of being accurate and having predictable behaviour.

I'm not suggesting we replace all our current HW with chips that implement posits (let's fix branch prediction first!!). More that FP should be opt-in for most HLLs.