RE: [boost] Interval Wrinkles

From: Paul A. Bristow (boost_at_[hidden])
Date: 2003-04-13 04:07:55

> -----Original Message-----
> From: boost-bounces_at_[hidden]
> [mailto:boost-bounces_at_[hidden]]On Behalf Of Guillaume Melquiond
> Sent: Friday, April 11, 2003 1:06 PM
> To: Boost mailing list
> Subject: Re: [boost] Interval Wrinkles
>
> > using namespace boost::numeric; // BEFORE
> > #include "stats.hpp"
>
> It shouldn't be needed. 'abs' is defined in the same namespace than
> 'interval' so the name resolution should find the correct version of
> 'abs'. Am I missing something here?

It seems to be needed. I too suspect the  MSVC 7.0 compiler. With luck 7.1 will
be better.

> > In doing do, I found that
> >
> > typedef boost::numeric::interval<double> I;
> > I x = -2.;
> > I x = boost::numeric::abs(x);
> >
> > works as expected, but I was puzzled that
> >
> > using boost::numeric::abs;
> > T absx = abs(x); // failed (with MSVC 7.0) because interval
> policies not found.
>
> Is it only a typo in your mail or did you really try to convert the result
> of 'abs(x)' to the type 'T'? The function 'abs' computes:
>
>   abs(X) == {abs(x) | x in X}

Not being a mathematician, I naively expected abs of the interval [-1.9, -2.1]
to return [1.9 , 2.1], but on giving it more a millisecond of thought, I can see
that [-0.1, 0.1] would not be so useful. Worth documenting for other interval
novices?

> In the next version of the library, there will be a new function called
> 'norm' that returns:
>
>   norm(X) = max {abs(x) | x in X}
>
> Maybe it's this kind of behavior you were expecting?

I suspect so. Neal Becker's version 2 includes an externally defined norm

template<typename T>
T Norm (T x) { return x * x ; }

If this exists, I'd be grateful for it.

> > I absx = boost::numeric::abs< boost::numeric::interval<double> >(x);
> >
> > testInterval.cpp(96) : error C2783: 'boost::numeric::interval<T,Policies>
> > boost::numeric::abs(const boost::numeric::interval<T,Policies> &)'
> >  : could not deduce template argument for 'Policies'
>
> In fact, the definition of 'abs' is:
>
>   template<class T, class Policies> inline
>   interval<T, Policies> abs(const interval<T, Policies>& x)
>
> So if you want to fully qualify the expresion, it should be:
>
>   I absx = boost::numeric::abs< double, I::traits_type >(x);

> One more time, the compiler doesn't find the correct version of 'abs'.
> Since I don't use MSVC 7, I can't really help you. But I think it's a bug
> in the compiler.

I more than suspect that you are right.

> > 2    I found several places where expressions like T mean/integer
> count failed
> > when T was an interval type.  This is because there is no conversion from
> > integer, though there is from double etc. writing mean/T(count) works OK.
> >
> > I half_x = x/2; // fails
> > I half_x = x/2.0; // OK
> > I half_x = x/ I(2); // OK
> >
> > This is a very common situation and would be helpful to avoid
> widespread changes
> > to existing code - but perhaps this is an exercise for the student :-)
>
> Yes, there are only mixed operations between expressions of type
> 'interval<T,_>' and 'T'. So it is normal for the first expression to fail.
> The correct way to do it is:
>
>    I half_x = x/T(2);
>
> We didn't include automatic promotion of 'int' to 'T' or 'interval<T,_>',
> because the library don't have any information of the validity of the
> conversion between 'int' and 'T'. If you think it is needed, we can add
> it.

It feels a reasonable assumption that an integer 2 is 'exact' and so should be
converted to a 'singleton' interval [2.00000000000000000, 2.000000000000000000]?

Lots of type templated code is going to assume this (and so require lots of
tiresome modifications to make it 'interval-type compatible'). So unless there
is any really good 'interval maths disadvantage' I think this would be a good
thing.

(In passing, I note the display style might optionally allow a display if the
number is 'exact', for example [2.] rather than [2., 2.]?  I know you can get at
this using the singleton function. I find the way the display of
interval<double. changes with precision slightly surprising - as you change
cout.precision(2) to precision(16) you get [1.9, 2.] ... [1.999999999999999,
2.].

> > 4   x1 = exp(x); // fails - exp_up and exp_down not a member ...
> >
> > I:/boost_1_30_0\boost\numeric\interval\transc.hpp(39) : error
> C2039: 'exp_up' :
> > is not a member of 'boost::numeric::interval_lib::rounded_math<T>'
> >         with
> >         [
> >             T=double
> >         ]
> >         I:/boost_1_30_0\boost\numeric\interval\hw_rounding.hpp(50) : see
> > declaration of 'boost::numeric::interval_lib::rounded_math<T>'
> >         with
> >         [
> >             T=double
> >         ]
>
> Yes, it's normal. Because we don't expect the mathematical functions to be
> correctly rounded (and so the results would not be correct), the exp_up
> and exp_down are not provided by default. In the first version of the
> library, there were placeholders for these functions. But during the Boost
> submission, the reviewers explained they prefered the compiler to return a
> compilation error rather than the functions to return an unusable result
> ('exp(x)' would have been '<0,+inf>'). So we removed them.
>
> > 5  similarly with log_up and log_down.

If you are using an interval<double> x to hold information about uncertainty,
then is it reasonable to expect exp(x) to give [exp(x.lower(), exp(x.higher()]?

So if the user wants this, he has to provide them?
(I believe this will be a common requirement, and optional code examples would
be helpful).

> > 6  Using interval pi I was puzzled that:
> >
> > 	using boost::numeric::interval_lib::pi<
> boost::numeric::interval<double> >; //
> > triggers compile fail at pi<I>()
> > 	using boost::numeric::interval_lib::pi; // illegal use of expression
> > 	I pi_d = pi<I>();
> >
> > whereas
> >
> > 	using namespace boost::numeric::interval_lib;
> > 	I pi_d = pi<I>();
> > and
> >
> > 	I pi_d = boost::numeric::interval_lib::pi<
> boost::numeric::interval<double>
> > >();
> >
> > are fine.
>
> I'm not sure to understand what you mean. Is it supposed to be another
> deficiency of the compiler?

Or is it my (lack of) understanding of C++?

Thanks for your prompt assistance.

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