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

From: Guillaume Melquiond (gmelquio_at_[hidden])
Date: 2002-09-08 05:36:58

On Sun, 8 Sep 2002, Gennadiy Rozental wrote:

> >   struct my_rounding {
> >     ... // all the previous stuff
> >     template<class Dest> Dest convert_up  (const T&);
> >     template<class Dest> Dest convert_down(const T&);
> >   };
> >
> > That's a solution. Another solution would be to have the conversion the
> > other way around: 'template<class Src> T convert_...(const Src&);'. But
> > these solutions suffer from the same drawback: when an user wants to add a
> > new conversion to an existing policy, it's suddenly become less trivial
> > (in my opinion).
> 
> How come? could not you just introduce specialization for the member
> function?

I never said that it was not possible; I just said that it was not
easy: you need to know the implementation details of the existing policy
before adding a new conversion.

> 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)?

And you say they are "implementation dependent". I would have said they
are implementation inter-dependent. 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.

> And here reply to Herve:
> > We didn't provide it in the end because the problem remains for
> > converting the policies. You may have interval<float> with your own
> > rounding policy and it's not clear at all we can convert this rounding
> > policy to operate on double, unless we know which policy you are using.
> > We could offer the functionality for just the default policies, but that
> > wouldn't be a generic solution.
> 
> 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.

Regards,

Guillaume