On Sun, 12 Dec 2004 18:10:58 -0700, Jonathan Turkanis <technews@kangaroologic.com> wrote:
This sounds like an argument for a checked_rational type, not for automatic rounding.
actually adding a "rounded" flag (e.g. stored in the sign bit of the denominator) is trivial and does not increase the complexity of the rounding code the thing is: rounding is a natural thing to rationals, not something superimposed on the arithmetic -- the gcd() function actually computes the sequence of more and more precise approximations until it reaches the exact number -- and i feel that with throwing this away we get rid of the very reason to use finite precision rationals (finite precision, fixed or floating slash) rational numbers are in many ways superior to (finite precision, fixed or) floating point systems, for example: - rationals are radix-independent while floats reflect the interaction of the radix and the number rather than the properties of the represented number itself (thus adding another layer of anomalies on top of the limitations inherent in finite precision) - of any two rational systems one is a refinement of the other (portability, here we come!), while different radix-based systems are simply different (and you are always using two of them, even on your PC: decimal for i/o and binary for computations) - rounding prefers simple fractions (there is a mathematical definition that nicely matches the intuitive concept) -- so even when your intermediate values are approximiations, you will still automagically get the exact result if it was 1/3
Depending on your requirements, the rounded or truncated results could be considered "unrelated garbage."
that is true: but then i should not be using any kind of finite precision arithmetic in the first place afaik cryptography and banking are the only such fields, everywhere else the goal is not to get exact results, but to get useable results usually your inputs aren't exact in the first place (no point in calculating the average salary of the people in your survey to 20 decimal places, as the individual salaries given are already rounded estimates), and even in cases where they are, it is pointless to calculate the length of the walls in the house you designed down to the atomic level imho the usual problem is that your intermediate values are inconsistent: the corner points of the surfaces of your wall are not equiplanar, so the roof becomes self-intersecting with a negative surface value
I understand the distinction you are making. But I don't yet see why it's necessarily worse than overflow.
overflow is the most natural consequence of using finite precision arithmetic. it is the easiest to understand, predict and prevent (in most applications you know in advance the magnitude of the numbers) garbage instead of rounding is counter-intuitive, unpredictable and practically impossible to prevent; would 1.0/3.0 result in a negative number instead of 0.333... no-one would be happy with floats
Boost.Rational has been around for almost 5 years now, and I don't believe it's had this effect.
do you know anyone who has been using it with built-ins? (this problem surfaced the second day i started using it, and i have spent a lot of time looking for the bug in my code before checking the boost::rational implementation :O) br, andras