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?
Unfortunately no.
Floating Point Math
31–40 of 67 posts
Re: Floating Point Math
#32Such a shame that decimals don't get more attention. I program in Go a lot and they don't even have a fixed point number type built into the language. Floating point numbers always seems to be the default. And while there is support via third party packages, it makes everything harder to use, from communicating with databases to (de-)serializing data. However, in reality most numbers I deal with can reasonably be ass…
In what context couldn't you just use an integer?
Re: Floating Point Math
#33It's a nice website explaining the problem lightly, but I think the cool part is the encyclopedic language list handling floating point numbers and the reference for bigdecimal support. The only sentence I don't really like: > When you have a base-10 system (like ours), it can only express fractions that use a prime factor of the base. It's a weird mix of over- and under-generalization. The second half sounds like a…
> 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 better and more rigid explanation would start with a rational p/q, with p and q relatively prime that can be written as some integer divided by 10^n, and reason from there.
Re: Floating Point Math
#34A 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.
Re: Floating Point Math
#35Why don't we store fractions as fractions rather than floating point?
Common Lisp does by default. Calling (/ 1 3) gives 1/3 which is a rational. The individual components of a rational number are bignums, so the size of the fraction is only limited to available RAM. However, this is not enough in many cases. For example, how would you store pi? In the case of Lisp, pi is stored as a floating point number, and the conversion rules say that a mathematical operation between a rational an…
As soon as you want to do something with π, you have no choice but an approximation, so floating-point is completely appropriate.
Re: Floating Point Math
#36Earlier 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.
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 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.
Re: Floating Point Math
#37Why don't we store fractions as fractions rather than floating point?
If you start with the idea that you want to store every number in the same finite number of n bits, you’ve got a problem: you can store (at most) 2^n different numbers in n bits, but there are infinitely many numbers.
So, if you want to hold on to that idea, the question becomes what numbers best to pick.
If you go for rational numbers, you soon discover that addition of rationals is slow because you have to [1] multiply the denominators and find a greatest common divisor (example: 1/3 + 1/9 = (19 + 13)/(3*9) = 12/27 = 4/9)
You also will find that your denominators can rapidly get large, and that, in real life, you need to represent a fairly wide range of numbers (say at least between 10^-3 and 10^6). That means you either accept large, random rounding in calculations, or have to pick a large number of bits
Also, the math you have to do to find the closest rational for square roots and results of goniometric functions makes those functions slow.
So, you either have to give up the idea to store rationals, or the idea to store every number in the same finite number of n bits. IEEE chooses the former for performance reasons.
[1] assuming you want to have a single representation for each rational. You likely want, as you don’t want to waste space and because you want equality testing to be simple.
Re: Floating Point Math
#38Earlier 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…
> 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?
Re: Floating Point Math
#39It's a nice website explaining the problem lightly, but I think the cool part is the encyclopedic language list handling floating point numbers and the reference for bigdecimal support. The only sentence I don't really like: > When you have a base-10 system (like ours), it can only express fractions that use a prime factor of the base. It's a weird mix of over- and under-generalization. The second half sounds like a…
My attempt: You can't express 1/3, 1/6, 1/7, or 1/9 in decimal without infinitely repeating digits; you can only express 1/2 and 1/5, and 2*5=10. In binary systems, you can only represent multiples of 1/2 without infinite repeating digits, so, 0.5, 0.25, 0.125 are all exact in binary floating point. 0.1 is 1/10, which needs that 5 you don't have in binary. Computers don't have infinite memory, so infinitely repeating digits are truncated at some point. As such, 0.1 + 0.2 in binary floating point is not exact, the same way adding 0.33333 + 0.66666 wouldn't exactly give you 1.0 in decimal.
Re: Floating Point Math
#40Such a shame that decimals don't get more attention. I program in Go a lot and they don't even have a fixed point number type built into the language. Floating point numbers always seems to be the default. And while there is support via third party packages, it makes everything harder to use, from communicating with databases to (de-)serializing data. However, in reality most numbers I deal with can reasonably be ass…
In what context couldn't you just use an integer?
Multiplication context maybe?