Re: Missing API in PARI?

[Karim BELABAS <Karim.Belabas@math.u-psud.fr>]

[Ilya:]
>> > Note that in the above examples the calculator makes some assumptions
>> > about layout of a and aa in memory (these assumptions are valid for
>> > data created by calculator).
>> > so it may be that in order to create such an API one may need to
>> > introduce an additional flag and mark GENs which are created in
>> > consequent chunks as such...

[me:]
>> (in fact this is exactly what I've done in 2.0: CLONEBIT is set to denote
>> an object cloned out of the stack. Thus you can change an entry in a
>> complicated structure without copying the whole thing as used to be the
>> case)

[Ilya:]
> No, this is not what I had in mind.  (At least in 1.36 or around)
> calculator knows that aa[2,4] is placed after aa[2,3], so one can find
> the allocation size of aa[2,3] by subtracting addresses of aa[2,4] and
> aa[2,3].  If the size of aa[2,3] is big enough (bigger than size
> needed to store 4 in the above example ;-), the calculator will write
> GEN(4) in the chunk of memory occupied by aa[2,3] - without reallocing
> aa.

Not anymore. This was cancelled a long time ago (around 1.38) since it led to
a HUGE number of fatal errors (SIGBUS mostly) in perfectly valid (and
previously working) scripts. Basically, it only worked under some additional
conditions on the _values_ themselves (non-recursive ones were always ok).
The whole mechanism could be toggled back and forth for a time by a
metacommand (\[ = "compact arrays"), and was disabled by default.

I removed the whole thing in 2.0 (in fact 1.905, but few people have actually
used these pre-alpha releases...). Now GP does not assume anything except
that he expects all components to be either part of the stack (no CLONEBIT)
or clones (with the CLONEBIT set). Whenever a component is changed, its
previous value is freed (recursively, it may be a complicated array itself)
if it was a clone, and we then insert a clone of the new value to replace it.
So far, this has proven reliable, and the loss of efficiency due to data
fragmentation is negligible.

The only problem is that for the sake of efficiency, there can be memory
leaks: when you replace a component which is a stack object, whose components
are clones. It would be easy to remove that as well (just explore all
components, regardless of the CLONEBIT, freeing everything that should be
freed), but this would hit heavily matrix manipulations. Since in practice it
does not happen often, I've left it alone so far.

Karim.
--
Karim Belabas                     e-mail: belabas@math.u-psud.fr
Universite Paris Sud              tel: (00 33) 01 69 15 57 48
Dep. de Mathematiques (bat. 425)
F-91405 Orsay