Karim BELABAS on Fri, 7 Jun 2002 18:02:57 +0200 (MEST)


[Date Prev] [Date Next] [Thread Prev] [Thread Next] [Date Index] [Thread Index]

Re: RESTORE_AVMA(oldvalue)


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. It should never be placed in the pari stack, or directly
operated upon by pari functions. 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. 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.

It may be a good thing to encapsulate direct stack access like av = avma /
avma = av pairs [ do not have a clear opinion about this yet, it's certainly
better from general principles, buf how useful in practice ? ].

It may also be a good thing to have refcounts for GP variables (for "clones"
in fact) since it would kill weird bugs like

  v = [0,0]; v + [v=0,v=0] --> SEGV

[ I don't see the point of it for a standard GEN on the stack. ]

Cheers,

    Karim.

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.

-- 
Karim Belabas                    Tel: (+33) (0)1 69 15 57 48
Dép. de Mathematiques, Bat. 425  Fax: (+33) (0)1 69 15 60 19
Université Paris-Sud             Email: Karim.Belabas@math.u-psud.fr
F-91405 Orsay (France)           http://www.math.u-psud.fr/~belabas
--
PARI/GP Home Page: http://www.parigp-home.de/