[OskarS]

Floating point is fine. Non-integers are inherently tricky to represent, especially when you have to pack it into 32 bits. You could maybe quibble with some of the decisions around NaN and denormals and things like that, but mostly IEEE-754 got it right. There's a reason it's been the standard for three and a half decades now, and it's served the computer industry very well.

Incidentally: the fact that 0.1+0.2 does not equal 0.3 is not something you could quibble with, that is absolutely reasonable for a floating point standard. It would be insanity to base it off of base 10 instead of base 2.

[UncleMeat]

I think one of the problems today is that floating point remains the default even for scripting languages like python. I'd wager that the huge majority of users of floating point arithmetic in their programs actually want correct math rather than efficient operations. This feels a bit like Random vs SecureRandom. So many people use the default and then accidentally shoot themselves in the foot. IMO, for scripting languages we should have infinite precision math by default and then be able to use floating point if you really care about speed.

[lifthrasiir]

This is not a trivial decision because rational numbers can have an unbounded denominator and it can cause a serious performance problem. Python explicitly ruled rational numbers out due to this issue [1]. There are multiple possible answers:

- Keep rational numbers; you also have an unbounded integer so that's to be expected. (Well, unbounded integers are visible, while unbounded denominators are mostly invisble. For example it is very rare to explicitly test denominators.)

- Use decimal types with precision controlled in run time, like Python `decimal` module. (That's still inexact, also we need some heavy language and/or runtime support for varying precision.)

- Use interval arithmetic with ordinary floating point numbers. (This would be okay only if every user knows pitfalls of IA: for example, comparison no longer returns true or false but also "unsure". There may be some clever language constructs that can make this doable though.)

- You don't have real numbers, just integers. (I think this is actually okay for surprisingly large use cases, but not all.)

[1] https://python-history.blogspot.com/2009/02/early-language-d... (search for "anecdote")

[UncleMeat]

Sure, every solution has problems. If there was an obvious alternative with little downside I think we'd have adopted it decades ago.

I just suspect that alternatives bite people less frequently than floating point does.

[edflsafoiewq]

What precise number representation do you want that's free of such "surprises"?

[lmilcin]

There exists no representation without "surprises" and it is easy to show why that must be.

The closest you can get is some systems like Matlab/Octave that specialize in working with numbers.

[aidenn0]

Of course it shouldn't be base 10. It should be base 60. That has more prime factors and wastes fewer bits than BCD does.

[lmilcin]

Or base 256 so that it fits a byte efficiently. Oh... wait...