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

From: Neil Groves (neil_at_[hidden])
Date: 2008-01-04 08:40:57

Are you certain that mixing floating-point types and integral types is
desirable?

floating-point types are, of course, approximations unlike integer types. It
is dangerous to mix the two, and the approach to do so should not be allowed
even by a policy. Mixing floating point types with integer types implicitly
is a poor software engineering practice without merit in my humble opinion.

Implicit type conversion has been a frequently regretted design decision in
my experience despite the initial syntactic appeal.

Neil Groves

On Jan 3, 2008 5:21 PM, John Maddock <john_at_[hidden]> wrote:

> 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.
>
> _______________________________________________
> Unsubscribe & other changes:
> http://lists.boost.org/mailman/listinfo.cgi/boost
>