Edit detail for #83 Bug 5977 1::DMP([x],FRAC INT)::POLY FRAC INT ==> 0 revision 2 of 13

William Sit <address@bogus.example.com> wrote:

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

Sorry, my mistake. coerce$POLY checks itself whether there is a variable or 
not...

> Which coerce$POLY is that?

the coerce operation in the POLY domain.

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

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

I'm pretty sure that the coercion to from DMP to POLY fails, without signalling 
an error, just like you could always do a "pretend". This would also explain 
(66)

Note that it is not possible to coerce a DMP or a UP or anything the like to a 
POLY in compiled code! Unfortunately I don't know where these interpreter 
coercions are coded. In any case, I'm convinced that they *should* be coded in 
the Algebra, not in the interpreter. 

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

Note that coerce$POLY only coerces to OutputForm... No internal stuff done 
there. That's why I'm sure that it is an interpreter bug.



------------------------------------------------------------


the original complaint --Tim Daly, Tue, 15 Feb 2005 20:39:05 -0600

(1) -> a:=1::DMP(['x],INT)

   (1)  1
               Type: DistributedMultivariatePolynomial([x],Integer)
(2) -> a::POLY INT

   >> System error:
   Caught fatal error [memory may be damaged]

protected-symbol-warn called with (NIL)
(2) -> variables(a)

   (2)  []
                                           Type: List OrderedVariableList [x]
(3) -> a::INT::POLY INT

   (3)  1
                                Type: Polynomial Integer

(4) -> 1::DMP([x],INT)::POLY INT


   >> System error:
   Caught fatal error [memory may be damaged]

protected-symbol-warn called with (NIL)

(5) -> 1::DMP([x],INT)::DMP([y],INT)

   (5)  1
               Type: DistributedMultivariatePolynomial([y],Integer)

and 

1::POLY INT :: DMP([x],INT) 
x::DMP([x],INT)::POLY INT
1::DMP([x,y],INT)::POLY INT 
1::EXPR INT:: POLY INT 
1::UP(x,INT)::POLY INT
 
and (surprise!) even
 
1::DMP([x],INT)::POLY FRAC INT

all worked!


This bug also exists in the NAG version, where the first (2) would give "Memory
access violation detected".  Two observations: (a) the coercion in (2), shows
the interpreter does not follow the two steps in (3); and (b) the problem is
specific to POLY INT. It may also have to do with the second (2), and my
suspicion is that it has to do with a combination of the interpreter, POLY, DMP,
INT, no variables, and may be POLYLIFT or MLIFT.

Tim: can you do a boot trace of (4) and compare that with any of the others that
work?



fixed in FriCAS --kratt6, Thu, 20 Dec 2007 01:45:47 -0800

Status: open => fix proposed