Which they tend to do a lot. Like, the moment a square root or trig function shows up.
Even without it’s pretty easy to overflow a fraction stored the way you’re describing. x=1/(x*x+1) does it in log time. There’s really not a lot of situations where exact fractions work, but purely symbolic logic wouldn’t. Maybe none, IDK.
Edit: I mean, I guess it’s all symbolic. What I’m trying to say is that if you’re at a level of detail where you can keep track of the size of denominators, native support for a type that hides them is counterproductive. It’s better to lay out your program in such a way that you just use small integers, which is guaranteed to be possible in that case.
There’s really not a lot of situations where exact fractions work, but purely symbolic logic wouldn’t. Maybe none, IDK.
Simulations maybe? Like the ones for chaotic systems where even the slightest inaccuracy massively throws the result off, where the tiny difference between an exact fraction and a float can seriously impact the accuracy as small errors build up over time.
Which they tend to do a lot. Like, the moment a square root or trig function shows up.
Even without it’s pretty easy to overflow a fraction stored the way you’re describing. x=1/(x*x+1) does it in log time. There’s really not a lot of situations where exact fractions work, but purely symbolic logic wouldn’t. Maybe none, IDK.
Edit: I mean, I guess it’s all symbolic. What I’m trying to say is that if you’re at a level of detail where you can keep track of the size of denominators, native support for a type that hides them is counterproductive. It’s better to lay out your program in such a way that you just use small integers, which is guaranteed to be possible in that case.
Simulations maybe? Like the ones for chaotic systems where even the slightest inaccuracy massively throws the result off, where the tiny difference between an exact fraction and a float can seriously impact the accuracy as small errors build up over time.