On Fri, Feb 4, 2011 at 7:50 AM, Cactus <[email protected]> wrote: > Having been caught once more by the often made, but incorrect, > assumption that the length of the 'long int' types GMP and MPIR use in > conversions match the length of limbs, I am wondering if it is time to > do something about this. > > This has recently come up several times over on the MersenneForum, > with more than one plea that we should 'do something about it' by, for > example, by using a type in these functions that is defined to be of > the same length as mp limbs. An alternative would be to introduce a > distinct type for all such uses so that GMP/MPIR users could set the > actual type used when GMP/MPIR is built.
Based on my experience with gmpy, I suggest the following: Create a parallel set of APIs (mpz_set_sii ??) that accepts a long long. On platforms with a 32-bit limb and a 64-bit long long, this API would need to set two limbs. If you want to present a single API to the user, you could define a signed version of mp_limb_t and then define mpz_set_limb as either mpz_set_si or mpz_set_sii. Python has distinct API calls for working with long vs. long long, so having access to both mpz_set_si and mpz_set_sii works well for me. I think the underlying limb type should be chosen for performance and the API should expose standard C types so I'm not in favor of specifying the limb type at compile time. Another "length of long" issue is the size of mp_bitcnt_t. It is currently set to unsigned long. I think size_t (which is already used in mpz_sizeinbase) would be more appropriate. casevh > > I would be interested in input on this issue - do we need to do > anything about it? And, if so, what should we do? > > Brian > -- You received this message because you are subscribed to the Google Groups "mpir-devel" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/mpir-devel?hl=en.
