login  home  contents  what's new  discussion  bug reports     help  links  subscribe  changes  refresh  edit
IssueTracker
#102 solve(sinh(z)=cosh(z), z)  ← ↑ →  #104 branch cuts differ?

#103 solve(z=z, z)
  
last edited 15 years ago by gdr

Edit detail for #103 solve(z=z, z) revision 1 of 3
1 2 3
Editor:
Time: 2007/11/17 21:51:36 GMT-8
Note: fixed by 20070916.01.tpd.patch 
changed:
-
<pre>[Anonymous user:]</pre><br>
This should return [ ] as in (1)

\begin{axiom}
solve(z=z,z)
\end{axiom}

\begin{axiom}
solve(z=z,y)
\end{axiom}

\begin{axiom}
solve(0=0,z)
\end{axiom}

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

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:% ==

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

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

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

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

<pre>[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>]</pre>


<hr><br>
<pre>[William Sit]</pre>

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

\begin{axiom}
p:=0::POLY INT
exquo(p,content p)
exquo(p, content(p,v))
\end{axiom}

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:

<pre>
     x exquo y ==
       zero? y => "failed"
       ...
</pre>

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

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

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

<pre>
     x exquo y ==
       zero? x => 0
       ...
</pre>


From BillPage Thu Feb 17 17:08:53 -0600 2005
From: Bill Page
Date: Thu, 17 Feb 2005 17:08:53 -0600
Subject: solve(z=z, z) should return [z=z]
Message-ID: <20050217170853-0600@page.axiom-developer.org>

Someone wrote:

> This should return <code>[ ]</code> as in (1)

but I disagree. The (trivial) solution of 'z=z' for the variable 'z'
is obviously <code>[z=z]</code> just as the solution of 'w=z' for 'z'
is <code>[z=w]</code>
\begin{axiom}
solve(w=z,z)
\end{axiom}

Similarly, I think the only reasonable result of 'solve(0=0,z)'
is also <code>[z=z]</code>. 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.

From kratt6 Fri Jun 17 08:29:20 -0500 2005
From: kratt6
Date: Fri, 17 Jun 2005 08:29:20 -0500
Subject: property change
Message-ID: <20050617082920-0500@page.axiom-developer.org>

Status: open => fix proposed 


From daly Sun Sep 16 17:53:10 -0500 2007
From: daly
Date: Sun, 16 Sep 2007 17:53:10 -0500
Subject: fixed by 20070916.01.tpd.patch
Message-ID: <20070916175310-0500@wiki.axiom-developer.org>

Status: fix proposed => closed

Submitted by : (unknown) at: 2007-11-17T21:51:36-08:00 (17 years ago)
Name :
Axiom Version :
Category : Severity : Status :
Optional subject :  
Optional comment : 

[Anonymous user:]

This should return [ ]? as in (1)

axiom
solve(z=z,z)
LatexWiki Image(1)
Type: List Equation Fraction Polynomial Integer

axiom
solve(z=z,y)
LatexWiki Image(2)
Type: List Equation Fraction Polynomial Integer

axiom
solve(0=0,z)
LatexWiki Image(3)
Type: List Equation Expression Integer

[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:

axiom
p:=0::POLY INT
LatexWiki Image(4)
Type: Polynomial Integer
axiom
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
       ...

solve(z=z, z) should return [z=z]? --Bill Page, Thu, 17 Feb 2005 17:08:53 -0600 reply
Someone wrote:
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] 

axiom
solve(w=z,z)
LatexWiki Image(5)
Type: List Equation Fraction Polynomial Integer

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.

property change --kratt6, Fri, 17 Jun 2005 08:29:20 -0500 reply
Status: open => fix proposed

fixed by 20070916.01.tpd.patch --daly, Sun, 16 Sep 2007 17:53:10 -0500 reply
Status: fix proposed => closed