Large denominators are not a problem

[edgar-bonet]

The page Rounding Errors contains this paragraph:

Large Denominators In any base, the larger the denominator of an (irreducible) fraction, the more digits it needs in positional notation. A sufficiently large denominator will require rounding, no matter what the base or number of available digits is. For example, 1/1000 cannot be accurately represented in less than 3 decimal digits, nor can any multiple of it (that does not allow simplifying the fraction).

This is incorrect. A large denominator does not necessarily imply rounding. For example, the number 1/1000 can be exactly represented with only one decimal digit in the significand:

1/1000 = 1 × 10⁻³

The paragraph is of course correct if interpreted in the context of fixed point numbers. However, the whole site is about floating point. The page on floating point numbers, which in the menu comes before this one, already introduced the concept using decimal floating point (the same scientific notation I am using here) as a teaching aid. The paragraph right before this one links back to floating point numbers and frames the subject of the page as being about the rounding errors with floating point numbers. At this particular point in the material, it makes no sense to discuss rounding issues specific to fixed point.

I have no simple alternative to suggest. My understanding is that this first bullet point is meant to cover the cases not covered by the following ones. Namely those numbers that can can be exactly represented with a finite number of significant digits in the chosen base, but require more digits than available in the format. A large denominator is not a sufficient condition. Neither is a large numerator. A sufficient condition would be for both the numerator and the denominator to be large, but I am not sure how to word that in a way that remains simple to understand.

[brazzy]

You're right - I really wasn't thinking very deeply when i wrote that. I rewrote the section completely with commit cee8edb, hopefully correctly.