[svat]

A couple of thoughts I've always had about floating-point arithmetic:

1. IMO it's unfortunate that most languages default to floating-point. Most programmers, most of the time, would be better served by slightly slower but less confusing alternatives (it's nice that Raku uses rational numbers by default: similarly for integers, it's great that Python uses arbitrary-precision integers by default). At any rate, programmers would be a lot less confused about floating-point arithmetic if they had to opt in to it explicitly, e.g. instead of 0.1 + 0.2 if they had to say something super-explicit like (just exaggerating a bit for effect, this is probably impractical anyway):

    NearestRepresentableSum(NearestRepresentable("0.1"), NearestRepresentable("0.2"))

till they got the hang of it.

2. IMO when explaining floating-point arithmetic it helps to add a picture, such as this one (added to Wikipedia by a user named Joeleoj123 in Nov 2020): https://upload.wikimedia.org/wikipedia/commons/b/b6/Floating...

With this picture (or a better version of it), one can communicate several main ideas:

- There are a finite number of representable values (the green points on the number line),

- Any literal like "0.1" or "0.2" or "0.3" is interpreted as the closest representable value (the closest green point),

- Arithmetic operations like addition and multiplication give the closest green point to the true sum,

- There are more of them near 0 and they get sparser away from 0 (the "floating-point" part),

etc.

Further, by staring at this picture, and the right words, one can infer (or explain) many of the important properties of floating-point arithmetic: why addition is commutative but not associative, why it is a good idea to add the small numbers first, maybe even the ideas behind Kahan summation and what not.

[codebje]

> IMO it's unfortunate that most languages default to floating-point. Most beginning programmers would be better served …

Most languages, most of the time, are not used by beginners.

[thethirdone]

If you are using "beginner" to refer to the time spent, this is true.

However, if you use "beginner" to the knowledge gained, it might not be. If you only ever make webpages, even if you have made 100s you could still be a novice programmer because you never branched out enough to learn new programming concepts.

If a programming language makes it easy to do something moderately, but it is hard to do it well. Programmers who only know that language are likely to have a gap in their stills. Floating point (in most languages) is easy to gets the basics working, but are hard to do well and very hard to do perfectly. This leads to a lot of programmers not learning floating point well.

[codebje]

General purpose programming languages are complex tools.

In this specific case representing non-integer numbers effectively on a binary device is complex. If you use a different representation than IEEE floats you just give a different set of corner cases and unexpected outcomes.

Don't let a novice build software you need to be correct without supervision, and if you are a novice expect to make mistakes, just like if I were to build a website I wouldn't expect my style choices to render appropriately on a wide range of devices... that's complex too!

[svat]

Whether or not that's true, you can remove "beginning" from my statement as it's not necessary (done, just edited, thanks): most programmers, most of the time, don't need the speed of floating-point everywhere (compared to fixed-point/scaled integers, or rationals, or interval arithmetic, or whatever), and when they do, the language could let them easily opt into it with a declaration like "use float" or whatever.

[codebje]

Every option here has tradeoffs and drawbacks: fixed point arithmetic suffers from a very limited precision range, rationals aren't even the same number set, cauchy sequences are precise but comparatively very slow… there's no one size fits all solution that's right in every circumstance.

Except, of course, at lower levels of abstraction - where IEEE floats are what the hardware implements. Lower level languages use 8-, 16-, 32-bit integers, they use IEEE floats and doubles, and they make these choices for pretty solid reasons.

Higher level languages make different choices (arbitrary precision integers are common in interpreted languages, eg). Libraries support all kinds of options up and down the stack.

[franga2000]

Of course, but low-level languages call their floats...floats. Certain higher-level languages often call them numbers or decimals, which is why this confusion happens in the first place. It's like if a language had uint8 but called it Integer - yes, there are many uses for uint8, but there are also many cades where it's the wrong thing to use and it shouldn't be possible to use it accidentally.

[ketzu]

> rationals aren't even the same number set

In what way are rationals not the same number set? In the strictest sense basically none of the proposed versions have the same number set, but in a broad sense, they all represent a useful subset of rationals, right?

[codebje]

In a broad sense, sure.

[ketzu]

Could you elaborate what your intended meaning was? It felt to me like you were singeling out 'rationals' as not being the same number set. Maybe we also think of something different when talking about 'rationals'?

Maybe I also missed something obvious, so I'd like to satisfy my curiosity!

[Kevcmk]

Agree. But experts/intermediates often gloss over language semantics in pursuit if getting something done. For me, floating point by-default is more often a nuisance

[franga2000]

That doesn't really matter. Even if you had 20 years of experience in C++ or whatever, you could confidently write JavaScript code with floating point bugs in it, because "the type is called Number, obviously that isn't floating point". Beginner programmers might actually realise this sooner, since veterans aren't going to be writing console.log(0.3+0.2) as part of learning the language.

[ycombobreaker]

IMHO this does not follow, for a few reasons:

- An experienced programmer would know that IEEE FP hardware is ubiquitous. Why would a language eschew that hardware capability by default? If anything, I would assume that any unfamiliar general-purpose language DOES start from that point (using IEEE float to represent non-integer numbers) because of historical precedent.

- "Number" is about as vague as you can get for a type name. Maybe personal bias here, but I find that vagueness invites research up front. "Time to read the documentation."

(I still expect a language newbie to get various bugs in new Javascript code, because the footguns in that language differ from the footguns in something like C++.)

[kaba0]

Should we really optimize for someone writing in a new language without reading anything about it? Like, if he/she doesn’t even know that js numbers are floats, just don’t even let them close to a program.

[ycombobreaker]

No we should not, nor am I advocating for that.

[lizmat]

Thank you for your mention of the Raku Programming Language.

If you want to force usage of floating point arithmetic, you will have to indicate that in literal values. E.g. `0.1` would be a [Rat](https://docs.raku.org/type/Rat) (Rational number), and `0.1e0` would be a [Num](https://docs.raku.org/type/Num) (aka a floating point".

In Raku, to get the nearest representation, use the [.narrow](https://docs.raku.org/routine/narrow) method. So `42e0.narrow`, `42.0.narrow` and `42+0i.narrow` would all be an `Int`. Yes, Raku has complex numbers built in as well :-)

[xigoi]

That would be another case of wasting a lot of time and electricity so the developer doesn't have to spend half an hour learning how a computer works.

[dahfizz]

Why should I have to learn how to do my job well? Programmer time is expensive! /s

[dahfizz]

Any other way of representing the real numbers is going to have gotchas. Rational numbers take up more space and are slower to use, but also have real drawbacks like not being able to do sqrt or having to worry about overflow when doing a comparison.

Ultimately, there is no substitute for knowing what you are doing.

[trinovantes]

If nothing else, I think compilers/linters should warn when trying to use equality/comparison operators between floats since most of the time it's mathematically wrong. All of my projects are filled with isApproxEquals(float1, float2)

[kwhitefoot]

That really depends on where the floats come from and how they have been manipulated. I have written quite a lot of code where comparing floats was perfectly sensible. I had to repeatedly revert changes by colleagues who didn't understand the code and had replaced A == B with something like isApproxEquals(A, B). This was in electrical design software where every millisecond counted.

[adhesive_wombat]

To be fair, float point equality is often a red flag and often deserves a double-take (even if the result is, yes, it's correct).

A comment like "exact equality is deliberate here and valid because XYX and important for meeting performance requirements ABC" would help, unless it's a major part of the system, in which case the colleague should know that already.

And on their part, a check in with you for "hey, I don't understand why this equality is valid" would be better than assuming it's wrong and changing it.

[ycombobreaker]

I see a lot of this (generic approx-comparison functions) at work. It can catch some problems, true, but it becomes very cargo-cultish. They understand that the hardware rounds calculations, but they behave as if the hardware is nondeterministic. There's also very little thought going into an appropriate epsilon value, whether based on the calculation being done, or the tolerance of the overall output/algorithm.