mpz_limbs interface

[Niels Möller]

Marc Glisse <marc.glisse at inria.fr> writes:

> Why not return int, since int is what we use for _mp_size?

int would be sufficient for all known float formats I guess. I choose
long because that was the signed type closest to mp_bit_cnt_t.

> Is 53 really safe for non-IEEE double? Maybe something based on
> DBL_MANT_DIG, assuming that FLT_RADIX==2?

The existing code was limited to 53 bits (e.g., in the definition of
LIMBS_PER_DOUBLE), I didn't try to improve on that part.

> I don't think we are still supporting gcc-2.8...

That volatile hack? I just copied it from __gmp_extract_double. Probably
it's no longer needed.

> From a performance POV, it may not be optimal to split the
> sign/infinity/nan/zero test from the rest, but I agree it makes the
> interface simpler.

I'm not sure what's the right thing for mpn_set_d to do with such
inputs. It seemed simplest to disallow them, and then we need no special
error return, and we can produce a normalized output in all cases.

It's a bit strange to disallow zero, though. One alternative might be to
allow zero, and specify that rp[MPN_SET_D_SIZE-1] == 0 iff the input is
zero.

>> +   ASSERT (d != 0.5*d);	/* Exclude infinities */
>
> That excludes more than infinities, it might also exclude
> FLT_TRUE_MIN, no?

I would have expected that FLT_TRUE_MIN * 0.5 == 0.0. And then it's not
excluded by that assert. But I'm not familiar with those fine floating
point details.

Regards,
/Niels

-- 
Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26.
Internet email is subject to wholesale government surveillance.