Bill Hart wrote:
> On 24 October 2011 20:31, leif wrote:
>> Adding more _ux and _sx functions would perhaps make more sense once we
>> get long longs that are, e.g., 128 bits on a variety of platforms.
>
> That will never happen. 64 bits is enough for anyone.
I bet the same had been said about 3
On 24 October 2011 20:31, leif wrote:
> Bill Hart wrote:
>> To my knowledge there are not even mpz_add_ux, mpz_mul_ux functions,
>> etc. in the MPIR C library, let alone C++ analogues.
>
> Well, is it worth adding such?
>
> If you're using a platform which, despite its machine word width being
> 6
Bill Hart wrote:
> To my knowledge there are not even mpz_add_ux, mpz_mul_ux functions,
> etc. in the MPIR C library, let alone C++ analogues.
Well, is it worth adding such?
If you're using a platform which, despite its machine word width being
64 bits, doesn't support an LP64 programming environ
You are right - size_t is supposed to be 64-bits on Windows x64. But to get
this behaviour, you have to define _WIN64 during the build process.
I have been caught by this so many times because _WIN64 is supposed to be a
predefined macro, onr that is automatically defined for 64-bit builds.
On Oct 24, 9:02 pm, Cactus wrote:
> As you have correctly surmise, solving this requires a full rewrite of about
> 50 functions in the underlying C library, all of which are written in a way
> that will use 32-bit integer types on Windows.
Ah... that's unfortunate. Good to know before I start pat
On Oct 24, 8:30 pm, Cactus wrote:
> Following up my earlier response, size_t on Windows x64 is a 32-bit integer
> so the test program you used won't use a 64-bit integer. To obtain 64-bit
> integers you can use intmax_t and uintmax_t
Brian, I'm really surprised that size_t on Windows x64 is a 32
On 24 October 2011 19:45, Joris Mooij wrote:
> Thanks for your answers so far.
>
> Actually, adding a constructor seems to be a simple two-line patch to
> mpixx.h:
> At line 1565 of the file mpirxx.h (in release 2.4.0), insert:
> __gmp_expr(intmax_t l) { mpz_init_set_sx(mp, l); }
> __gmp_expr(
As you have correctly surmise, solving this requires a full rewrite of about
50 functions in the underlying C library, all of which are written in a way
that will use 32-bit integer types on Windows.
This is a large undertaking and, so far, nobody has been willing to embark
on this. With enoug
Thanks for your answers so far.
Actually, adding a constructor seems to be a simple two-line patch to
mpixx.h:
At line 1565 of the file mpirxx.h (in release 2.4.0), insert:
__gmp_expr(intmax_t l) { mpz_init_set_sx(mp, l); }
__gmp_expr(uintmax_t l) { mpz_init_set_ux(mp, l); }
I realize that
Following up my earlier response, size_t on Windows x64 is a 32-bit integer
so the test program you used won't use a 64-bit integer. To obtain 64-bit
integers you can use intmax_t and uintmax_t
I found it easy to add a 64-bit constructor to mpirxx.h (NOT gmpxx.h) and
this program then gives t
This is a well known issue that derives from a fundamental incompatibility
between the data models used by GMP (and MPIR) and Windows x64.
GMP and MPIR use the LP64 model whereas Windows x64 uses the LLP64 model -
in consequence integers and longs on Windows x64 integers are 32-bits
whereas i
Hi Joris,
It might be worth us including a 64 bit C++ constructor for mpz's on
Windows 64. At the moment the constructor basically mimics mpz_set_ui,
which explains the limitation.
Brian may be able to let us know whether it is even possible to do
this (I don't know enough C++ to say for sure).
Hi,
first of all, I would like to thank the developers of (GMP and) MPIR
for this great library. I am using it in my own open source library,
libDAI.
When using MPIR in a Win64 environment, I encountered the problem that
the C++ wrappers do not seem to handle 64-bit integers, like size_t's
(or lo
13 matches
Mail list logo
