Edit detail for #103 solve(z=z, z) revision 2 of 3

[Anonymous user:]

solve(z=z,z)

(1)

solve(z=z,y)

(2)

solve(0=0,z)

(3)

[Martin Rubey (kratt6) Thu Feb 17 07:35:54 -0600 2005
Subject: patch
Message-ID: <20050217073554-0600@page.axiom-developer.org>]

The mistake is in primitivePart$POLYCAT, where a check for zero (as in primitivePart!$NEWPOLY, primitivePart$SUP, primitivePart$FAMR) is missing.

The functions should read:

  @@ -580,8 +585,10 @@
           unit(s := squareFree p) * */[f.factor for f in factors s]
         content(p,v) == content univariate(p,v)
         primitivePart p ==
  +        zero? p => p
           unitNormal((p exquo content p) ::%).canonical
         primitivePart(p,v) ==
  +        zero? p => p
           unitNormal((p exquo content(p,v)) ::%).canonical
       if R has OrderedSet then
         p:% < q:% ==

[Martin Rubey (kratt6) Thu Feb 17 07:49:05 -0600 2005
Subject: another bug
Message-ID: <20050217074905-0600@page.axiom-developer.org>]

However, the result in (1) is another bug! The result should be '[0=0]?', which is not the emptyset!

[William Sit, Thu Feb 17 10:44:08 -0600 2005] 
Date: Thu, 17 Feb 2005 10:44:08 -0600

Why is (1) a bug? 0=0 is always true, the equation is equivalent to no equation, the empty set. This is a simplification of the system of equations given. The empty set implies that anything is a solution (the polynomial ideal is the zero ideal, the algebraic variety is the entire affine space).

[unknown Thu Feb 17 10:54:28 -0600 2005
Subject: change it to Axiom Library
Message-ID: <20050217105428-0600@page.axiom-developer.org>
In-Reply-To: <20050217104408-0600@page.axiom-developer.org>]

[William Sit]

Martin, thanks for pointing out the source. However, I think the error is not in primitivePart, but in exquo. There are two cases:

p:=0::POLY INT

(4)

exquo(p,content p)

   >> Error detected within library code:
   Division by 0

Description: exquo(a,b) either returns an element c such that c*b=a or "failed" if no such element can be found. The "failed" case is intended for the situation when b does not divide a exactly. So exquo(p,content p) which is exquo(0,0) returning 0 is ok, but exquo(p,content(p,v)) which is also exquo(0,0) but with a different signature, returning "failed" is wrong. This happens because the second exquo tested b first (whether it is zero) and returned "failed" causing the problem. In catdef.spad, EuclideanDomain, the second exquo is implemented as:

     x exquo y ==
       zero? y => "failed"
       ...

This should be: (patch in catdef.spad : EuclideanDomain)

     x exquo y ==
+       zero? x => 0
        zero? y => "failed"
        ...

Compare this with implementation for the first exquo in polycat.spad : FAMR

     x exquo y ==
       zero? x => 0
       ...

This should return [ ] as in (1)

but I disagree. The (trivial) solution of z=z for the variable z is obviously [z=z] just as the solution of w=z for z is [z=w]

solve(w=z,z)

(5)

Similarly, I think the only reasonable result of solve(0=0,z) is also [z=z]. So I agree that the result should be that same as (1) except that the result of (1) is also wrong!

Note: These are the same as the results returned by Maple.