Re: Missing API in PARI? (fwd)

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

Forwarded message:
> [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).

You mean that there was a way to put a vector into a variable so that
it the components do not occupy consequent chunks of memory?  Or is

  (blah(foo))[73] = bar

allowed?

> 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.

Leaving the technobabble (which I cannot follow) aside, is it true
that the default way to assign to arrays element-wise takes O(n^2) now?

Ilya