Boost logo

Boost :

From: Gennadiy Rozental (gennadiy_at_[hidden])
Date: 2002-09-08 20:21:56

"Guillaume Melquiond" <gmelquio_at_[hidden]> wrote in message
> On Sun, 8 Sep 2002, Gennadiy Rozental wrote:
> > > > In general I think that your may struggle here because of the
> > in
> > > > Rounding policy design (see my review): it's to big and unite in one
> > bottle
> > > > several implementation dependent but independent from user
> > > > policies. This one would be The ConvertionPolicy. And though it may
> > > > some staff from other rounding policies it still independent
> > Once
> > > > it become independent player it will more easy to work with it,
> > particularly
> > > > to change it.
> > >
> > > Why do you think they are independent? Is there a good reason a user
> > > like to use precise computations and unprecise conversions (or the
> > > way around)?
> >
> > Under "They" I meant rounding abstraction "levels". Do you?
> >
> > > And you say they are "implementation dependent". I would have said
> > > are implementation inter-dependent.
> >
> > No. Every rounding abstraction "level" only depends on lower level for
> > implementation.
> So you seem to think there are more than one level?

No. It's you who seems to state that. Here is from docs:
"A lot of classes are provided. The classes are organized by level. At the
bottom is the class rounding_control. At the next level come
rounded_arith_exact, rounded_arith_std and rounded_arith_opp. Then there are
rounded_transc_dummy, rounded_transc_exact, rounded_transc_std and
rounded_transc_opp. And finally are save_state and save_state_nothing. Each
of these classes provide a set of members that are required by the classes
of the next level. For example, a rounded_transc_... class needs the members
of a rounded_arith_... class."

> Here is a part of the 'Rounding' policy for an interval type based on
> struct mpfr_rounded_math {
> mpfr_t add_down(const mpfr_t& x, const mpfr_t& y) {
> mpfr_t z;
> mpfr_add(&z, &x, &y, GMP_RNDD); // a function of MPFR
> return z;
> }
> };

And how mpfr_rounded_math is dependent on mpfr_t? What prevent you from
using template member functions and provide specialization for mprf_t? But
in fact there is more generic concern. See below?
> You think the part of the library responsible of the computations (the
> rounding policy) is not flexible enough. May I ask you what is the extent
> of your knowledge of interval arithmetic libraries, multi-precision
> arithmetic libraries and floating-point internals of various processors?

As I mentioned before I am not an expert in numeric computation but my
comments were based on my knowledge and experience in C++ language not a
specific domain. And they lay namely in generic domain. When I sad "is not
flexible enough" I meant namely "is not generic from C++ user stand point".
As an example let's try to answer following question:
What if I want to change only one function in rounded_arithmetic logic and
keep other existent levels implementation? rounded_math would not be of any
help here, while with simple change it could.
> > > > As I mention in my review I do not see the reason why Rounding
> > depend on T as a template parameter. Once you exclude T problem
disappear by
> > itself. If policies defines conversions, intervals are convertible
> I never said it was in the code. I just wanted to say that, in some cases,
> the lowest level of rounding (in the case there is more than one rounding
> level) needed to be type-dependent. And I was providing you the example of
> a processor where the rounding mode can be set to be precision-dependent.
> If you really want some code, just take a look at the file
> boost/interval/ext/x86_fast_rounding_control.hpp in the boost-sandbox
> cvs. The content and the usage of this file are not documented, but you
> will find some code that sets the FPU accordingly to the floating-point
> type used for computations.

Before I will proceed with reply I want to make one generic statement, based
in which we much more easily find a consensus. Here it is.
IMO following rule/ recommendation is correct: Never use template parameter
in sole purpose of introducing specialization later on in design of generic
There could be an exclusions but it is good as a generic rule.

Once we agree on this everything become more clear. Let's apply it to you
current example. x86_fast_rounding_control.hpp introduce 3 specializations
for x86_fast_rounding_control template:

x86_fast_rounding_control<long double>

As far as I understand they are supposed to be (or may be if supposed to be
picked up automatically) used for explicit specialization of
interval<float>,interval<double>, and interval<long double>. But with the
same success you could have implemented x86_fast_rounding_control_for_float,
x86_fast_rounding_control_for_long_double and use them in above
 You yourself sad that only rounding_control level in "some cases" needs to
be specialized for some types. Once you make every level as independent
player you will be able introduce whatever class you want in its place
keeping all other decisions as default. The interface may look like this (if
we would use NTP):
typedef interval<float,
rounding_control_is<x86_fast_rounding_control_for_float> >

> Regards,
> Guillaume



Boost list run by bdawes at, gregod at, cpdaniel at, john at