Boost logo

Boost :

From: Guillaume Melquiond (guillaume.melquiond_at_[hidden])
Date: 2008-01-03 11:58:23

Le samedi 22 décembre 2007 à 16:03 +0000, John Maddock a écrit :
> Can someone explain what the issue is in converting an integer type to a
> boost::interval, and in performing mixed integer/floating point arithmetic
> and comparisons?
> Is it simply that the integer types may have more bits in their
> representation than floating point ones, and we may therefore loose
> precision?

Yes, that is the main issue I can think of.

> If so, can we not convert integers to intervals implicitly, complete with
> calculation of the error? That would auto-magically make mixed
> integer/floating point arithmetic work as well.

You are right for arithmetic operations. Note that it has a surprising
consequence though. It means that 2*i (with i of type interval<float>)
would be much slower than 2.0f*i, since operations involving
implicitly-singleton intervals are faster than operations on "wide"

It also does not work that well with comparisons. For example,
2147483600 < i may be true from a mathematical point of view. But when
the lower bound of i happens to be 2147483648, the comparison
interval<float>(2147483600) < i can evaluate to something else or throw
an exception (depending on the comparison kind).

> And yes, I'm prepared to invest some time to make this work and do the right
> thing, if time is the only stumbling block :-)

If you intend to work on it, you may want to take a look at the code
stored there:
This is a project aiming at transforming the Boost.Interval library so
that it matches the specification of N2137 while retaining
backward-compatibility. As a consequence, it provides a brand new
policy-based system, which should be a lot simpler to use than the
previous one, I hope. In particular, it would then be trivial to add a
"no integer / small integer / full integer" policy for dealing with the
issue at hand. But I am just thinking out loud and it may be too

Best regards,


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