[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Axiom-developer] code release: Bug#5977
From: |
martin . rubey |
Subject: |
Re: [Axiom-developer] code release: Bug#5977 |
Date: |
Thu, 30 Dec 2004 14:42:05 +0100 |
Dear William, dear Tim,
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.
Martin
- [Axiom-developer] RE: axiom--windows--1--patch-8/src/input, (continued)
- [Axiom-developer] RE: axiom--windows--1--patch-8/src/input, Bill Page, 2004/12/28
- [Axiom-developer] Re: axiom--windows--1--patch-8/src/input, root, 2004/12/28
- [Axiom-developer] RE: Savannah patches, Bill Page, 2004/12/29
- [Axiom-developer] Re: Savannah patches, root, 2004/12/29
- [Axiom-developer] RE: Savannah patches, Bill Page, 2004/12/29
- [Axiom-developer] Re: Savannah patches, root, 2004/12/29
- [Axiom-developer] Re: Savannah patches, Martin Rubey, 2004/12/28
- [Axiom-developer] RE: Savannah patches, Bill Page, 2004/12/29
- [Axiom-developer] RE: Savannah patches, martin . rubey, 2004/12/30
- Re: [Axiom-developer] code release: Bug#5977, William Sit, 2004/12/28
- Re: [Axiom-developer] code release: Bug#5977,
martin . rubey <=
- Re: [Axiom-developer] code release, C Y, 2004/12/27