mjhjmtu

My question is, why not use fractions?

Quick answer:

• Too much code needed


• Dynamic storage needed


• Long representation even for simple numbers


• Complex and slow execution

And most prominent:

• Because floating point is already based on fractions:
  Binary ones, the kind a binary computer handles best.
  

Long Form:

The mantissa of a floating point number is a sequence of fractions to the base of two:

1/2 + 1/4 + 1/8 + 1/16 + 1/32 + 1/64 + 1/128 ...

Each holding a zero or one denoting if that fraction is present. So displaying 3/8th gives the sequence 0110000...

A fraction is just two numbers which, when divided by each other, yields the number you are interested in. So picture a struct which holds one integer of whatever size, and one byte for each of divisor and dividend.

That 'whatever size' is eventually the most important argument against. An easy to implement system does need a representation as short as possible to save on memory usage - that's a premium, especially early machines - and it should use fixed size units, so memory management can be as simple as possible.

One byte each may not really be good to represent the needed fractions, resulting in a rather complicated puzzle of normalisation, which to be handled needs a rather large amount of divisions. A really costly operation (Hard or Softwarewise). In addition to the storage problem for the numbers, this would require even more address space to hold the non trivial handling routines.

Binary (*1) floating point is based on your idea of fractions, but takes it to the logical end. With binary FP there is no need for many complex operations.

• Turning decimal FP into binary is just a series of shift operations.


• Returning it to decimal (*2) is again just shifting plus additions


• Adding - or subtracting - two numbers does only need a binary integer addition after shifting the lesser one to the right.


• Multiplying - or dividing - means multiplication - or division - of a these two fixed point integers and addition of the exponent.

All complex issues get reduced to fixed length integer operations. Not only the most simple form, but also exactly what binary CPUs can do best. And while that length can be tailored to the job (*3), already rather thrifty ones (size wise) with just 4 bytes storage need will cover most of everyday needs. And extending that to 5,6 or 8 gives a precision rarely needed (*4).

And probably we all remember how to add or subtract fractions from school.

No, we don't really. To me that was something only mentioned for short time during third grade. Keep in mind most of the world already went (decimal) floating point more than a century ago.

*1 - Or similar systems, like IBM's base-16 floating point used in the /360 series. Here the basic storage unit isn't a bit but a nibble, acknowledging that the memory is byte-orientated and parts of the machine nibble-orientated.

*2 - The least often done operation.

*3 - Already 16 bit floating point can be useful for everyday issues. I even remember an application with a 8 bit float format used to scale priorities.

*4 - Yes, there are be use cases where either more precision or a different system is needed for accurate/needed results, but their number is small and special - or already covered by integers:)

There is a mathematical problem with your idea. If you choose to store fractions with a fixed-length numerator and denominator, that's works fine until you try to do arithmetic with them. At that point, the numerator and denominator of the result may become much bigger.

Take a simple example: you could easily store 1/1000 and 1/1001 exactly, using 16-bit integers for the numerator and denominator. But 1/1000 - 1/1001 = 1/1001000, and suddenly the denominator is too big to store in 16 bits.

If you decide to approximate the result somehow to keep the numerator and denominator within a fixed range, you haven't really gained anything over conventional floating point. Floating point only deals with fractions whose denominators are powers of 2, so the problem doesn't arise - but that means you can't store most fractional values exactly, not even "simple" ones like 1/3 or 1/5.

Incidentally, some modern software applications do store fractions exactly, and operator on them exactly - but they store the numerators and denominators using a variable length representation, which can store any integer exactly - whether it has 10 digits, or 10 million digits, doesn't matter (except it takes longer to do calculations on 10-million-digit numbers, of course).

Floating-point isn't just about representing numbers that have fractional parts. It's also about representing numbers that are very large, or very small, in a way that allows extra range by sacrificing precision.

Consider these examples:

1,000,000,000,000,000,000,000,000,000,000 (1 with 30 zeros after). This number can be reasonably stored in floating-point format in 8 bytes with some loss of precision (reduced number of significant digits). To store it as an exact fraction, you need considerably more space.

Similarly, the fraction 1/1,000,000,000,000,000,000,000,000,000,000 has the same problem. It's still 8 bytes in floating-point but much larger as a fraction.

Because floating-point has an exponent that's stored separately from the mantissa, this gives it the ability to represent a larger range of numbers, even if every number within that range cannot be represented exactly. This is a valuable tradeoff because in many applications only a limited amount of precision (significant digits) is needed so this saves memory, which is especially at a premium on small systems (and in the beginning, all systems were small by today's standards).

Point by point.

• faster addition/subtraction
  
  No: 8/15 + 5/7 is evaluated as 131/105 [(8*7 + 15*5)/(7*15)], so 3 multiplications for one single addition/subtraction. Plus possibly reduction



• easier to print
  
  No: you have to print a human readable string of digits. So you must transform 131/105 to 1.247... Or are you proposing to simply display the fraction? Not so useful for the user.
  PRINT 12/25 --> RESULT IS 12/25




• less code
  
  No: floating point code is compact, it's just shifting all in all




• easy to smoosh those values together into an array subscript (for sine tables etc)
  
  I don't understand what you mean. Floating point 32 or 64 bit values can be packed togeter easily




• easier for laypeople to grok
  
  Irrelevant, laypoepole do not program the bios of microcomputers. And statistics tell us that most of laypeople do not understand fractions anyway




• x - x == 0
  
  The same in floating point

Some modern programming languages do have a Rational or Fractional type, so your idea has merit.

However, there are and were several different problems with it. It's worth noting that, even on systems where floating-point also needed to be implemented in software, fractional math wasn't widely-used as an alternative. Some possible reasons that applied at the time:

• The 8-bit computers you list used either the Zilog Z80 or MOS 6502 CPU, which had no hardware multiply instruction. (The Motorola 6809, used in the Tandy CoCo, did.)


• Adding or subtracting rationals requires computing greatest common divisor or least common multiple, which could be done without division but still would have been very slow compared to the shift-and-add of floating-point numbers, and then both multiplication and division (which was even slower).


• Reducing fractions to their canonical form would also have involved calculating GCD and dividing.


• Multiplication and division of floating-point is also simpler: multiply mantissas, add exponents.


• While floating-point math needs only a few extra guard bits of precision, exact multiplication of rationals requires doubling the number of bits, so to be able to compute a/b + c/d where a, b, c and d have 16-bit precision, then find the GCD of ad+bc and bd and divide both the numerator and denominator, you would have needed 32-bit math on an 8-bit ALU with no hardware multiplier or divider.


• Many values that programmers want to work with are irrational, most famously Ï€ and the square root of 2.


• It wasn't how math had always worked on mainframes and minicomputers, and wouldn't have been acceptable for scientific computing.


• Fixed-point was a simpler alternative for most use cases. You typically know what an acceptable lowest common denominator for your problem domain is, and then you only need to store the numerators and the math becomes easy.

In the era of 16-bit microcomputers, floating-point coprocessors appeared on the market that were hundreds of times faster, systems that did not have the coprocessor emulated them, and their functionality became IEEE standards, although many games and applications continued to use fixed-point. In the late '80s, floating-point math became integrated into the CPU cores themselves.

In fact, fractions often are used, especially by wise programmers on systems without hardware floating point capability. However, generally this is done where the same denominator can be used for all values to be considered in a particular computation. For a fixed denominator to work, the programmer must start by figuring out the maximum range of values and the required precision, determine a denominator which supports this, and then write the relevant portions of the program in the context of that. In simpler cases no actual manipulation of the denominator is needed - its just implicitly assumed all the way through, though when multiplying two fractional values adjustment is of course required. Most often the denominators chosen are powers of two, so this adjustment typically ends up being a simple arithmetic shift - or in the simplest case, the denominator is the word width, so the shift is accomplished by not even bothering to perform the parts of the calculation which would produce the discarded part of the result.

Ultimately, the choice between computation which uses a fixed denominator, verses the variable binary exponents of floating point (when unassisted by hardware) is a software decision, not a hardware one.

Programmers writing efficient, high performance code for such platforms would use integer or fixed fraction arithmetic, then and also today. Programmers needing to deal with a wider range of values, or working on a program that would take longer to write than the amount of time users would ever spend waiting for it to run, might find floating point more suitable or more convenient.

If the systems you mentioned had a norm, it was likely more with packaged languages, especially a ROM BASIC. Typically, if someone is writing in BASIC, they want flexibility and approachability more than speed, and so many BASICs had their default variable type floating point (in effect, "hey computer, figure out how to represent this for me"). However, it was not uncommon for a BASIC to also support explicitly declaring a variable as an integer type. And of course some of the smaller/earlier ROM BASICs such as Apple's Integer BASIC didn't support floating point to begin with.

One more point on the topic. Floating-point was designed so that almost all bit patterns of a memory representation of a number were used meaningfully. With the exception of zeros, infinities and NaNs, every bit pattern is a different number. On the other hand, when using fractions, you get 1/2 == 2/4 == 3/6 == … etc. You either keep normalizing fractions (and end up never using bit patterns corresponding to non-normalized fractions), or having trouble even comparing numbers. So, in your proposed case of a byte for divisor and a byte for dividend, out of 2¹⁶ bit patterns available for two bytes:

• there are at least 127 bit patterns that represent 1/2,




• there are at least 85 bit patterns that represent 1/3 and 2/3 each,




• there are at least 63 bit patterns that represent 1/4 and 3/4 each,




• there are at least 51 bit patterns that represent 1/5, 2/5, 3/5, 4/5 each,

…and for these 9 fractions you're already using almost 1% of all possible bit patterns ("at least" depends on defining corner case semantics, like: what number is represented when the divisor is zero?).

What's more, you're wasting close to half of all possible bit patterns on numbers where divisor > dividend.

dirkt and alephzero provided definitive general responses. Mine is focused on one element of your question, the structure used to store a fraction. You proposed something on the order of:

struct mixedFrac 
 int whole;
 uchar dividend;
 uchar divisor;

Note that this pre-limits general accuracy; there is only so much precision an 8-bit divisor can depended on to provide. On the one hand, it could be perfect; 78 2/3 could be represented with no loss, unlike with floating point. Or it could provide great (but not perfect) accuracy, such as pi at 3 16/113 (accurate to 6 decimal places). On the other hand, an infinite quantity of numbers would be far from accurate. Imagine trying to represent 1 1/1024. Within the structure, the closest you could get would be 1 0/255.

The proposed structure could be easily simplified and improved with the use of a different structure:

struct simpFrac 
 long dividend;
 ulong divisor;

Since the divisor is now represented with much more precision, a much wider span of general accuracy is allowed. And now that approximation to pi can be shown in traditional fashion, 355/113.

But as the others have pointed out, as you use these perfect to very accurate fractions, you lose precision quickly, plus the overhead of maintaining the "best" divisor for the result is quite costly, especially if a primary goal of using fractions was to keep things more efficient than floating point.

Consider fixpoint arithmetic, that is pretty much what you are looking for:

A 32-bit value can, for example, be split in 2 16-bit values with an implicit "binary point" between them. π, for example, would then be expressed with

1 * 2 + 1 * 1 + 0 * 1/2 + 0 * 1/4 + 1 * 1/8 + 0 * 1/16 + 0 * 1/32 + 
1 * 1/64 + 0 * 1/128 + 0 * 1/256 + 0 * 1/512 + 0 * 1/1024 +
1 * 1/2048 + 1 * 1/4096 + ....

That is pretty much a representation in fractions. The downside is a relatively small range of values, but if you can live with that, the upside is blazingly fast operations and a relatively good precision within the number range.

Old flight simulators used to use a system called binary scaling. This was a system where an imaginary binary point was set on an integer.

What that meant was the numbers above the `binary point' were ascending powers of two, and those below descending.

Use of fractions to represent any scale number to maximum accuracy of the integer!

It meant they could get away without using slow floating point processors. Also binary scaling means more accuracy, because some of the bits in a float/double/REAL are used to hold the scaling. Binary scaled values used the context to store this information.

See https://en.wikipedia.org/wiki/Binary_scaling