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@johnmaddock.co.uk> 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