On Jan 8, 5:19 pm, Cactus <[email protected]> wrote:
> The change to mp_size_t and mp_exp_t on WIndows to use a 64-bit long
> long type seems to be incompatible with MPFR.
>
> After accounting for the addition of a __GMP_MP_SIZE_T_INT value of 2,
> the following MPFR assertion fails:
>
> ..\..\init2.c:42: MPFR assertion failed:
> ((mp_exp_t)((~((~(unsigned int)0)>>1))+2)) == (((-2147483647L -
> 1))+2)
>
> This is the the following macro:
>
> /* Check for correct EXP NAN, ZERO & INF in both mpfr.h and in mpfr-
> impl.h */
> MPFR_ASSERTN( __MPFR_EXP_NAN == MPFR_EXP_NAN );
>
> which can be tracked to:
>
> #if __GMP_MP_SIZE_T_INT
> #define __MPFR_EXP_NAN ((mp_exp_t)((~((~(unsigned int)0)>>1))+2))
> #else
> #define __MPFR_EXP_NAN ((mp_exp_t)((~((~(unsigned long)0)>>1))+2))
> #endif
>
> and:
>
> # define MPFR_EXP_NAN (MPFR_EXP_MIN+2)
>
> I haven't much of a clue what is going on but we don't want a release
> that doesn't support MPFR.
Unfortunately MPFR depends on mp_size_t, mp_exp_t and
__GMP_MP_SIZE_T_INT in quite a few palces so MPFR is not going to work
with MPIR unless we either revert to a 32-bit type for these types or
the MPFR team makes changes to accomodate our changes to MPIR in thsi
regard.
So we have to decide what to do:
1) revert to 32-bit types and give up huge integer values
2) request changes to MPFR to accomadate our needed MPIR changes.
ANy view on whiich way to go?
Brian
--
You received this message because you are subscribed to the Google Groups
"mpir-devel" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/mpir-devel?hl=en.
