Bitwise logic gmpxx.h problems

Marc Glisse marc.glisse at normalesup.org
Tue Jul 29 13:48:05 CEST 2008


On Tue, 29 Jul 2008, Torbjorn Granlund wrote:

> Marc Glisse <marc.glisse at normalesup.org> writes:
>
>  __gmp_expr<T, T> temp(expr.val);
>  Op::eval(p, temp.__get_mp());
>
>  I believe it could be safely replaced by:
>
>  expr.val.eval(p);
>  Op::eval(p,p);
>
> This is greek to me, but if you say the latter is better, I believe
> you.  :-)

The goal of the function is to do something like p=-expr. The current 
version evaluates expr and puts the result in temp. It then does p=-temp. 
The one I suggested evaluates expr and puts the result in p. It then does 
p=-p. It basically saves a copy from temp to p in some cases.

>  It would also be interesting to make statistics about how often a typical
>  gmpxx program calls mpz_set(x,y) with x==y.
>
> That's bad, and should really be avoided.

There may be more with mpq than mpz, and I see it is already mentionned in 
the tasks.

>  I was surprised to see that the allocation policy choice in gmp is at the
>  level of the malloc/realloc/free functions. This means that if for
>  instance I want a policy like "never allocate less than two limbs" for
>  mpz_t, the best I can do is apparently to have the malloc replacement
>  allocate more than asked and the realloc replacement do nothing if the new
>  size asked is still smaller than already allocated. It would have been
>  nicer if I could have made the mpz_t aware of the size actually allocated
>  to it. Looks like one of the "bright ideas" in the tasks.
>
> The mpz->_mp_alloc field is "aware" of the allocation.  Or what do you
> mean?

_mp_alloc is aware of what allocation size is requested from malloc. If 
malloc happens to allocate more (because I replaced the standard malloc 
by my own that allocates only even numbers of limbs), _mp_alloc does not 
know it. This means that replacing malloc/realloc/free is not such a nice 
way to specify an allocation policy.


>  I would say DBL_MAX_EXP (from <float.h>) in C and
>  std::numeric_limits<double>::max_exponent (from <limits>) in C++ if I
>  understand the question.
>
> OK, I'll use the terse C++'y std::numeric_limits<double>::max_exponent.

I am not sure it is as portable as DBL_MAX_EXP from <cfloat>, but we'll 
see. It's easy to switch anyway if one causes trouble.

-- 
Marc Glisse


More information about the gmp-bugs mailing list