William Sit 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. > 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] > > > > protectedsymbolwarn 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 the original complaint Tim Daly, Tue, 15 Feb 2005 20:39:05 0600 reply Problem:
(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] protectedsymbolwarn 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] protectedsymbolwarn called with (NIL) (5) > 1::DMP([x],INT)::DMP([y],INT) <a href="#eq5">(5)</a> 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? Status: open => fix proposed Status: fix proposed => fixed somewhereno patch available fricas a:=1::DMP(['x],
Type: DistributedMultivariatePolynomial?([x],
fricas a::POLY INT
Type: Polynomial(Integer)
fricas variables(a)
Type: List(OrderedVariableList?([x]))
fricas 1::DMP([x],
Type: Polynomial(Integer)
fricas 1::DMP([x],
Type: DistributedMultivariatePolynomial?([y],
fricas 1::POLY INT :: DMP([x],
Type: DistributedMultivariatePolynomial?([x],
fricas x::DMP([x],
Type: Polynomial(Integer)
fricas 1::DMP([x,
Type: Polynomial(Integer)
fricas 1::EXPR INT:: POLY INT
Type: Polynomial(Integer)
fricas 1::UP(x,
Type: Polynomial(Integer)
fricas 1::DMP([x],
Type: Polynomial(Fraction(Integer))
Status: fixed somewhere => open
Not really fixed. sorry. http://axiom.svn.sourceforge.net/viewvc/axiom/branches/whsandbox/src/interp/icoerfn.boot.pamphlet?r1=263&r2=636&view=patch Status: open => fixed somewhere
Status: fixed somewhere => closed
