
Boost : 
From: Paul A. Bristow (boost_at_[hidden])
Date: 20030413 04:07:55
> Original Message
> From: boostbounces_at_[hidden]
> [mailto:boostbounces_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 'intervaltype 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
+44 1539 561830 Mobile +44 7714 33 02 04
Mobile mailto:pabristow_at_[hidden]
mailto:pbristow_at_[hidden]
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk