Re: [boost] Re: Re: Re: Formal Review for IntervalLibrary(was:IntervalLibraryreminder)

From: Guillaume Melquiond (gmelquio_at_[hidden])
Date: 2002-09-09 01:28:18

On Sun, 8 Sep 2002, Gennadiy Rozental wrote:

> > > No. Every rounding abstraction "level" only depends on lower level for
> it's
> > > 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."

You were confused by these classes and the documentation. These classes
aren't policies but helper classes for helping to build the rounding
policy. The user is absolutely not forced to use them. The requirements of
the rounding policy are clearly stated in the documentation and you don't
have to use these helper classes if they are not adapted to the situation 
(and in many cases they will not) or if you don't want to.

This whole discussion was about your suggestion of creating a conversion
policy and separating it from the rounding policy. So let's come back to
this subject and please provide some details about the way to do it.

> > Here is a part of the 'Rounding' policy for an interval type based on
> MPFR:
> >   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?

What are you speaking about? It was just an example of a "one-level"
rounding policy.

> > 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.

What is this "simple change"?

> 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
> library.
> *********************************************************
> 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<float>
> x86_fast_rounding_control<double>
> 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_double,
> x86_fast_rounding_control_for_long_double and use them in above
> specializations.

I don't agree with you about your rule/recommendation. I would like to be
able to write some generic code like:

   rounded_arith_opp<T, x86_fast_rounding_control<T> >

Why should I be forced to write:

  rounded_arith_opp<float, x86_fast_rounding_control_for_float >
  rounded_arith_opp<double, x86_fast_rounding_control_for_double >
  rounded_arith_opp<long double, x86_fast_rounding_control_for_long_... >

Your rule is probably right when the specialized isn't used in generic
code afterwards. But what if it is?

>  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> >
> my_float_interval;

So, no more generic code?

Moreover, just remember that your 'x86_fast_rounding_control_for_float'
only define some functions that are not even part of the requirements of a
rounding policy. So you really can't use it as the 'Rounding' parameter of
'interval'. One more time, this is only an helper class.

Regards,

Guillaume