Bill Page wrote:
>
> On 11 May 2017 at 08:16, Waldek Hebisch <[email protected]> wrote:
> > Bill Page wrote:
> >>
> >> http://axiom-wiki.newsynthesis.org/SandBoxBugGroebnerFactorize
> >>
> >> A simple example of Groebner factorization works:
> > <snip>
> >> But the following moderately complex problem fails:
> > <snip>
> >> with the message
> >>
> >> >> Error detected within library code:
> >> index out of range
> >>
> >> The error apparently originates from 'npcoef.spad' in:
> >>
> >> --
> >> check(tterm:TermC,ulist:Vector(P)) : Union(Detc,"failed") ==
> >> cfu:P := 1$P;doit:NNI := 0;poselt:NNI := 0;pp:Union(P,"failed")
> >> termlist : List(VTerm) := tterm.detfacts
> >> vterm : VTerm := empty()
> >> #termlist = 1 =>
> >> vterm := termlist.first
> >> for elterm in vterm while doit<2 repeat
> >> (cu1 := elterm.pcoef) ~= 0 => cfu := cu1*cfu
> >> doit := doit+1
> >> poselt := position(elterm, vterm)::NNI
> >> doit = 2 or (pp := tterm.coefu exquo cfu) case "failed" => "failed"
> >> [vterm.poselt.expt, pp::P, poselt]$Detc
> >> "failed"
> >> --
> >>
> >> It looks like this line:
> >>
> >> (cu1 := elterm.pcoef) ~= 0 => cfu := cu1*cfu
> >>
> >> causes premature exit from the loop and really should be:
> >>
> >> if (cu1 := elterm.pcoef) ~= 0 then cfu := cu1*cfu
> >>
> >> in order that poselt be set properly on exit from the loop.
> >
> > No. If poselt is not set, then check may simply fail.
> >
>
> ??? poselt is set to 0 by default. If this is not changed in the loop
> than vterm.poselt will produce an index error. This looks to me like
> just a simple programming error.
>
> What do you mean by "may simply fail"? check does not return "failed"
> in the case I am worried about, instead it aborts with an index error.
There is a bug somewhere. One way out is to change:
doit = 2 or (pp := tterm.coefu exquo cfu) case "failed" => "failed"
into
doit ~= 1 or (pp := tterm.coefu exquo cfu) case "failed" => "failed"
Current code apparently assumes that doit will be bigger than 0
and this assumption is violated in your example. ATM I do not
know if the change above is good one or we should do some other
fix.
> >> In any case after fixing the index problem as above, another problem
> >> arises:
> >>
> >> >> Error detected within library code:
> >> Table construction failed in MLIFT
> >>
> >> in 'mlift.spad'.
> >>
> >
> > This is affected by a few bugs in pgcd. Actually, it seem
> > that 'nontCoprime' in pgcd.spad is quite buggy.
> >
>
> Assuming that one avoids the index error above are you suggesting that
> 'nontCoprime' is the source of this error in mlift?
Yes. I have essentially disabled 'npcoef' and problems appeared in
due to 'notCoprime'. More precisely, error in MLIFT is due to
wrong data and at least one source of problems is due to 'nontCoprime'.
I also got separate error directly in 'nontCoprime' (failire in
division). I have tried version which disabled 'npcoef' and fixed a
few things in 'notCoprime' and it was running for several hours
without signaling error but I do not know if it will finish
(I am waiting what will happen).
--
Waldek Hebisch
--
You received this message because you are subscribed to the Google Groups
"FriCAS - computer algebra system" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at https://groups.google.com/group/fricas-devel.
For more options, visit https://groups.google.com/d/optout.
