Boost logo

Boost :

From: Andras Erdei (aerdei_at_[hidden])
Date: 2004-12-14 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 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

- 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

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

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

> 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)


Boost list run by bdawes at, gregod at, cpdaniel at, john at