## [Maxima-bugs] [ maxima-Bugs-776441 ] orderlessp not transitive

 [Maxima-bugs] [ maxima-Bugs-776441 ] orderlessp not transitive From: SourceForge.net - 2003-07-25 14:26:55 ```Bugs item #776441, was opened at 2003-07-23 14:25 Message generated for change (Comment added) made by macrakis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=776441&group_id=4933 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: orderlessp not transitive Initial Comment: l: [z+x*(x+2)+v+1,z+x^2+x+v+1,z+(x+1)^2+v]; orderlessp(l[1],l[2]) => True orderlessp(l[2],l[3]) => True orderlessp(l[1],l[3]) => False !!! More concise example: q: x^2; r: (x+1)^2; s: x*(x+2); orderlessp(q,r) => true orderlessp(r,s) => true orderlessp(s,q) => true That is, sComment By: Stavros Macrakis (macrakis) Date: 2003-07-25 10:26 Message: Logged In: YES user_id=588346 This not only screws up SORT etc., but even basic simplification, since simplus, simptimes, etc. depend on great: q+r+s => (x+1)^2+x^2+x*(x+2) q+s+r => x^2+x*(x+2)+(x+1)^2 (q+s+r)-(q+s+r) => x^2-x^2 (q+s+r)-(s+q+r) => x^2-x^2 (q+r+s)-(q+s+r) => x (x + 2) - x (x + 2) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=776441&group_id=4933 ```

 [Maxima-bugs] [ maxima-Bugs-776441 ] orderlessp not transitive From: SourceForge.net - 2003-07-23 18:25:15 ```Bugs item #776441, was opened at 2003-07-23 14:25 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=776441&group_id=4933 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: orderlessp not transitive Initial Comment: l: [z+x*(x+2)+v+1,z+x^2+x+v+1,z+(x+1)^2+v]; orderlessp(l[1],l[2]) => True orderlessp(l[2],l[3]) => True orderlessp(l[1],l[3]) => False !!! More concise example: q: x^2; r: (x+1)^2; s: x*(x+2); orderlessp(q,r) => true orderlessp(r,s) => true orderlessp(s,q) => true That is, s
 [Maxima-bugs] [ maxima-Bugs-776441 ] orderlessp not transitive From: SourceForge.net - 2003-07-25 14:26:55 ```Bugs item #776441, was opened at 2003-07-23 14:25 Message generated for change (Comment added) made by macrakis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=776441&group_id=4933 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: orderlessp not transitive Initial Comment: l: [z+x*(x+2)+v+1,z+x^2+x+v+1,z+(x+1)^2+v]; orderlessp(l[1],l[2]) => True orderlessp(l[2],l[3]) => True orderlessp(l[1],l[3]) => False !!! More concise example: q: x^2; r: (x+1)^2; s: x*(x+2); orderlessp(q,r) => true orderlessp(r,s) => true orderlessp(s,q) => true That is, sComment By: Stavros Macrakis (macrakis) Date: 2003-07-25 10:26 Message: Logged In: YES user_id=588346 This not only screws up SORT etc., but even basic simplification, since simplus, simptimes, etc. depend on great: q+r+s => (x+1)^2+x^2+x*(x+2) q+s+r => x^2+x*(x+2)+(x+1)^2 (q+s+r)-(q+s+r) => x^2-x^2 (q+s+r)-(s+q+r) => x^2-x^2 (q+r+s)-(q+s+r) => x (x + 2) - x (x + 2) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=776441&group_id=4933 ```
 [Maxima-bugs] [ maxima-Bugs-776441 ] orderlessp not transitive From: SourceForge.net - 2003-08-05 04:35:45 ```Bugs item #776441, was opened at 2003-07-23 14:25 Message generated for change (Comment added) made by macrakis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=776441&group_id=4933 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: orderlessp not transitive Initial Comment: l: [z+x*(x+2)+v+1,z+x^2+x+v+1,z+(x+1)^2+v]; orderlessp(l[1],l[2]) => True orderlessp(l[2],l[3]) => True orderlessp(l[1],l[3]) => False !!! More concise example: q: x^2; r: (x+1)^2; s: x*(x+2); orderlessp(q,r) => true orderlessp(r,s) => true orderlessp(s,q) => true That is, sComment By: Stavros Macrakis (macrakis) Date: 2003-08-05 00:35 Message: Logged In: YES user_id=588346 More amusing consequences: q+r+s => (x+1)^2+x^2+x*(x+2) expand(%,0,0) => x^2+x*(x+2)+(x+1)^2 expand(%,0,0) => x*(x+2)+(x+1)^2+x^2 expand(%,0,0) => (x+1)^2+x^2+x*(x+2) q+r+s-r-q-s => (x+1)^2+x^2+x*(x+2)-(x+1)^2-x^2-x* (x+2) expand(%,0,0) => x^2-x^2 expand(%,0,0) => 0 I haven't found an example where simptimes fails, though. Fateman reports that this bug is also found in commercial Macsyma 2.4, and calls it a Methuselah bug because it has persisted for so long -- presumably it has been around for 30+ years. ---------------------------------------------------------------------- Comment By: Stavros Macrakis (macrakis) Date: 2003-07-25 10:26 Message: Logged In: YES user_id=588346 This not only screws up SORT etc., but even basic simplification, since simplus, simptimes, etc. depend on great: q+r+s => (x+1)^2+x^2+x*(x+2) q+s+r => x^2+x*(x+2)+(x+1)^2 (q+s+r)-(q+s+r) => x^2-x^2 (q+s+r)-(s+q+r) => x^2-x^2 (q+r+s)-(q+s+r) => x (x + 2) - x (x + 2) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=776441&group_id=4933 ```
 [Maxima-bugs] [ maxima-Bugs-776441 ] orderlessp not transitive From: SourceForge.net - 2003-08-08 23:50:22 ```Bugs item #776441, was opened at 2003-07-23 20:25 Message generated for change (Comment added) made by wjenkner You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=776441&group_id=4933 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: orderlessp not transitive Initial Comment: l: [z+x*(x+2)+v+1,z+x^2+x+v+1,z+(x+1)^2+v]; orderlessp(l[1],l[2]) => True orderlessp(l[2],l[3]) => True orderlessp(l[1],l[3]) => False !!! More concise example: q: x^2; r: (x+1)^2; s: x*(x+2); orderlessp(q,r) => true orderlessp(r,s) => true orderlessp(s,q) => true That is, sComment By: Wolfgang Jenkner (wjenkner) Date: 2003-08-09 01:50 Message: Logged In: YES user_id=581700 This one doesn't even involve MEXPT (I found it while checking one of the cases needed for proving that ORDLIST implements a consistent way of extending a given total order on a set of simplified expressions to their simplified sums and products. So it doesn't...) (C1) orderlessp(t/2,t); (D1) TRUE (C2) orderlessp(t,t+1/4); (D2) TRUE (C3) orderlessp(t/2,t+1/4); (D3) FALSE The point is that t/2 is ((MTIMES SIMP) ((RAT SIMP) 1 2) |\$t|) and, lexicographically, we have (t, 1/2) < (t, 1), (t, 0) < (t, 1/4) and (t, 1/2, *) > (t, 1/4, +). So t corresponds to (t, 1) in the first comparison and to (t, 0) in the second comparison. Trouble. Floats instead of rational numbers give the same results, by the way. This one is more like Stavros's examples. (C1) orderlessp((x+1)^2,x^2-1); (D1) TRUE (C2) orderlessp(x^2-1,x^2); (D2) TRUE (C3) orderlessp((x+1)^2,x^2); (D3) FALSE Maybe powers whose exponents are positive integers should be treated like products. Actually, ORDMEXPT does this already but it isn't always called by ORDFN, for whatever reason. Anyway, here is the patch I'm currently experimenting with (it solves all the issues reported by Stavros and also the last example above, but in light of the other example it is certainly far from being a complete solution. It might even be totally wrong since I have no reason to believe that it is more than a simple palliative and that it would make things more consistent). ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ cut ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Index: simp.lisp =================================================================== RCS file: /cvsroot/maxima/maxima/src/simp.lisp,v retrieving revision 1.5 diff -C2 -r1.5 simp.lisp *** simp.lisp 5 Mar 2003 01:36:26 -0000 1.5 --- simp.lisp 8 Aug 2003 19:10:57 -0000 *************** *** 1848,1854 **** ((MEMQ CX '(MPLUS MTIMES)) (COND ((MEMQ CY '(MPLUS MTIMES)) (ORDLIST (CDR X) (CDR Y) CX CY)) ! ((ALIKE1 (SETQ U (CAR (LAST X))) Y) (NOT (ORDHACK X))) ! ((AND (EQ CX 'MPLUS) (EQ CY 'MEXPT) (MPLUSP (CADR Y))) (NOT (ORDMEXPT Y X))) (T (GREAT U Y)))) ((MEMQ CY '(MPLUS MTIMES)) (NOT (ORDFN Y X))) --- 1848,1854 ---- ((MEMQ CX '(MPLUS MTIMES)) (COND ((MEMQ CY '(MPLUS MTIMES)) (ORDLIST (CDR X) (CDR Y) CX CY)) ! ((AND (EQ CX 'MPLUS) (EQ CY 'MEXPT)) (NOT (ORDMEXPT Y X))) + ((ALIKE1 (SETQ U (CAR (LAST X))) Y) (NOT (ORDHACK X))) (T (GREAT U Y)))) ((MEMQ CY '(MPLUS MTIMES)) (NOT (ORDFN Y X))) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ cut ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ---------------------------------------------------------------------- Comment By: Stavros Macrakis (macrakis) Date: 2003-08-05 06:35 Message: Logged In: YES user_id=588346 More amusing consequences: q+r+s => (x+1)^2+x^2+x*(x+2) expand(%,0,0) => x^2+x*(x+2)+(x+1)^2 expand(%,0,0) => x*(x+2)+(x+1)^2+x^2 expand(%,0,0) => (x+1)^2+x^2+x*(x+2) q+r+s-r-q-s => (x+1)^2+x^2+x*(x+2)-(x+1)^2-x^2-x* (x+2) expand(%,0,0) => x^2-x^2 expand(%,0,0) => 0 I haven't found an example where simptimes fails, though. Fateman reports that this bug is also found in commercial Macsyma 2.4, and calls it a Methuselah bug because it has persisted for so long -- presumably it has been around for 30+ years. ---------------------------------------------------------------------- Comment By: Stavros Macrakis (macrakis) Date: 2003-07-25 16:26 Message: Logged In: YES user_id=588346 This not only screws up SORT etc., but even basic simplification, since simplus, simptimes, etc. depend on great: q+r+s => (x+1)^2+x^2+x*(x+2) q+s+r => x^2+x*(x+2)+(x+1)^2 (q+s+r)-(q+s+r) => x^2-x^2 (q+s+r)-(s+q+r) => x^2-x^2 (q+r+s)-(q+s+r) => x (x + 2) - x (x + 2) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=776441&group_id=4933 ```
 [Maxima-bugs] [ maxima-Bugs-776441 ] orderlessp not transitive From: SourceForge.net - 2006-07-08 17:13:17 ```Bugs item #776441, was opened at 2003-07-23 12:25 Message generated for change (Settings changed) made by robert_dodier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=776441&group_id=4933 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. >Category: Lisp Core Group: None Status: Open Resolution: None >Priority: 7 Submitted By: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: orderlessp not transitive Initial Comment: l: [z+x*(x+2)+v+1,z+x^2+x+v+1,z+(x+1)^2+v]; orderlessp(l[1],l[2]) => True orderlessp(l[2],l[3]) => True orderlessp(l[1],l[3]) => False !!! More concise example: q: x^2; r: (x+1)^2; s: x*(x+2); orderlessp(q,r) => true orderlessp(r,s) => true orderlessp(s,q) => true That is, s<q<r<s. The problem is somewhere in the internal great function, which by the way does some strange things, in particular: why does ordlist have an explicit check for mplus: (RETURN (COND ((= L2 0) (EQ CX 'MPLUS)) (Thanks to Barton for his contributions to tracking this down.) Maxima 5.9.0 GCL 2.5.0 ---------------------------------------------------------------------- >Comment By: Robert Dodier (robert_dodier) Date: 2006-07-08 11:13 Message: Logged In: YES user_id=501686 Increasing the priority on this one -- potential for subtle breakage in various contexts. ---------------------------------------------------------------------- Comment By: Wolfgang Jenkner (wjenkner) Date: 2003-08-08 17:50 Message: Logged In: YES user_id=581700 This one doesn't even involve MEXPT (I found it while checking one of the cases needed for proving that ORDLIST implements a consistent way of extending a given total order on a set of simplified expressions to their simplified sums and products. So it doesn't...) (C1) orderlessp(t/2,t); (D1) TRUE (C2) orderlessp(t,t+1/4); (D2) TRUE (C3) orderlessp(t/2,t+1/4); (D3) FALSE The point is that t/2 is ((MTIMES SIMP) ((RAT SIMP) 1 2) |\$t|) and, lexicographically, we have (t, 1/2) < (t, 1), (t, 0) < (t, 1/4) and (t, 1/2, *) > (t, 1/4, +). So t corresponds to (t, 1) in the first comparison and to (t, 0) in the second comparison. Trouble. Floats instead of rational numbers give the same results, by the way. This one is more like Stavros's examples. (C1) orderlessp((x+1)^2,x^2-1); (D1) TRUE (C2) orderlessp(x^2-1,x^2); (D2) TRUE (C3) orderlessp((x+1)^2,x^2); (D3) FALSE Maybe powers whose exponents are positive integers should be treated like products. Actually, ORDMEXPT does this already but it isn't always called by ORDFN, for whatever reason. Anyway, here is the patch I'm currently experimenting with (it solves all the issues reported by Stavros and also the last example above, but in light of the other example it is certainly far from being a complete solution. It might even be totally wrong since I have no reason to believe that it is more than a simple palliative and that it would make things more consistent). ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ cut ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Index: simp.lisp =================================================================== RCS file: /cvsroot/maxima/maxima/src/simp.lisp,v retrieving revision 1.5 diff -C2 -r1.5 simp.lisp *** simp.lisp 5 Mar 2003 01:36:26 -0000 1.5 --- simp.lisp 8 Aug 2003 19:10:57 -0000 *************** *** 1848,1854 **** ((MEMQ CX '(MPLUS MTIMES)) (COND ((MEMQ CY '(MPLUS MTIMES)) (ORDLIST (CDR X) (CDR Y) CX CY)) ! ((ALIKE1 (SETQ U (CAR (LAST X))) Y) (NOT (ORDHACK X))) ! ((AND (EQ CX 'MPLUS) (EQ CY 'MEXPT) (MPLUSP (CADR Y))) (NOT (ORDMEXPT Y X))) (T (GREAT U Y)))) ((MEMQ CY '(MPLUS MTIMES)) (NOT (ORDFN Y X))) --- 1848,1854 ---- ((MEMQ CX '(MPLUS MTIMES)) (COND ((MEMQ CY '(MPLUS MTIMES)) (ORDLIST (CDR X) (CDR Y) CX CY)) ! ((AND (EQ CX 'MPLUS) (EQ CY 'MEXPT)) (NOT (ORDMEXPT Y X))) + ((ALIKE1 (SETQ U (CAR (LAST X))) Y) (NOT (ORDHACK X))) (T (GREAT U Y)))) ((MEMQ CY '(MPLUS MTIMES)) (NOT (ORDFN Y X))) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ cut ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ---------------------------------------------------------------------- Comment By: Stavros Macrakis (macrakis) Date: 2003-08-04 22:35 Message: Logged In: YES user_id=588346 More amusing consequences: q+r+s => (x+1)^2+x^2+x*(x+2) expand(%,0,0) => x^2+x*(x+2)+(x+1)^2 expand(%,0,0) => x*(x+2)+(x+1)^2+x^2 expand(%,0,0) => (x+1)^2+x^2+x*(x+2) q+r+s-r-q-s => (x+1)^2+x^2+x*(x+2)-(x+1)^2-x^2-x* (x+2) expand(%,0,0) => x^2-x^2 expand(%,0,0) => 0 I haven't found an example where simptimes fails, though. Fateman reports that this bug is also found in commercial Macsyma 2.4, and calls it a Methuselah bug because it has persisted for so long -- presumably it has been around for 30+ years. ---------------------------------------------------------------------- Comment By: Stavros Macrakis (macrakis) Date: 2003-07-25 08:26 Message: Logged In: YES user_id=588346 This not only screws up SORT etc., but even basic simplification, since simplus, simptimes, etc. depend on great: q+r+s => (x+1)^2+x^2+x*(x+2) q+s+r => x^2+x*(x+2)+(x+1)^2 (q+s+r)-(q+s+r) => x^2-x^2 (q+s+r)-(s+q+r) => x^2-x^2 (q+r+s)-(q+s+r) => x (x + 2) - x (x + 2) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=776441&group_id=4933 ```
 [Maxima-bugs] [ maxima-Bugs-776441 ] orderlessp not transitive From: SourceForge.net - 2009-12-14 00:29:08 ```Bugs item #776441, was opened at 2003-07-23 14:25 Message generated for change (Settings changed) made by dgildea You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=776441&group_id=4933 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Lisp Core Group: None >Status: Pending >Resolution: Fixed Priority: 7 Private: No Submitted By: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: orderlessp not transitive Initial Comment: l: [z+x*(x+2)+v+1,z+x^2+x+v+1,z+(x+1)^2+v]; orderlessp(l[1],l[2]) => True orderlessp(l[2],l[3]) => True orderlessp(l[1],l[3]) => False !!! More concise example: q: x^2; r: (x+1)^2; s: x*(x+2); orderlessp(q,r) => true orderlessp(r,s) => true orderlessp(s,q) => true That is, s<q<r<s. The problem is somewhere in the internal great function, which by the way does some strange things, in particular: why does ordlist have an explicit check for mplus: (RETURN (COND ((= L2 0) (EQ CX 'MPLUS)) (Thanks to Barton for his contributions to tracking this down.) Maxima 5.9.0 GCL 2.5.0 ---------------------------------------------------------------------- >Comment By: Dan Gildea (dgildea) Date: 2009-12-13 19:29 Message: I think these issues are resolved in simp.lisp rev 1.93. ---------------------------------------------------------------------- Comment By: Robert Dodier (robert_dodier) Date: 2006-07-08 13:13 Message: Logged In: YES user_id=501686 Increasing the priority on this one -- potential for subtle breakage in various contexts. ---------------------------------------------------------------------- Comment By: Wolfgang Jenkner (wjenkner) Date: 2003-08-08 19:50 Message: Logged In: YES user_id=581700 This one doesn't even involve MEXPT (I found it while checking one of the cases needed for proving that ORDLIST implements a consistent way of extending a given total order on a set of simplified expressions to their simplified sums and products. So it doesn't...) (C1) orderlessp(t/2,t); (D1) TRUE (C2) orderlessp(t,t+1/4); (D2) TRUE (C3) orderlessp(t/2,t+1/4); (D3) FALSE The point is that t/2 is ((MTIMES SIMP) ((RAT SIMP) 1 2) |\$t|) and, lexicographically, we have (t, 1/2) < (t, 1), (t, 0) < (t, 1/4) and (t, 1/2, *) > (t, 1/4, +). So t corresponds to (t, 1) in the first comparison and to (t, 0) in the second comparison. Trouble. Floats instead of rational numbers give the same results, by the way. This one is more like Stavros's examples. (C1) orderlessp((x+1)^2,x^2-1); (D1) TRUE (C2) orderlessp(x^2-1,x^2); (D2) TRUE (C3) orderlessp((x+1)^2,x^2); (D3) FALSE Maybe powers whose exponents are positive integers should be treated like products. Actually, ORDMEXPT does this already but it isn't always called by ORDFN, for whatever reason. Anyway, here is the patch I'm currently experimenting with (it solves all the issues reported by Stavros and also the last example above, but in light of the other example it is certainly far from being a complete solution. It might even be totally wrong since I have no reason to believe that it is more than a simple palliative and that it would make things more consistent). ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ cut ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Index: simp.lisp =================================================================== RCS file: /cvsroot/maxima/maxima/src/simp.lisp,v retrieving revision 1.5 diff -C2 -r1.5 simp.lisp *** simp.lisp 5 Mar 2003 01:36:26 -0000 1.5 --- simp.lisp 8 Aug 2003 19:10:57 -0000 *************** *** 1848,1854 **** ((MEMQ CX '(MPLUS MTIMES)) (COND ((MEMQ CY '(MPLUS MTIMES)) (ORDLIST (CDR X) (CDR Y) CX CY)) ! ((ALIKE1 (SETQ U (CAR (LAST X))) Y) (NOT (ORDHACK X))) ! ((AND (EQ CX 'MPLUS) (EQ CY 'MEXPT) (MPLUSP (CADR Y))) (NOT (ORDMEXPT Y X))) (T (GREAT U Y)))) ((MEMQ CY '(MPLUS MTIMES)) (NOT (ORDFN Y X))) --- 1848,1854 ---- ((MEMQ CX '(MPLUS MTIMES)) (COND ((MEMQ CY '(MPLUS MTIMES)) (ORDLIST (CDR X) (CDR Y) CX CY)) ! ((AND (EQ CX 'MPLUS) (EQ CY 'MEXPT)) (NOT (ORDMEXPT Y X))) + ((ALIKE1 (SETQ U (CAR (LAST X))) Y) (NOT (ORDHACK X))) (T (GREAT U Y)))) ((MEMQ CY '(MPLUS MTIMES)) (NOT (ORDFN Y X))) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ cut ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ---------------------------------------------------------------------- Comment By: Stavros Macrakis (macrakis) Date: 2003-08-05 00:35 Message: Logged In: YES user_id=588346 More amusing consequences: q+r+s => (x+1)^2+x^2+x*(x+2) expand(%,0,0) => x^2+x*(x+2)+(x+1)^2 expand(%,0,0) => x*(x+2)+(x+1)^2+x^2 expand(%,0,0) => (x+1)^2+x^2+x*(x+2) q+r+s-r-q-s => (x+1)^2+x^2+x*(x+2)-(x+1)^2-x^2-x* (x+2) expand(%,0,0) => x^2-x^2 expand(%,0,0) => 0 I haven't found an example where simptimes fails, though. Fateman reports that this bug is also found in commercial Macsyma 2.4, and calls it a Methuselah bug because it has persisted for so long -- presumably it has been around for 30+ years. ---------------------------------------------------------------------- Comment By: Stavros Macrakis (macrakis) Date: 2003-07-25 10:26 Message: Logged In: YES user_id=588346 This not only screws up SORT etc., but even basic simplification, since simplus, simptimes, etc. depend on great: q+r+s => (x+1)^2+x^2+x*(x+2) q+s+r => x^2+x*(x+2)+(x+1)^2 (q+s+r)-(q+s+r) => x^2-x^2 (q+s+r)-(s+q+r) => x^2-x^2 (q+r+s)-(q+s+r) => x (x + 2) - x (x + 2) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=776441&group_id=4933 ```
 [Maxima-bugs] [ maxima-Bugs-776441 ] orderlessp not transitive From: SourceForge.net - 2009-12-28 02:20:38 ```Bugs item #776441, was opened at 2003-07-23 18:25 Message generated for change (Comment added) made by sf-robot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=776441&group_id=4933 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Lisp Core Group: None >Status: Closed Resolution: Fixed Priority: 7 Private: No Submitted By: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: orderlessp not transitive Initial Comment: l: [z+x*(x+2)+v+1,z+x^2+x+v+1,z+(x+1)^2+v]; orderlessp(l[1],l[2]) => True orderlessp(l[2],l[3]) => True orderlessp(l[1],l[3]) => False !!! More concise example: q: x^2; r: (x+1)^2; s: x*(x+2); orderlessp(q,r) => true orderlessp(r,s) => true orderlessp(s,q) => true That is, s<q<r<s. The problem is somewhere in the internal great function, which by the way does some strange things, in particular: why does ordlist have an explicit check for mplus: (RETURN (COND ((= L2 0) (EQ CX 'MPLUS)) (Thanks to Barton for his contributions to tracking this down.) Maxima 5.9.0 GCL 2.5.0 ---------------------------------------------------------------------- >Comment By: SourceForge Robot (sf-robot) Date: 2009-12-28 02:20 Message: This Tracker item was closed automatically by the system. It was previously set to a Pending status, and the original submitter did not respond within 14 days (the time period specified by the administrator of this Tracker). ---------------------------------------------------------------------- Comment By: Dan Gildea (dgildea) Date: 2009-12-14 00:29 Message: I think these issues are resolved in simp.lisp rev 1.93. ---------------------------------------------------------------------- Comment By: Robert Dodier (robert_dodier) Date: 2006-07-08 17:13 Message: Logged In: YES user_id=501686 Increasing the priority on this one -- potential for subtle breakage in various contexts. ---------------------------------------------------------------------- Comment By: Wolfgang Jenkner (wjenkner) Date: 2003-08-08 23:50 Message: Logged In: YES user_id=581700 This one doesn't even involve MEXPT (I found it while checking one of the cases needed for proving that ORDLIST implements a consistent way of extending a given total order on a set of simplified expressions to their simplified sums and products. So it doesn't...) (C1) orderlessp(t/2,t); (D1) TRUE (C2) orderlessp(t,t+1/4); (D2) TRUE (C3) orderlessp(t/2,t+1/4); (D3) FALSE The point is that t/2 is ((MTIMES SIMP) ((RAT SIMP) 1 2) |\$t|) and, lexicographically, we have (t, 1/2) < (t, 1), (t, 0) < (t, 1/4) and (t, 1/2, *) > (t, 1/4, +). So t corresponds to (t, 1) in the first comparison and to (t, 0) in the second comparison. Trouble. Floats instead of rational numbers give the same results, by the way. This one is more like Stavros's examples. (C1) orderlessp((x+1)^2,x^2-1); (D1) TRUE (C2) orderlessp(x^2-1,x^2); (D2) TRUE (C3) orderlessp((x+1)^2,x^2); (D3) FALSE Maybe powers whose exponents are positive integers should be treated like products. Actually, ORDMEXPT does this already but it isn't always called by ORDFN, for whatever reason. Anyway, here is the patch I'm currently experimenting with (it solves all the issues reported by Stavros and also the last example above, but in light of the other example it is certainly far from being a complete solution. It might even be totally wrong since I have no reason to believe that it is more than a simple palliative and that it would make things more consistent). ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ cut ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Index: simp.lisp =================================================================== RCS file: /cvsroot/maxima/maxima/src/simp.lisp,v retrieving revision 1.5 diff -C2 -r1.5 simp.lisp *** simp.lisp 5 Mar 2003 01:36:26 -0000 1.5 --- simp.lisp 8 Aug 2003 19:10:57 -0000 *************** *** 1848,1854 **** ((MEMQ CX '(MPLUS MTIMES)) (COND ((MEMQ CY '(MPLUS MTIMES)) (ORDLIST (CDR X) (CDR Y) CX CY)) ! ((ALIKE1 (SETQ U (CAR (LAST X))) Y) (NOT (ORDHACK X))) ! ((AND (EQ CX 'MPLUS) (EQ CY 'MEXPT) (MPLUSP (CADR Y))) (NOT (ORDMEXPT Y X))) (T (GREAT U Y)))) ((MEMQ CY '(MPLUS MTIMES)) (NOT (ORDFN Y X))) --- 1848,1854 ---- ((MEMQ CX '(MPLUS MTIMES)) (COND ((MEMQ CY '(MPLUS MTIMES)) (ORDLIST (CDR X) (CDR Y) CX CY)) ! ((AND (EQ CX 'MPLUS) (EQ CY 'MEXPT)) (NOT (ORDMEXPT Y X))) + ((ALIKE1 (SETQ U (CAR (LAST X))) Y) (NOT (ORDHACK X))) (T (GREAT U Y)))) ((MEMQ CY '(MPLUS MTIMES)) (NOT (ORDFN Y X))) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ cut ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ---------------------------------------------------------------------- Comment By: Stavros Macrakis (macrakis) Date: 2003-08-05 04:35 Message: Logged In: YES user_id=588346 More amusing consequences: q+r+s => (x+1)^2+x^2+x*(x+2) expand(%,0,0) => x^2+x*(x+2)+(x+1)^2 expand(%,0,0) => x*(x+2)+(x+1)^2+x^2 expand(%,0,0) => (x+1)^2+x^2+x*(x+2) q+r+s-r-q-s => (x+1)^2+x^2+x*(x+2)-(x+1)^2-x^2-x* (x+2) expand(%,0,0) => x^2-x^2 expand(%,0,0) => 0 I haven't found an example where simptimes fails, though. Fateman reports that this bug is also found in commercial Macsyma 2.4, and calls it a Methuselah bug because it has persisted for so long -- presumably it has been around for 30+ years. ---------------------------------------------------------------------- Comment By: Stavros Macrakis (macrakis) Date: 2003-07-25 14:26 Message: Logged In: YES user_id=588346 This not only screws up SORT etc., but even basic simplification, since simplus, simptimes, etc. depend on great: q+r+s => (x+1)^2+x^2+x*(x+2) q+s+r => x^2+x*(x+2)+(x+1)^2 (q+s+r)-(q+s+r) => x^2-x^2 (q+s+r)-(s+q+r) => x^2-x^2 (q+r+s)-(q+s+r) => x (x + 2) - x (x + 2) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=776441&group_id=4933 ```