mpfr
Hans Aberg
haberg at math.su.se
Fri Mar 12 11:16:43 CET 2010
On 12 Mar 2010, at 11:06, Paul Zimmermann wrote:
>> What do you mean by "more importantly" - I made a Guile SMOB, and
>> then
>> custom allocators are necessary to make use of its conservative GC.
>
> I mean that if there was no custom allocators in GMP, it would take
> a few
> days or weeks to implement them.
And then yo would have to update whenever MPFR issues version. So
unless you like, that, absence of custom allocators would have menat
it would have been unusable.
> But if there was no mpn layer in GMP, it
> would take years to implement them (I mean as efficient as GMP is)!
By contrast, this is is irrelevant for those that want to use the
library - it belongs to the implementation.
>> I have an idea of yet another floating point type, where the (binary)
>> precision is computed automatically based on the operation and its
>> arguments. Right now, it has to be done by hand for each operation,
>> it
>> seems.
>
> right, with MPFR the user has a full control of the precision and
> rounding
> modes. Note that the C++ interfaces for MPFR already do what you
> want to do:
> when writing "a = b + c" they automatically determine the precision
> of a
> (with different strategies depending on the particular interface).
I recall an interface that want to a backtrace precision for the result.
I had in mind an error analysis.
> But maybe this is off-topic for the gmp-discuss list. I suggest we
> continue
> to discuss on the MPFR list if needed.
Don't know - the GMP floating type is sort of limited, so it might be
of interest in that context.
Hans
More information about the gmp-discuss
mailing list