On Aug 26, 7:06 pm, Nils Bruin <nbr...@sfu.ca> wrote:
OK, so r and d would probably get allocated using
mpz_t *r
mp_ptr d
r = (mpz_t) ecl_alloc(sizeof(mpz_t)+(c->_mp_size )*sizeof(limb))
d = (mp_ptr) (r+1)
r->_mp_size = c->_mp_size
r->_mp_d = d
r->_mp_alloc = c ->_mp_size
Looking at the code of mpz_array_init, it seems that for GMP, *r
should pretty much look like an mpz_t
coming from an mpz_array_init. From the documentation there:
The space allocated to each integer by this function will not be
automatically increased, unlike the normal mpz_init, so an application
must ensure it is sufficient for any value stored. The following space
requirements apply to various routines,
* mpz_abs, mpz_neg, mpz_set, mpz_set_si and mpz_set_ui need room
for the value they store.
* mpz_add, mpz_add_ui, mpz_sub and mpz_sub_ui need room for the
larger of the two operands, plus an extra mp_bits_per_limb.
* mpz_mul, mpz_mul_ui and mpz_mul_ui need room for the sum of the
number of bits in their operands, but each rounded up to a multiple of
mp_bits_per_limb.
* mpz_swap can be used between two array variables, but not
between an array and a normal variable.
For other functions, or if in doubt, the suggestion is to calculate in
a regular mpz_init variable and copy the result to an array variable
with mpz_set.
So it seems that GMP makes storage guarantees after all (oddly, the
bit operations have no guarantee. My guess is that they were just
overlooked). This means we should be fine. I wonder how GMP recognizes
the difference between a variable from mpz_init and one from
mpz_array_init in order to decide whether to do a realloc.
--~--~---------~--~----~------------~-------~--~----~
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to
sage-devel-unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~----------~----~----~----~------~----~------~--~---
