[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Axiom-developer] [#83 Bug 5977 1::DMP([x], FRAC INT)::POLY FRAC INT =
From: |
Tim Daly |
Subject: |
[Axiom-developer] [#83 Bug 5977 1::DMP([x], FRAC INT)::POLY FRAC INT ==> 0] (new) |
Date: |
Thu, 27 Jan 2005 23:52:18 -0600 |
William Sit <address@hidden> 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.
--
forwarded from http://page.axiom-developer.org/zope/mathaction/address@hidden
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- [Axiom-developer] [#83 Bug 5977 1::DMP([x], FRAC INT)::POLY FRAC INT ==> 0] (new),
Tim Daly <=