Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Floating Point Math

0.30000000000000004.com

Post reply on HN
Print view View original

51–60 of 67 posts

Re: Floating Point Math

#51

Post by franga2000 »

codebje wrote: post #36
svat wrote: post #28

Earlier quoted context omitted.

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.

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…

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.

Re: Floating Point Math

#52

Post by dahfizz »

xigoi wrote: post #34
svat wrote: post #15

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, program…

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.

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

Re: Floating Point Math

#53

Post by lozenge »

ketzu wrote: post #44
codebje wrote: post #42

Earlier quoted context omitted.

In a broad sense, sure.

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!

You can't do trigonometry on the rationals, which would prevent any games, graphics software, audio mixing software etc from using the rationals.

Re: Floating Point Math

#54

Post by dahfizz »

ketzu wrote: post #10
waynecochran wrote: post #4

We all know this by now right? We know computers store numbers in binary (unless using BCD) and numbers like 1/10 and 1/3 can only be approximated in a finite number of bits. This isn't news is it?

Rational numbers can also be trated as quotient of two integers and stored with arbitrary precision by storing these two values, even with limited precision of 2x32 bit integers, that would perfectly accurately capture 1/3 and 1/10. But I also don't think it is particularly 'news', the discussion on previous versions centered around the problems that arise from floats, such as inconsistent handling by tools and langu…

Rationals have their own set of issues:

1) it's really slow slow. Adding two fractions involves three integer multiplications and then running the GCD to simplify the fractions.

2) just simply comparing two rational numbers involves multiplication, which may overflow.

3) you can't represent irrational numbers. You can't do square roots, for example.

Re: Floating Point Math

#55

Post by ketzu »

dahfizz wrote: post #54
ketzu wrote: post #10

Earlier quoted context omitted.

Rational numbers can also be trated as quotient of two integers and stored with arbitrary precision by storing these two values, even with limited precision of 2x32 bit integers, that would perfectly accurately capture 1/3 and 1/10. But I also don't think it is particularly 'news', the discussion on previous versions centered around the problems that arise from floats, such as inconsistent handling by tools and langu…

Rationals have their own set of issues: 1) it's really slow slow. Adding two fractions involves three integer multiplications and then running the GCD to simplify the fractions. 2) just simply comparing two rational numbers involves multiplication, which may overflow. 3) you can't represent irrational numbers. You can't do square roots, for example.

Yes, all systems will have some drawbacks. My response was only geared towards this part:

> numbers like 1/10 and 1/3 can only be approximated in a finite number of bits

Maybe I should have been more explicit.

Re: Floating Point Math

#56

Post by ketzu »

lozenge wrote: post #53
ketzu wrote: post #44

Earlier quoted context omitted.

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!

You can't do trigonometry on the rationals, which would prevent any games, graphics software, audio mixing software etc from using the rationals.

I mean, you can, but you shouldn't. I don't think anyone is arguing that any representation is suitable for all usecases or that ieee754 should not be available in programming languages.

Also, I think I'm too tired by now, I get confused too much between the rationals as the rational numbers \mathbb{Q} and the rationals as an implementation of rational numbers using a quotient of two integers.

Re: Floating Point Math

#57

Post by dahfizz »

svat wrote: post #15

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, program…

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.

Re: Floating Point Math

#58

Post by dahfizz »

lmm wrote: post #19
toxicFork wrote: post #6

Why don't we store fractions as fractions rather than floating point?

Because that was too slow in the 1970s, when this particular corner of programming language design ossified.

Alternatively, people cared about performance then. Nowadays programmers would rather do the slow, easy thing so they don't have to think as hard.

Re: Floating Point Math

#59

Post by DecayingOrganic »

Someone wrote: post #33
7x11x13 wrote: post #8

Earlier quoted context omitted.

> it can only express fractions that use a prime factor of the base. IMO it could do better to explain why this is the case rather than state it as a fact, as it’s not immediately obviously true (at least to me). A terminating decimal is equivalent to a fraction with a denominator that is a power of 10. Any fraction with a denominator that is a product of prime factors of 10 can be turned into a fraction with a denom…

That’s not a very good explanation. That second sentence > Any fraction with a denominator that is a product of prime factors of 10 can be turned into a fraction with a denominator that is a power of 10. isn’t sufficient. You also have to argue that any fraction with a denominator that is not a product of the prime factors of 10 cannot be written as a finite decimal. If you do that you end up with a tautology. A bett…

I don't think you're being charitable here. Sure, their explanation wasn't perfect, but their line of reasoning was absolutely on point.

You almost gave a really good explanation yourself on why this should be the case but stopped short of it. Don't know why. Any terminating decimal can be written in the form a/10^{n} where a and n are both integers. After we have our p/q, there exists an integer c such that p/q · c/c = p/10^{n} if and only if q consists solely of the primes 2 or 5 (or both). And if not, then there isn't an integer c to satisfy said condition, thus making it impossible to write our p/q in the form of a/10^{n} (white still keeping the numerator an integer at least) so it's an infinitely repeating decimal.

Re: Floating Point Math

#60

Post by ycombobreaker »

franga2000 wrote: post #49
codebje wrote: post #20

Earlier quoted context omitted.

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

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.

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

Post reply on HN