Re: weird error in thueinit

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

* Karim Belabas [2013-06-03 14:15]:
> * Max Alekseyev [2013-06-03 13:49]:
> > On Mon, Jun 3, 2013 at 7:17 AM, Bill Allombert
> > <Bill.Allombert@math.u-bordeaux1.fr> wrote:
> > 
> > > I suggest you add
> > > y;
> > > as the first line of your script.
> > 
> > Wow. It seemed to help.
> > How this magic works?
> 
> This is a bug. When the main variable is "x", the nfroots() call
> requires a new variable, which is selected to be "y" for debugging
> purposes ( it's easier to read y^2 + 2 than <#123879>^2 + 2 when you run
> into a later error or under a debugger... )
> 
> For some reason, the "y" variable already exists in your session
> (it springs into existence when you use the "y" name); and for some 
> reason, it was not created in the "proper" way and its content is
> invalid at the time nfroots() tries to access it. Then we are dead.
> 
> I'm trying to understand how we reach this inconsistent state . :-)

OK, I understand now: 

1) select(y->...,...) creates the 'y' identifier
without binding a proper initial value to it (e.g. a degree 1 monomial).

[ This is a minor optimization in order to avoid that too many polynomial
variables spring into existence, later posing problems related to variable
priorities: once a variable is defined, there's no simple way to change its
priority. ]

2) Then local(y) assigns the value 0 to 'y', without ensuring that a 
proper initial value is attached to 'y'

3) Then nfgaloisconj() find that 'y' exists and trusts its initial value to
provide a sensible variable number.

Simple way to reproduce:

  select(y->0,[]);
  local(y); nfgaloisconj((x+1)^4+2);

==>

  ***   at top-level: local(y);nfgaloisconj((x+1)^4
  ***                          ^--------------------
  *** nfgaloisconj: incorrect priority in nfroots: variable x >= x


The fix will soon be committed to 'master' and 'pari-2.5'


Cheers,

    K.B.

P.S. In almost all cases, using 'local' instead of 'my' in a script is a bug.
Unless lexical scoping is explicitly *not* desired (resulting in semi-global
variables which other function calls can modify !), replacing 'local' by 'my'
is much safer and will generate simpler and more efficient bytecode.

It helps us find obscure bugs, though ! :-)

--
Karim Belabas, IMB (UMR 5251)  Tel: (+33) (0)5 40 00 26 17
Universite Bordeaux 1          Fax: (+33) (0)5 40 00 69 50
351, cours de la Liberation    http://www.math.u-bordeaux1.fr/~kbelabas/
F-33405 Talence (France)       http://pari.math.u-bordeaux1.fr/  [PARI/GP]
`