On Mon, Feb 7, 2011 at 1:03 AM, Cactus <rieman...@gmail.com> wrote: > > > On Feb 7, 7:23 am, Case Vanhorsen <cas...@gmail.com> wrote: >> On Fri, Feb 4, 2011 at 7:50 AM, Cactus <rieman...@gmail.com> 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. > > Thank you for this feedback Case. > > To have a complete parallel API for long long types would involve a > lot of new functions because it is not only the set/get functions that > are involved. > > Are you suggesting that we should just add set/get functions or a > complete parallel long long API? A complete parallel long long API. I was just just mpfr_set_ as an example. > > In MPIR (not GMP) mp_bitcnt_t is defined as: > > #ifdef _WIN64 > typedef unsigned long long int mp_bitcnt_t; > #else > typedef unsigned long int mp_bitcnt_t; > #endif > > so it follows the size of limbs. I missed that. The documentation for mpz_popcount should be changed since it refers to ULONG_MAX. > > Brian > > > -- > You received this message because you are subscribed to the Google Groups > "mpir-devel" group. > To post to this group, send email to mpir-devel@googlegroups.com. > To unsubscribe from this group, send email to > mpir-devel+unsubscr...@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/mpir-devel?hl=en. > >
-- You received this message because you are subscribed to the Google Groups "mpir-devel" group. To post to this group, send email to mpir-devel@googlegroups.com. To unsubscribe from this group, send email to mpir-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/mpir-devel?hl=en.
