Re: [Axiom-developer] code release: Bug#5977

[William Sit]

Martin wrote:

Thanks for investigating further.
 
> it might be that there is an error in mainVariable$SMP, but more likely, the
> bug is earlier in the history. mainVariable$SMP is called from coerce$POLY,
> interestingly without checking that the result of mainVariable might be
> "failed".

Shouldn't that mean coerce$POLY should be fixed to check the "failed" case?
Which coerce$POLY is that?

> (66) -> 1::DMP([x],FRAC INT)::POLY FRAC INT
> 
>    coerce$POLY
>    mainVariable1$SMP
>    mainVariable3$SMP
>    mainVariable4$SMP
>  LISP output:
> 1
>    coerce4$POLY
>    1
>    coerce5$POLY
>    coerce6$POLY
>    (66)  0
>                           Type: Polynomial Fraction Integer

Very interesting.
Of course, this is another (perhaps related, but perhaps not) bug that seems to
point to coerce$POLY. Another surprise (in the sense of tracing the bug):

1::DMP([x], FRAC INT)::POLY INT

returns 1 (correctly).

By (66), FRAC is involved in the bug as well.

> Is there a way to find out what exactly the variable p in mainVariable
> contains?
> 
use p$Rep  ? or trace boot.

Now p is declared in multpoly.spad as Union(R, VPoly).
So the code mainVariable p seems to be correct, but your debug info

> (65) -> 1::DMP([x],INT)::POLY INT
> 
>    coerce$POLY
>    mainVariable1$SMP
>    mainVariable3$SMP
>    mainVariable4$SMP
> 
>    >> System error:
>    Caught fatal error [memory may be damaged]
> 
> protected-symbol-warn called with (NIL)

suggests that when 1$DMP([x], INT) is passed on to coerce$(POLY INT) and then to
mainVariable$SMP as p, it is recognized as "case VPoly". So that must be where
the bug is, in coerce$(POLY INT).
I think p is correctly passed, based on:

> (67) ->  1::DMP([x],INT)::POLY FRAC INT
>    Loading /home/rubey/axiom/mnt/linux/algebra/POLY2.o for package
>       PolynomialFunctions2
>    Loading /home/rubey/axiom/mnt/linux/algebra/INDE.o for domain
>       IndexedExponents
>    mainVariable1$SMP
>    mainVariable3$SMP
>    mainVariable4$SMP
>  LISP output:
> x
>    mainVariable1$SMP
>    mainVariable2$SMP
>    1
> 
>    coerce$POLY
>    (67)  1

where mainVariable2$SMP is printed, and that coerce$(POLY FRAC INT) then handles
the case correctly.

The puzzle is that coerce$POLY is defined independent of R, but yet R affects
the correctness of the output. I would be surprised if 1$DMP([x],INT) is passed
correctly in one case but not the other because of the target POLY has different
parametric domains. It that were the case, the culpit would be the interpreter.
Unfortunately, I think trying testing this same bug in the compiler would not
work because these coercion statements are not specific enough for the compiler,
but it may be worth trying because of (66).

Martin, can you also post the debug code inserts for coerce$POLY?

William