Why does Swift not support rational numbers?

[taylorswift]

@scanon

• If you round results, it is always strictly better to use floating-point, because it has scale invariance and fewer redundant representations, so for any fixed precision it has smaller error.
• If you do not round results, the sizes of the numerator and denominator grow exponentially in general.
• Because of this, any non-trivial fixed-size rational program overflows immediately.

i am not sure if the first two observations support the conclusion here. in a lot of financial applications, there are formulas that must be applied in exact rational form, but the operation depth is fixed such that the implementation does not “overflow immediately”, although the number of bits needed to represent the result may be very large, larger than can fit into a Int64.

in the end, we must always round the result such that customers are not transacting in increments of dust, but it is incorrect to say it is “always strictly better to use floating-point”. sometimes the rounding is decimal-based, sometimes it is contract-defined, and sometimes it is designed simply to rob people of their dust (way more common than you think, because it’s almost impossible to notice, and usually dwarfed by explicit fees anyway.) but it is very, very rarely performed using floating-point arithmetic.

there are a lot of reasons for this, a few of which i can think off the top of my head:

• business-type people tend to have a hard time understanding floating point,
• contracts are usually defined using ratios, and executing them with floating point opens up a small but non-trivial possibility of major headaches down the road. (but i’ve personally never witnessed anyone get sued over it, because the amounts in dispute are usually quite small. and truth be told, there are a lot of shady things being done to dust on purpose anyway.)
• floating point transactions are really hard to audit, because of scale invariance. this doesn’t always involve wrongdoing, a lot of times people just make small mistakes implementing things, and having a large error tolerance to account for floating point error makes it harder to catch these kinds of bugs.

but i think the first of those reasons is probably by far the most important.

the most commonly-occurring denominators for these kinds of rational parameters are multiples of 10, so this tends to get boxed into a “decimal problem”. but i’ve also seen denominators like 24, 60, etc. compounded interest is weird.