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

From: Guillaume Melquiond (gmelquio_at_[hidden])
Date: 2002-09-08 18:27:30

On Sun, 8 Sep 2002, Gennadiy Rozental wrote:

> > > In general I think that your may struggle here because of the problems
> in
> > > Rounding policy design (see my review): it's to big and unite in one
> bottle
> > > several implementation dependent but independent from user prospective
> > > policies. This one would be The ConvertionPolicy. And though it may need
> > > some staff from other rounding policies it still independent decision.
> Once
> > > it become independent player it will more easy to work with it,
> particularly
> > > to change it.
> >
> > Why do you think they are indepedent? Is there a good reason a user would
> > like to use precise computations and unprecise conversions (or the other
> > way around)?
> 
> Under "They" I meant rounding abstrction "levels". Do you?
>
> > And you say they are "implementation dependent". I would have said they
> > are implementation inter-dependent.
> 
> No. Every rounding abstrction "level" only depends on lower level for it's
> implementation.

So you seem to think there are more than one level? 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 all the functions of the policy are defined the same way. Do you still
think there is more than one level? In some particular cases, there are
two or three levels; but in the general case, there is only one level, in
particular when you don't rely anymore on hardware native types. Just
remember that 'interval<double>' isn't the only interval type the library
can handle.

> > You seem to think that it is easy to
> > separate them. I just suggest you to give it a bit of thought, and look
> > how the hardware solutions (processors FPUs) and software solutions
> > (libraries like MPFR) deal with rounding. If we had done this library in
> > order to be used with a specific processor or a specific library, it would
> > have been possible to simplify the design yes. But we wanted to do a
> > generic library, and there was only one solution: to separate all the base
> > type computations dependent stuff in one policy.
> >
> > So please stop thinking we love to use over-complex thingies. We really
> > give a lot of thoughts in this library.
> 
> Vice-verca, I think that the library should be a little bit more complex to
> be much more flexible.

I want to remind you the two purposes of this library. First it was to
provide a standard interface that could be used with the other existing
libraries. Second it was to be a really fast implementation on
floating-point types (so fast that we could change all the 'double' in a
program by 'interval<double>' without seeing a performance loss) without
sacrificing the precision of the computations.

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?

The previous question is purely rethorical and I won't be offended if you
don't answer it. But I would be very glad if you could give some details
showing that you really did think about the points you are criticizing.
All the other reviewers who suggested important changes to the library
gave concrete explanations of their opinion and even provided some working
code to support it.

> > > As I mention in my review I do not see the reason why Rounding policies
> depend on T as a template parameter. Once you exclude T problem disappear by
> itself. If policies defines conversions, intervals are convertible either.
> >
> > I'm not sure to know what you are talking about. If you are saying that
> > the rounding is independant from the base type, you're totally wrong.
> > I could give you a lot of explanations; but here is one you could easily
> > verify: just look at the 'precision field' of the 'control register' of
> > the x86 FPU. So, because the rounding can be type-dependent in some
> > situations, it's only natural that there is a template parameter.
> 
> Could you please be more specific and point to exact location in you code.
> Since I could not find nor 'precision field' nor 'control register' notions
> references.

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.

For the notions of 'precision field' and 'control register', just refer to
Intel's technical sheets about the floating-point unit of x86 processors.

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.

Regards,

Guillaume