
Boost : 
From: Andras Erdei (aerdei_at_[hidden])
Date: 20041214 06:34:03
On Sun, 12 Dec 2004 18:10:58 0700, Jonathan Turkanis
<technews_at_[hidden]> 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 radixindependent 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 radixbased 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 selfintersecting 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 counterintuitive, unpredictable and
practically impossible to prevent; would 1.0/3.0 result in a
negative number instead of 0.333... noone 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 builtins?
(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
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk