On Tue, 31 Jul 2012, Patrick Pelissier wrote:
Why not intmax_t / uintmax_t instead of long long / unsigned long long?
I believe every platform that has intmax_t also has long long, but the
converse is not true.
Do you have an example of such a platform?
Say, MS visual studio up to version 9
>> Why not intmax_t / uintmax_t instead of long long / unsigned long long?
> I believe every platform that has intmax_t also has long long, but the
> converse is not true.
Do you have an example of such a platform?
> Some platforms provide types larger that intmax_t (intmax_t is part of the
> AB
Replying to myself yet again...
> For the power x^n, I currently use mpn_powlo. But the least significant
> half is known from the previous iteration, so wraparound would be
> desirable. To me it would make some sense with a pow function for (mod
> (2^k - 1)), i.e., using mpn_mulmod_bnm1 and mpn_s
On 2012-07-31 09:51:00 +0200, Marc Glisse wrote:
> Some platforms provide types larger that intmax_t (intmax_t is part of the
> ABI, and they couldn't change it when they added a longer type, see for
> instance __int128 in gcc).
GCC could have added an option to change the ABI, as it has done for
On Tue, 31 Jul 2012, Patrick Pelissier wrote:
On Mon, Jul 30, 2012 at 10:53 PM, Niels Möller wrote:
Torbjorn Granlund writes:
We could perhaps add a parallel set of functions (_ul, or _ull) allowing
long long. We should then follow the principle of "one GMP release, one
GMP API" and reject
On Mon, Jul 30, 2012 at 10:53 PM, Niels Möller wrote:
> Torbjorn Granlund writes:
>
>> We could perhaps add a parallel set of functions (_ul, or _ull) allowing
>> long long. We should then follow the principle of "one GMP release, one
>> GMP API" and reject compilers and ABIs without long long s
