Re: variable losing its value in 2.0.10

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

[Igor:]
> ? a=nextprime(2^129)
> 680564733841876926926749214863536422929
> ? a=nextprime(a+1);factorint(a*nextprime(a+1))
> ^C  ***   user interrupt after 1,053 ms.
>  
> ? a
> a
> 
> What happened to the value of a???

It's lost and it's a feature. A variable's value can be altered in 3
different way (there are some other marginal cases which don't matter here):

1) assignment (a=..., a++, etc.) and the former value is lost, unless it's
the initial value (monomial of degree 1).

2) it can be pushed down/poped out a stack when the frame changes. Ex:
  f(x)=...
  for(i=1,...)
x and i are preserved and their old values are restored when returning from
the function/loop.

3) When recovering from an error (user interrupt is an error). All stacks
arising from case 2 above are inspected and values that were pushed down
since the last input command (from the GP prompt) are poped out. 
[Technical note: This is analogous to case 2 above except that arrays/matrices
which haven't been changed as a whole (some components may have been) aren't
restored (n fact, this is a memory leak which I don't know how to fix
reliably, without a huge performance hit).]

Here the `a' stack is as follows (oldest values to the left)

i)    a <-- nextprime(2^129)                  (case 1, initial value)
ii)   a <-- nextprime(nextprime(2^129) + 1)   (case 1)
iii)  a                                       (case 3)

If you had written the code above as follows:

? f(a)= a=nextprime(a+1);factorint(a*nextprime(a+1))
? a=nextprime(2^129);
? f(a)

the value of a would have been restored.

  Hope it helps,

      Karim.

P.S: It would be easy to keep a stack of all values, regardless of the scope,
but that would be a memory hog and slow down all scripts for marginal
gain in interactive use.

A better solution, and relatively easy to implement at a slight performance
cost, would be to check how old the former value is before each assignment.
We'd save it somewhere if it was created before the current run, in case an
error would be raised later on. I'm not sure it's worth it, though...
--
Karim Belabas                    email: Karim.Belabas@math.u-psud.fr
Dep. de Mathematiques, Bat. 425
Universite Paris-Sud             Tel: (00 33) 1 69 15 57 48
F-91405 Orsay (France)           Fax: (00 33) 1 69 15 60 19
--
PARI/GP Home Page: http://pari.home.ml.org