RE: [boost] Formal Review for Interval Library - which significand constants needed?

From: Paul A. Bristow (boost_at_[hidden])
Date: 2002-09-08 06:19:46

I understand your valid point,
but I think that the number of significand counts
is quite small (fingers of both hands)
and we can predict them well enough to meet almost all requirements.

Anyone who needs to add a new one will also need to have
the arbitrary high precision arithmetic package
to calculate the new constants, so it will probably fall to the maintainer
of the constants anyway.

(I have used NTL written in C++ which is GPL licence -
and written a proper Standard C++ program to write the C++ code.
It would be well beyond my skills with a scripting language,
and I would doubt if it is sensible to try).

So that persuades me to stick with Sylvain's iffy solution.

I am less clear what to do for a 'default' solution when
numeric_limits<>::digits
is not known at all, or the interval are not implemented for that value.

Ideas on how to generate a default interval?

Can I also ask here for views on which are needed apart from the
obvious IEEE 24, 53, and 64, and 106 and 112 and 128?
(These are values from numeric_limits<FPType>::digits

aka DBL_MANT_DIGS etc where provided by a macro.

Paul

> -----Original Message-----
> From: boost-bounces_at_[hidden]
> [mailto:boost-bounces_at_[hidden]]On Behalf Of Herve Bronnimann
> Sent: Saturday, September 07, 2002 10:14 AM
> To: boost_at_[hidden]
> Subject: Re: [boost] Formal Review for Interval Library- getting
> intervalsof constants
>
>
> On Fri, Sep 06, 2002 at 08:14:14PM -0400, Sylvain Pion wrote:
> > So now can you answer my initial question, then ?  Is there a nicer
> > way to do it, and if yes, which one ?
> >
> > (template stuff is nice, but it doesn't really simplify the complexity
> > I'd like to get rid of, i.e. that all cases of digits/radix basically
> > have to be treated separately).
>
> You're right, in the template stuff as well as in the ?: solution,
> you have to supply a different decimal string for your
> constants. And it's easy once all the parameters are known to compute
> the constants off-line and put them in the compile-time header.
>
> But I thought at least with the template stuff it's easy to add them
> independently one by one, so you can divide them up into headers and
> include only the headers that specify the specializations that
> are relevant for your setup. Pretty much the same way as
> roundings are specified with one header per platform in
> interval/detail/...
>
> But that's still an awful lot of constants to provide and you probably
> want to write a script to generate those headers. The advantage of
> template<int> solution over ?: is that you can provide the script, so
> users can generate the missing header for their platform if you don't
> supply it. Whereas it's impossible for them (short of modifying the
> library code) to change the ?: expression.
>
> Now you are still looking for a solution that would bypass that, and
> that's a worthy goal. The above is just a solution within what is known
> to work already.
> My two cents,
> --
> Herve'
>
>
> _______________________________________________
> Unsubscribe & other changes:
> http://lists.boost.org/mailman/listinfo.cgi/boost
>