Is that because you can express a rotation (etc) as a matrix? If so, don't you need to be able to do the trigonometry exactly to create a correct rational matrix in the first place? What am i missing?
Or is it that you just don't need to do those sorts of operations at all inside the renderer?
As far as construction of rotation matrices goes, most of that will be baked before rendering a frame, so expensive trigonometric calculations and their conversion to rationals will occur ahead of time and therefore much less frequently than anything done per pixel, improving performance.
In computer graphics, because a great many calculations need to be done for each pixel to be displayed, use of expensive functions tends to be avoided. In the literature I recall reading a number of triangle-ray intersection algorithms where each breaks down precisely how many adds, multiplies, divisions, etc are performed because the goal is to minimize all these things. If you are intersecting 10 triangles per pixel at 2 million pixels per frame, a single multiply per intersection becomes 20 million multiplies per frame. By contrast, recalculating the camera matrix using expensive functions should only happen once per frame.
It is usually (but not always) possible to reframe problems in such a way that exponentials (including sine/cosine/tangent) and logarithms (including arcsine, arctangent, ..) are unnecessary.
Vector methods are much faster, have fewer weird edge cases, are less subject to rounding error, etc.
As an example: if you want to store a planar vector, use a pair of coordinates instead of an angle measure and magnitude. If you want to store an 2d orientation or rotation, still use a pair of (x, y) coordinates on the unit circle instead of angle measure (which is a logarithmic quantity). If you want to reduce your pair of coordinates to a single number, use the stereographic projection, which only requires division.
Both methods result in "holes" bellow zero (necessarily of course), but they do not fit inside each other. However within a limited set of operations, rational numbers (within a capable format, and with necessary operators) have some interesting properties over floating point math that makes them desirable, i.e not loosing precision (unless overflow due to encountering large primes), and they are less expensive (built on integer math).
What he did do, is make a rational number bit format (floating bar) which stores everything as fractions, it's quite elegant really and anyone familiar with IEEE754 will see the similarities.
Quilez's concern with how the number fits into 32 or 64 bits may be necessary for performance, but using arbitrary precision numerators and denominators is the only way to achieve the robustness he was initially pursuing.
