Re: RESTORE_AVMA(oldvalue)

[Ilya Zakharevich <ilya@math.ohio-state.edu>]

On Fri, Jun 07, 2002 at 06:02:57PM +0200, Karim BELABAS wrote:
> On Wed, 15 May 2002, Ilya Zakharevich wrote:
> > As far as I understand, the only problem with interfacing PARI with
> > other math-related libraries (e.g., to allow Groebner bases supported)
> > is an absense of the type t_EXTERNAL_DATA.  The minimal support for
> > this type in the PARI core should be: cloning/uncloning,
> > create/destroy and a couple of others; these operations should go
> > through the dispatch table (the pointer to this table should be a part
> > of the data structure associated to this type).
> >
> > However, the major obstacle for this to be done is the absense of
> > refcounts for PARI objects: whatever is on stack at the time of
> > "restoring the stack position" is just ignored (if it is not
> > gerepile()d).  This could lead to severe memory leaks.
> 
> I disagree. If we import some object from some library, then it's the other
> library's business to allocate the object, and give us the ways of handling,
> then destroying it.

Absolutely.

> It should never be placed in the pari stack, or directly
> operated upon by pari functions.

But the PARI *wrapper object* for this object must be able to be
placed on the stack, and some functions should be able to operate on
it as well (via the dispatch table of the wrapper; in the worst cases
by just converting them to the most suitable PARI object).

> Of course one can write wrappers to let
> pari operate on the object nethertheless, but if we eventually copy it to
> stack, then we make it a genuine pari GEN first.

This is either impossible (e.g., for objects which are not
*reversively* convertable to PARI objects), or very wasteful (for
objects which would be endlessly converted back and forth).

> And in any case one would have to make sure the wrappers import then
> destroy the object, we don't want it to interfere with pari regular
> "gerepile" business.

Why not?  The price of modifying gerepile is negligible - in the
(current) case of no "imported objects" it is just one check
list_imported == NULL and a jump.

> P.S: also, Groebner bases are computationaly expensive, so one can certainly
> afford to exchange data as character strings, without bothering about
> respective internal data structure.

To the contrary: AFAIU the F4 benchmarks, groebner bases calculations
are more or less linear with respect to "input + output" size.

Ilya