On Mar 9, 5:55 pm, Case Vanhorsen <cas...@gmail.com> wrote:
> 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
> > athttp://groups.google.com/group/mpir-devel?hl=en.
To add these new functions to mpir.h we either need (a) to include
<stdint.h> in mpir.h, or (b) guard these function declarations so that
they are only present when mpir.h has been included in a source code
file that has previously included <stdint.h>.
Does anyone have a view on how we should do this?
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.
