RE: [boost] Interval Wrinkles

From: Paul A. Bristow (boost_at_[hidden])
Date: 2003-04-14 08:50:10

> And, abs([-2.1,-1.9]) == [1.9,2.1]; abs([-0.1,0.1]) == [0,0.1].

Rats! You have discovered that I am mathmetically challenged :-(

> All these results are deduced from the inclusion property, which is
> already in the documentation. Maybe some more examples of this property
> should be added.

But I doubt if I am alone in this sad state :-) So Yes.

> Maybe it is meant to be the square of a norm?
> In this case, the naming should be changed in my opinion.

Perhasp Neal will defer to your math expertise here?

> Expressions like T mean/integer count failed when T was an interval type.
> I half_x = x/2; // fails

> In order for the user to access integer functions, I can add this
> kind of code:
>
>   template<class T, class Policies>
>   interval<T, Policies> operator* (int x, interval<T, Policies> y) {
>     return static_cast<T>(x) * y;
>   }
>
> It will solve the issue. But it may induce some strange behavior when int
> is not exactly convertible to T. For example, x is not always equal to
> float(x) (for some big integers).

I think users using the library to handle measurement or computational
uncertainty will decide the utility is worth the risk.  For more mathematical
uses, it may not be. So

> to put these helper functions in a separate header that would not be included
by default sounds a sensible compromise.

> The display of intervals is something we didn't want to do. It's up to the
> user to define its own display. The header interval/io.hpp is merely
> provided as a debug facilities (it isn't included by default).

Some warnings/examples would help the naive user.

> So you are free to do whatever you want for the display of intervals, it's
> outside the scope of the library.

OK, I understand the limitations.  For handling measurements, the ideal is to
use the interval 'width' to chose the right precision (number of significant
digits).  I have found this gives a great improvement in clarity of display (in
other programs) and may be able to offer an alternative to your simple
interval/io.hpp.

> x1 = exp(x); // fails - exp_up and exp_down not a member ...

> So it isn't enough to only compute [exp(lower),exp(upper)], the
> function needs to compute [exp_down(lower),exp_up(upper)] in order for the
> result to correctly contain all possible results.
> The user needs to rely on an external mathematical library
> which provides them. And it's the reason why the library doesn't do
> anything by default.

> I will try to add an example which uses an external library.

Thanks. exp and log are likely to most useful because some math library
implementations introduce more than a few eps of computation 'error'.

Do I understand correctly that it is deliberate that (if cout.precision(17))

I x = 2.; // exactly representable as 2.00000000000000000
outputs:
[1.9999999999999993, 2.0000000000000004]

despite
2. is singleton true

[3.9999999999999991,4]
square(x) is singleton true

[1.9999999999999993,2.0000000000000004]
sqrt(square(-2.)) is singleton true
[3.9999999999999991,4]

Thus there is a ulp or eps/2 widening, even of a singleton.

If one wanted to show singletons explicitly, I presume I could test and only
output one central value?

> This code:
> using boost::numeric::interval_lib::pi;
> I a = pi<I>();
> works with GCC and Intel CC.,
but MSVC 7.0 says:

typedef boost::numeric::interval<double> I;
using boost::numeric::interval_lib::pi;
a = pi<I>();

testInterval.cpp(65) : error C2275: 'I' : illegal use of this type as an
expression
        testInterval.cpp(59) : see declaration of 'I'
testInterval.cpp(65) : error C2059: syntax error : ')'

but

I pi_d = boost::numeric::interval_lib::pi< boost::numeric::interval<double> >();
I pi_d1 = boost::numeric::interval_lib::pi<I>();

are OK,

so am I in bad company in my (lack of) understanding of C++ :-(

Paul

Paul A Bristow, Prizet Farmhouse, Kendal, Cumbria, LA8 8AB  UK
[phone]   Mobile [phone]
Mobile mailto:pabristow_at_[hidden]
mailto:pbristow_at_[hidden]