|
|
Boost : |
From: Guillaume Melquiond (gmelquio_at_[hidden])
Date: 2002-09-09 04:46:57
On Mon, 9 Sep 2002, Gennadiy Rozental wrote:
> > 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.
>
> You see, as I am trying to explain, IMO problem lays in original design on
> Rounding policy, which is too bulky and inconvenient to update. That is why
> you were struggle adding anything new. My point was and is that once you
> segregate Rounding policy interface on several parts "layers" it would be
> much more easy to add something new. You current internal separation on
> layers seems to be a good fit. I was just proposing to bring it close to the
> light. On the other hand I agree with you that we do not force namely this
> separation in any case. So we keep Rounding policy as one template parameter
> of interval with one bulky contract. What we need is one implementation of
> the Rounding policy that is based in the segregation mentioned above. And we
> already have almost what we need: class rounded_math. It's just not flexible
> enough yet. In a review and later I was proposing to change the design of
> class rounded_math and others classes involved in this segregation.
Now I understand what you were talking about. Unfortunately, you think
that our "current internal separation on layers seems to be a good
fit". It's where we disagree.
As I explained by providing the code for an interval class based on MPFR,
there are a lot of situations where segregating between 'control',
'arith', 'transc' and 'conversion' is a bad solution. And it's the
reason why we didn't do something that looks like what you suggest.
So, let's see. On x86, Sparc and PPC, 'control', 'arith', 'transc' can be
left segregated (even if there are a lot of restriction on 'transc' that
would suggest a close bound with 'arith'); but 'conversion' need to be
merged with 'control' since it's a closely related hardware-dependent
thing. However, it only need to be merged with 'control' for conversion
with another primitive floating-point type.
On Alpha processors, 'arith' and 'transc' can still be left
segregated; but 'control' need to be merged with 'arith' in order to
fully exploit the instruction set of the processor.
With an exact type like rational, there is no 'control', and 'sqrt' which
is in 'arith' should be merged with 'transc'.
With a multi-precision library like MPFR, there is no 'control'; and
'arith' and 'transc' are merged.
On a processor without support for transcendental functions (PPC for
example), you may want to let the processor handle arithmetic computations
on double and to let a multi-precision library handle transcendental
functions. In that case, 'transc' rely on its own 'control' that is
different from the 'control' used by 'arith'. And 'conversion' need to
know that some internal conversions may be in use between the two number
format.
And so on, there are a lot more examples where this layered policy isn't
adapted.
So I hope you now understand that the "internal" layer model was only
meant to define policies for hardware closely related floating-point
types. And it's really a bad idea to try to extend it to a generic
interface. I personally would vote NO against such a library (unless the
library only manipulates 'interval<float>' and 'interval<double>').
I don't need to discuss the rest of your mail. Thank you for having
provided some code. However the first step is not to ameliorate the
current internal model, but to provide a new model that would really be
generic.
Regards,
Guillaume
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk