Re: test if an unsigned long fits in a limb.
Torbjorn Granlund t...@gmplib.org writes: ni...@lysator.liu.se (Niels Möller) writes: One can have alternative functions accepting mp_limb_t and mp_limb_signed_t, if one finds that useful. That would be nice, and so would functions accepting long long. But unfortunatly, neither is possible if we want one GMP interface per release, since some compilers do not support these types (but could well compile user code which links beautifully to GMP). I'm not following you. Surely, on all platforms supported by GMP, mp_limb_t is a type supported by the compiler? As for functions taking arguments of type long long, that support would have to depend on a configure check for long long, and exclude that interface if long long is not present. I don't think that should be a big deal; If a program used that feature it will fail to work on systems without long long, but the reason for the failure is not primarily that the functions were excluded in the GMP build, but that the program uses a type not supported by the compiler. Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance. ___ gmp-devel mailing list gmp-devel@gmplib.org http://gmplib.org/mailman/listinfo/gmp-devel
Re: test if an unsigned long fits in a limb.
Marc Glisse marc.gli...@inria.fr writes: Imagine that mpz_set_si takes as argument a long long on win64. I can still pass it a long with no problem. Imagine that mpz_get_si outputs a long long. I can still store it safely in a long, because I first called mpz_fits_slong_p to check that it would fit. It doesn't look like I have lost anything. I see. That could work, even if I'm still not convinced it's a good idea to have the type used depend on the GMP configuration. If the intention is to get an integer of size matching a the native word size, no matter which C type that may be, I think using mp_limb_t and mp_limb_signed_t (but without nail bits) should be goood enough. Functions using long long would provide additional functionality on platforms where long long is larger than mp_limb_t (presumably because long long is larger than the native word size). But I think those should be additional functions, since they will give a larger overhead if you really just want a long (which fits in a native word on sane platforms). We can add an awful lot of functions here, so I imagine we need to think a bit on which function really are needed. If I understand you correctly, the most urgent problem is to be able to convert between mpz_t and native (64-bit) integers on W64. Is there any other supported platform that has chosen an ABI where Long is smaller than the native word size? Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance. ___ gmp-devel mailing list gmp-devel@gmplib.org http://gmplib.org/mailman/listinfo/gmp-devel
Re: test if an unsigned long fits in a limb.
On Wed, 7 Mar 2012, Niels Möller wrote: Marc Glisse marc.gli...@inria.fr writes: Imagine that mpz_set_si takes as argument a long long on win64. I can still pass it a long with no problem. Imagine that mpz_get_si outputs a long long. I can still store it safely in a long, because I first called mpz_fits_slong_p to check that it would fit. It doesn't look like I have lost anything. I see. That could work, even if I'm still not convinced it's a good idea to have the type used depend on the GMP configuration. If the intention is to get an integer of size matching a the native word size, no matter which C type that may be, I think using mp_limb_t and mp_limb_signed_t (but without nail bits) should be goood enough. Possibly. I repeated some arguments, but I don't know the answer either. Functions using long long would provide additional functionality on platforms where long long is larger than mp_limb_t (presumably because long long is larger than the native word size). But I think those should be additional functions, since they will give a larger overhead if you really just want a long (which fits in a native word on sane platforms). We can add an awful lot of functions here, so I imagine we need to think a bit on which function really are needed. If I understand you correctly, the most urgent problem is to be able to convert between mpz_t and native (64-bit) integers on W64. Is there any other supported platform that has chosen an ABI where Long is smaller than the native word size? I would assume that this mostly corresponds to the 'longlong' configurations, which according to configure.in include quite a few 64bit platforms that provide a 32bit ABI. -- Marc Glisse ___ gmp-devel mailing list gmp-devel@gmplib.org http://gmplib.org/mailman/listinfo/gmp-devel
Re: test if an unsigned long fits in a limb.
bodr...@mail.dm.unipi.it writes: The first one is the one I prefer. Has this problem been addressed in the alimb branch? We generalised this and separated long and size arithmetic from limb arithmetic. More work is needed on the alimb code, and help is most welcome. I think Per Olofsson posted a url to his mercurial repo some time ago. I hope we can have alimbs integrated in the mainline repo before the 5.1 release. -- Torbjörn ___ gmp-devel mailing list gmp-devel@gmplib.org http://gmplib.org/mailman/listinfo/gmp-devel
Re: test if an unsigned long fits in a limb.
ni...@lysator.liu.se (Niels Möller) writes: One can have alternative functions accepting mp_limb_t and mp_limb_signed_t, if one finds that useful. That would be nice, and so would functions accepting long long. But unfortunatly, neither is possible if we want one GMP interface per release, since some compilers do not support these types (but could well compile user code which links beautifully to GMP). -- Torbjörn ___ gmp-devel mailing list gmp-devel@gmplib.org http://gmplib.org/mailman/listinfo/gmp-devel
Re: test if an unsigned long fits in a limb.
On Tue, 6 Mar 2012, Niels Möller wrote: Marc Glisse marc.gli...@inria.fr writes: Note that mpir is replacing signed/unsigned long by two typedefs that can be defined as (unsigned) long long on _LONG_LONG_LIMB platforms. That works around the problem too... (actually they don't seem to have released that yet, they are just experimenting) But the point of the _ui and _si functions, as I understand them, is to make it safe and easy to pass values between code using GMP and code which is unaware of GMP types. One can have alternative functions accepting mp_limb_t and mp_limb_signed_t, if one finds that useful. But for the above reason, advertising such functions as a substitute for the _ui and _si functions seems to totally miss the point. Their main goal is to be able to interact with 64 bit integers on win64. Imagine that mpz_set_si takes as argument a long long on win64. I can still pass it a long with no problem. Imagine that mpz_get_si outputs a long long. I can still store it safely in a long, because I first called mpz_fits_slong_p to check that it would fit. It doesn't look like I have lost anything. -- Marc Glisse ___ gmp-devel mailing list gmp-devel@gmplib.org http://gmplib.org/mailman/listinfo/gmp-devel
