Why aren't rational numbers implemented and stored as fractions with zero loss of information? [closed]

Question

I know this is a bit hypothetical but I am wondering why no language I know does it.

For example, you want to store 1/3. Give the programmer an option to specify it as 1/3, and store 1 and 3. Something like

struct float {     int numerator;     int denominator; }; 

Rational number arithmetic becomes really easy and considerably more accurate!

This would solve so many problems related to the precision and storage limitations of floating point numbers, and I dont see it introducing any new problems as well!

Hence my question: Why aren't rational numbers implemented and stored as fractions with zero loss of information?

---

As Joe asked, and others might also point out, I do not mean this to replace existing system, but to complement it.

Q: How do you store pi?

A: So many times, I am just storing 1/3 and not pi. pi can be stored the old way, and 1/3 in the new way.

Answer 1

The reason they are not stored this way by default is that the range of valid values that can fit in a fixed set of bits is smaller. Your float class can store numbers between 1/MAXINT and MAXINT (plus or minus). A C/C++ float can represent numbers between 1E+37 and 1E-37 (plus or minus). In other words, a standard float can represent values 26 orders of magnitude bigger and 26 orders of magnitude smaller then yours despite taking half the number of bits. In general, it's more convenient to be able to represent very large and very small values than to be perfectly precise. This is especially true since rounding tends to give us the right answers with small fractions like 1/3. In g++, the following gives 1:

std::cout << ((1.0/3.0) * 3.0) << std::endl;  

Remember that types in C++ have a fixed size in bits. Thus a datatype in 32 bits has at most MAX_UINT values. If you change the way it is represented, you're just changing which values can be precisely represented, not increasing them. You can't cram more in, and thus can't be "more precise". You trade being able to represent 1/3 precisely for not being able to represent other values precisely, like 5.4235E+25.

It is true that your float can represent values more precisely between 1E-9 and 1E+9 (assuming 32 bit ints) but at a cost of being completely unable to represent values outside of this range. Worse, while the standard float always has 6 digits of precision, your float would have precision that varied depending on how close to zero the values were. (And note that you are using twice the bits that float does.)

(I'm assuming 32 bit ints. Same argument applies for 64 bit ints.)

Edit: Also note that most data people use floats for is not precise anyway. If you are reading data off of a sensor, you've already got imprecision, so being about to "perfectly" represent the value is pointless. If you are using a float in any sort of computing context, it's not going to matter. There is no point in perfectly describing '1/3' if your purpose is to display a bit of text 1/3rd of the way across the screen.

The only people who really need perfect precision are mathematicians, and they generally have software that gives them this. Very few others need precision beyond what double gives.

Answer 2

Real number arithmetic becomes really easy and considerably more accurate!

No, it doesn't. The struct you describe only handles rational numbers, i.e. those that can be expressed as fractions. The set of real numbers includes both rational and irrational numbers. Most real-world calculations are done using real numbers, so you can't just limit yourself to the rationals and expect everything to be fine.

I am wondering why no language I know does it.

Most of the languages that I can think of make it possible to do exactly what you describe. In C, you can create a struct that contains numerator and denominator, and you can define a bunch of functions that operate on such structs. C++ makes things a LOT easier by letting you define a class and operations on that class -- same idea, much nicer syntax, etc. In fact, different sets of numbers are often used as examples in OO languages: you might start by defining a Rational class, and then extend that to include Imaginary numbers, and so on.

I'd guess that the reason that there aren't more languages with built-in support for exact types probably has to do with the fact that processors don't directly support such operations. Modern processors include instructions that implement arithmetic operations for floating point types, so it's easy to include those in any language. Supporting exact types would mean building a math library into the language, and it's probably better on several levels to leave the math library out of the language and let those who need it build it into their software.

If you're going to go to all the trouble to produce exact results, you probably don't want to limit yourself just to rationals, so the struct you give as an example isn't going to cut it. Being able to do exact calculations on rationals isn't very helpful if you fall back to inexact results the first time an irrational number shows up. Fortunately, there are sophisticated math systems out there. Mathematica is one well-known example.