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