bug-gmp
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: wishlist: support for long doubles; new add/multiply routines


From: Kevin Ryde
Subject: Re: wishlist: support for long doubles; new add/multiply routines
Date: 12 Aug 2001 07:37:33 +1000
User-agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.5

Dan Christensen <address@hidden> writes:
> 
> 1) It would be great to be have long double versions of the
>    mpf_set_d and mpf_get_d functions.

Yes they'd be good.  If you want to throw together your own it's just
a matter of getting the bits lined up to have the radix point on a
limb boundary, then setting f->_mp_exp appropriately.
__gmp_extract_double does that, though the code is rather uglified by
handling different limb sizes and possible non-IEEE float formats.

>    Am I overlooking any other workarounds?

If you want long doubles then I guess you have to have conversions.

> 2) I often find myself wanting to add or multiple a mpf_t variable
>    by a double (or long double).

Such mixed-precision functions would be quite useful, but will
probably end up waiting until a full set can be put together, since
it'd be rather tedious to have some combinations available and not
others.  A full set of _si functions falls into that category too.

>    Currently I need to declare a
>    second mpf_t, init it, mpf_set it, and do the mpf_mul.

If reentrancy isn't a worry then just one global init/clear could be
done.  Or if you don't mind getting into the mpf internals then you'll
see that a fake mpf_t can be set up on the stack with a fixed two
limbs, something like

        mpf_t      f;
        mp_limb_t  data[3];
        f->_mp_d = data;
        f->_mp_prec = 2;
        mpf_set_d (f, x);
        ...

>    It would be great if there was a function mpf_mul_d analogous to
>    mpf_mul_ui.  Here there is an obvious workaround, which is to
>    write this function myself using a temporary variable, but I
>    guess I'm wondering if a built-in function to do this might be
>    faster.

I guess knowing the operand is only 2 or 3 limbs it could avoid the
temporary memory and copying in mpf/mul.c (though I suppose that code
ought to do so itself when presented with 1 or 2 limb operands).



reply via email to

[Prev in Thread] Current Thread [Next in Thread]