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).
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. Best regards, Guillaume