Why don't we store fractions as fractions rather than floating point?
You can do that, but then you still leave out all the irrationals like sqrt(2) and pi.
Floating Point Math
11–20 of 67 posts
Re: Floating Point Math
#12We 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?
Keep in mind that when something appears on the front page, it’s because enough people voted it up. I don’t actually know, but suspect that commenting on it may bump the score a little as well? Either way, if it’s uninteresting to you, I encourage voting up or submitting something more interesting.
Also keep in mind that because computing is a growing field, the majority of people in it are relatively new to the field, plus there are plenty of people here that don’t have CS degrees.
FWIW, there are many representations for real & floating point numbers. Rationals are an example of something that’s neither floating point nor BCD, and can represent 1/10 and 1/3 exactly. Here’s a fun example: https://iquilezles.org/articles/floatingbar/
Re: Floating Point Math
#13Why don't we store fractions as fractions rather than floating point?
The other answers pointed out some good reasons we use floats instead, but just a note -- Python at least has a "fractions" class.
Re: Floating Point Math
#14Why don't we store fractions as fractions rather than floating point?
You can start there then wind up with floating point.
Say we have a 32 bit CPU. Let's store fractions in two halves, the numerator and denominator.
This turns out to be super inconvenient for irrational numbers. We can use an alternative representation where the number is in two halves, the integer half and fractional half. In other words your first 32 bits are 1X2^0...31 and second 32 bits are 1x2^-1...-32. This is called fixed point.
You run into a problem where this is usually extremely wasteful in the number of bits used, so you can fuse them into a single 32 bits used, and the binary decimal point is at the 16th bit, 18th bit, whatever you need. You just need to track it when multiplying or dividing numbers to handle the appropriate shifts. This is "fixed" point math, and it's what we did for decades because it's super cheap in hardware (it's the same integer adders/multipliers, just some extra work for division and shifting for multiplication).
You might even want the decimal point to move. Say your numbers are almost always less than 1, why use more than 1 bit for the integer part and in software, handle the overflows and change of decimal point when needed?
Well that software part is super complex, so you can implement some special hardware to do it. It's even really convenient to change the representation from a fixed integer and decimal half to a decimal mantissa and integer exponent. Now you've reinvented floating point. It would be great if there was a standard so all languages could agree on representation and hardware to implement it really fast. That's IEEE 754.
Re: Floating Point Math
#15A 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"))
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.
Re: Floating Point Math
#16Why don't we store fractions as fractions rather than floating point?
What if you need to also make sure, sqrt(2) * sqrt(2) == 2? Even this is possible in many representations, but you can see my point I guess.
Re: Floating Point Math
#17Why 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 and a floating point number yields a floating point number. This means that even though you have rational numbers, you still have to be aware of floating point.
Re: Floating Point Math
#18A 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…
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)
Re: Floating Point Math
#19Why 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.
Re: Floating Point Math
#20A 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…
> 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.