Juan Jose Garcia-Ripoll <juanjose.garciarip...@googlemail.com> writes:
| On Fri, Aug 13, 2010 at 11:35 AM, Gabriel Dos Reis <g...@cs.tamu.edu> wrote:
|
| So, I am wondering why ECL is making that distinction? That is, why does
| ECL need to distinguish 'long' from ECL_FIXNUM_TYPE? Should not
| the distinction between GMP_LIMB_BITS vs. FIXNUM_BITS be sufficient?
|
|
| Gabriel, I think you have found a major problem. GMP only exports routines to
| convert from gmp to long and int, not to long long. Since I did not want to
| tinker with GMP's internals, I almost never manipulated limbs myself. I have
| not the faintest idea of what choices GMP takes when facing an LLP platform. I
| believe the Sage group switched from GMP to MPIR for this precise reason, but
| it also poses a significant problem for ECL because we will have to have a
look
| at the cl_fixnum -> gmp conversions scattered throughout the code, which
| currently rely on GMP's mpz_set_si function and this is taking LONG not LONG
| LONG!!!
Aha! Thanks for the explanation.
I would not think that it would be good for ECL to swicth from GMP to
MPIR (not that I think bad of MPIR, but only because GMP remains quite
popular on almost all platforms and is still actively maintained.)
As for the conversion problem.
1. GMP does use 'long long' for mp_limb_t where it is available.
So, ECL could check at configure time whether ECL_FIXNUM_TYPE
matches mp_limb_t in size.
2. GMP offers low-level mpn_xxx functions that could be used to
initialize mpz objects from fixnum values. That would avoid
the unstructured code you are alluding to. Is that something
you would contemplate?
-- Gaby
------------------------------------------------------------------------------
This SF.net email is sponsored by
Make an app they can't live without
Enter the BlackBerry Developer Challenge
http://p.sf.net/sfu/RIM-dev2dev
_______________________________________________
Ecls-list mailing list
Ecls-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ecls-list
