On Wed, Mar 9, 2011 at 8:53 AM, Cactus <rieman...@gmail.com> wrote: > > > On Mar 8, 8:21 pm, Cactus <rieman...@gmail.com> wrote: >> On Feb 14, 10:18 am, Jason <ja...@njkfrudils.plus.com> wrote: >> >> >> >> >> >> > On Sunday 13 February 2011 16:43:47 Cactus wrote: >> >> > > [cut previous text] >> >> > > > > Probably the easiest solution on Windows is to simply to express the >> > > > > integer parameters of ui/si functions (and some internal integers in >> > > > > the functions themselves) as a new global integer type that is >> > > > > (unsigned) long on 32-bit Windows systems and (unsigned) long long on >> > > > > 64-bit Windows. >> >> > > > > Brian >> >> > > > I think changing the signature of ui/si functions will cause problems. >> > > > You should assume that code using MPIR will be written using long or >> > > > long long. Forcing that code to use a new type will cause issues, too. >> > > > Python has specific API calls for working with long vs long long. I'd >> > > > like to be able to map the output of those API calls directly to the >> > > > appropriate function. A parallel ull/sll API would be the easiest for >> > > > use with gmpy. A parallel uj/sj would work also and matches the API in >> > > > MPFR (both ui/si and uj/sj functions are supported). >> >> > > > I think the high-level API should be be expressed in terms of standard >> > > > C types. Just having the alternate API defined, either ull/sll and/or >> > > > uj/sj, should make it easier for software authors to make the proper >> > > > choice. Since the only interface functions are defined use long, it's >> > > > not surprising that all code uses long. To avoid possible name >> > > > collisions with GMP, you could prefix these functions with mpir_. >> >> > > Looking at all the input we have had it would seem that, if we are >> > > going to do anything here, the addition of uj/sj functions (using >> > > uintmax_t and intmax_t) paralleling the ui/si ones has the most >> > > support. >> >> > > One of my main worries was that the obvious way of doing this with the >> > > 'C templates' I described earlier might mess up *nix builds. >> >> > Can't see any problem with it , there are already some mpn functions like >> > this >> > , however it does conflict with our "one function=one file" , but we could >> > always do it at a pre-build stage or even manually like we do for mpn >> > generic >> > logic functions >> >> > > But nobody seems concerned about this so can I assume that my worries >> > > are ill founded? >> >> > > Brian >> >> Now that MPIR 2.3.0 is out, I am looking at the issue of 32bit longs >> on Windows. >> >> From our earlier discussions I think the favoured option is to add >> functions that interface with intmax_t and uintmax_t types and it >> seeems logical to start with mpz_<set|get>_<u|s>intmax_t() functions >> (suitably named). >> >> But in looking at this I am wondering whether or not we are supporting >> nails in MPIR as this makes a difference in how these new functions >> are implemented.. >> >> Brian > > Unless anyone objects, I am now working on the addition of the > following four functions to MPIR: > > uintmax_t mpz_get_ux (mpz_srcptr z) - return a uintmax_t integer = > low_bits(z) > intmax_t mpz_get_sx (mpz_srcptr z) -- return an intmax_t integer = > sign(z) * low_bits(z) > void mpz_set_ux (mpz_ptr z, uintmax_t v) -- set z to the uintmax_t > value v > void mpz_set_sx (mpz_ptr z, intmax_t v) -- set z to the intmax_t > value v > > If desirable, I can avoid any impact on Linux by putting these > declarations within mpir.h in a win32 guarded section. > > Should I do this or allow these new functions on Linux? > > I chose the ux/sx suffix as the 'x' associates these functions with > the 'x' in the (u)intmax_t types.
I believe MPFR uses 'j' as a suffix for intmax/uintmax support. > > 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.
