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 -- 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.
