On Thursday 27 August 2009 09:18:04 Juanjo wrote: > On Aug 27, 4:06 am, Nils Bruin <nbr...@sfu.ca> wrote: > > mpz_init(&c) > > mpz_add(&c,&a,&b) > > d=ecl_alloc( (c->_mp_size )*sizeof(limb)) > > memcpy(d,c->_mp_alloc,c->_mp_size * sizeof(limb)) > > r=ecl_alloc(sizeof(mpz_t)) > > r->_mp_size = c->_mp_size > > r->_mp_d = d > > r->_mp_alloc = c ->_mp_size > > mpz_clear(&c) > > now we have our result r and all memory that GMP allocated has been > > released again, > > as long as we have the guarantee that GMP won't do a realloc on either > > a or b. If GMP won't guarantee even that, then we basically have to > > copy the operands into temps as well. > > Exactly. The point, which I did not make clear enough, is not that we > know the size of the output, but that we DO HAVE the output. > > All intermediate and final computations are always stored in integers > that are allocated by whatever routine GMP is using for allocation. > ECL will not clobber that. Instead, the output will be just saved -- > more or less as Nils showed, but in a much simpler way -- using our > own allocation routines. mp_set_memory_functions() will never be > called by ECL. > > The only thing we need is a guarantee that mpz_add and similar > routines will not reallocate A and B -- I would say it must not > (otherwise what is the point of a three argument mpz_add), but it does > not hurt asking at the MPIR / GMP mailing lists. >
In case I not been entirely clear we do not reallocate the sources as they are declared const pointers. > I am right now on holidays, but I will try to introduce the > appropriate fixes in ECL during the coming days. > --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
