Re: [boost] [Interval] Conversion from integer types?

From: John Maddock (john_at_[hidden])
Date: 2008-01-03 12:21:12

Guillaume Melquiond wrote:
> 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"
> intervals.

:-(

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

Yes, I'm already knee deep in the comparison issues !

>> 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: https://gforge.inria.fr/projects/std-interval/
> 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
> far-fetched.

Ah, I was wanting to do the minimum amount of work necessary ;-)

I already have some patches for the existing Boost.Interval code that 
effectively fix the mixed integer/floating point arithmetic issue (I hope). 
I hadn't realized that there was a new design floating around.  I'll take a 
look but don't hold your breath :-)

Does this mean that you're not keen on patches to the the existing 
Boost.Interval code?

Thanks, John.