You can subscribe to this list here.
2002 
_{Jan}

_{Feb}

_{Mar}

_{Apr}

_{May}

_{Jun}
(67) 
_{Jul}
(61) 
_{Aug}
(49) 
_{Sep}
(43) 
_{Oct}
(59) 
_{Nov}
(24) 
_{Dec}
(18) 

2003 
_{Jan}
(34) 
_{Feb}
(35) 
_{Mar}
(72) 
_{Apr}
(42) 
_{May}
(46) 
_{Jun}
(15) 
_{Jul}
(64) 
_{Aug}
(62) 
_{Sep}
(22) 
_{Oct}
(41) 
_{Nov}
(57) 
_{Dec}
(56) 
2004 
_{Jan}
(48) 
_{Feb}
(47) 
_{Mar}
(33) 
_{Apr}
(39) 
_{May}
(6) 
_{Jun}
(17) 
_{Jul}
(19) 
_{Aug}
(10) 
_{Sep}
(14) 
_{Oct}
(74) 
_{Nov}
(80) 
_{Dec}
(22) 
2005 
_{Jan}
(43) 
_{Feb}
(33) 
_{Mar}
(52) 
_{Apr}
(74) 
_{May}
(32) 
_{Jun}
(58) 
_{Jul}
(18) 
_{Aug}
(41) 
_{Sep}
(71) 
_{Oct}
(28) 
_{Nov}
(65) 
_{Dec}
(68) 
2006 
_{Jan}
(54) 
_{Feb}
(37) 
_{Mar}
(82) 
_{Apr}
(211) 
_{May}
(69) 
_{Jun}
(75) 
_{Jul}
(279) 
_{Aug}
(139) 
_{Sep}
(135) 
_{Oct}
(58) 
_{Nov}
(81) 
_{Dec}
(78) 
2007 
_{Jan}
(141) 
_{Feb}
(134) 
_{Mar}
(65) 
_{Apr}
(49) 
_{May}
(61) 
_{Jun}
(90) 
_{Jul}
(72) 
_{Aug}
(53) 
_{Sep}
(86) 
_{Oct}
(61) 
_{Nov}
(62) 
_{Dec}
(101) 
2008 
_{Jan}
(100) 
_{Feb}
(66) 
_{Mar}
(76) 
_{Apr}
(95) 
_{May}
(77) 
_{Jun}
(93) 
_{Jul}
(103) 
_{Aug}
(76) 
_{Sep}
(42) 
_{Oct}
(55) 
_{Nov}
(44) 
_{Dec}
(75) 
2009 
_{Jan}
(103) 
_{Feb}
(105) 
_{Mar}
(121) 
_{Apr}
(59) 
_{May}
(103) 
_{Jun}
(82) 
_{Jul}
(67) 
_{Aug}
(76) 
_{Sep}
(85) 
_{Oct}
(75) 
_{Nov}
(181) 
_{Dec}
(133) 
2010 
_{Jan}
(107) 
_{Feb}
(116) 
_{Mar}
(145) 
_{Apr}
(89) 
_{May}
(138) 
_{Jun}
(85) 
_{Jul}
(82) 
_{Aug}
(111) 
_{Sep}
(70) 
_{Oct}
(83) 
_{Nov}
(60) 
_{Dec}
(16) 
2011 
_{Jan}
(61) 
_{Feb}
(16) 
_{Mar}
(52) 
_{Apr}
(41) 
_{May}
(34) 
_{Jun}
(41) 
_{Jul}
(57) 
_{Aug}
(73) 
_{Sep}
(21) 
_{Oct}
(45) 
_{Nov}
(50) 
_{Dec}
(28) 
2012 
_{Jan}
(70) 
_{Feb}
(36) 
_{Mar}
(71) 
_{Apr}
(29) 
_{May}
(48) 
_{Jun}
(61) 
_{Jul}
(44) 
_{Aug}
(54) 
_{Sep}
(20) 
_{Oct}
(28) 
_{Nov}
(41) 
_{Dec}
(137) 
2013 
_{Jan}
(62) 
_{Feb}
(55) 
_{Mar}
(31) 
_{Apr}
(23) 
_{May}
(54) 
_{Jun}
(54) 
_{Jul}
(90) 
_{Aug}
(46) 
_{Sep}
(38) 
_{Oct}
(60) 
_{Nov}
(92) 
_{Dec}
(17) 
2014 
_{Jan}
(62) 
_{Feb}
(35) 
_{Mar}
(72) 
_{Apr}
(30) 
_{May}
(97) 
_{Jun}
(81) 
_{Jul}
(63) 
_{Aug}
(64) 
_{Sep}
(28) 
_{Oct}
(45) 
_{Nov}
(48) 
_{Dec}
(109) 
2015 
_{Jan}
(106) 
_{Feb}
(36) 
_{Mar}
(65) 
_{Apr}
(63) 
_{May}
(95) 
_{Jun}
(56) 
_{Jul}
(48) 
_{Aug}
(55) 
_{Sep}
(100) 
_{Oct}
(57) 
_{Nov}
(33) 
_{Dec}
(46) 
2016 
_{Jan}
(76) 
_{Feb}
(53) 
_{Mar}
(88) 
_{Apr}
(79) 
_{May}
(62) 
_{Jun}
(65) 
_{Jul}
(37) 
_{Aug}
(23) 
_{Sep}
(108) 
_{Oct}
(68) 
_{Nov}
(66) 
_{Dec}
(47) 
2017 
_{Jan}
(55) 
_{Feb}
(11) 
_{Mar}

_{Apr}

_{May}

_{Jun}

_{Jul}

_{Aug}

_{Sep}

_{Oct}

_{Nov}

_{Dec}

S  M  T  W  T  F  S 






1
(2) 
2
(4) 
3

4
(11) 
5

6

7

8
(4) 
9
(1) 
10
(10) 
11
(3) 
12

13
(1) 
14

15
(1) 
16
(1) 
17

18
(1) 
19
(13) 
20

21
(2) 
22
(4) 
23

24

25

26
(13) 
27
(6) 
28

29

30
(1) 
31







From: SourceForge.net <noreply@so...>  20061219 15:13:50

Bugs item #1617688, was opened at 20061217 20:36 Message generated for change (Comment added) made by robert_dodier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1617688&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 Private: No Submitted By: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: scanmap coredumps (GCL) Initial Comment: scanmap(polarform,[%i]) coredumps: "unknown software exception 0xc00000fd occurred at location 0x00608df4. Same thing for scanmap(polarform,1+%i). Though this must reflect a problem in Maxima (infinite recursion?), it also seems to reflect a problem in GCL (not handling stack overflow gracefully?). Maxima 5.10.0 GCL 2.6.8 Windows 2000 Athlon  >Comment By: Robert Dodier (robert_dodier) Date: 20061219 08:13 Message: Logged In: YES user_id=501686 Originator: NO The immediate problem is that SCANMAP1 (src/comm2.lisp) calls itself on the result of applying SCANMAP1. Since polarform(%i) => exp(%i*%pi/2) which contains %i, that causes a bottomless recursion. Aside from polarform, it seems like any function which yields an expression containing the original expression has the potential for causing stack overflow. Here is a definition of scanmap which (I hope) avoids stack overflow. newscanmap has this effect: apply oldscanmap with 1st argument = gensym, then substitute newscanmap 1st argument for gensym and evaluate. Comments? For the record: scanmap(polarform, [%i], bottomup) => [%i] (which seems incorrect; should be [exp(%i*%pi/2)] instead) Clisp 2.39 + Maxima 5.10.99rc2 + scanmap(polarform,[%i]) => stack overflow SBCL 1.0 + Maxima 5.10.99rc2 + scanmap(polarform,[%i]) => "Control stack exhausted (no more space for function call frames)"  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1617688&group_id=4933 
From: SourceForge.net <noreply@so...>  20061219 05:09:43

Bugs item #649669, was opened at 20021206 11:55 Message generated for change (Comment added) made by robert_dodier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=649669&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: 5 Private: No Submitted By: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: is(equal([x],[rat(x)])) => error Initial Comment: is(equal([x],[rat(x)])) => FATAL ERROR Macsyma 5.5  >Comment By: Robert Dodier (robert_dodier) Date: 20061218 22:09 Message: Logged In: YES user_id=501686 Originator: NO Fixed by r1.16 src/compar.lisp (by Barton Willis).  Comment By: Robert Dodier (robert_dodier) Date: 20060630 22:50 Message: Logged In: YES user_id=501686 Still present in 5.9.3cvs. gcl => "Caught fatal error [memory may be damaged]" sbcl & clisp => "1 is not a list" Probably ratdisrep or something like that needs to be called. See also bug report # 643254 "orderlessp([rat(x)], [rat(x)])".  Comment By: Robert Dodier (robert_dodier) Date: 20031209 19:19 Message: Logged In: YES user_id=501686 I tried this again with a build from cvs dated 20031128, and I don't get a fatal error, I get: Maxima encountered a Lisp error: CAR: 1 is not a LIST Automatically continuing. To reenable the Lisp debugger set *debuggerhook* to nil. and then it's back to the user input prompt. I'm running Maxima on clisp 2.31. I don't know what the right behavior is, but it's encouraging that I didn't get a fatal error.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=649669&group_id=4933 
From: SourceForge.net <noreply@so...>  20061219 05:08:40

Bugs item #812968, was opened at 20030926 03:29 Message generated for change (Comment added) made by robert_dodier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=812968&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: 5 Private: No Submitted By: Joel Ray Holveck (piquan) Assigned to: Nobody/Anonymous (nobody) Summary: is(equal(...)) says unknown, ratsimp says 0 Initial Comment: The way I understood EQUAL, it seems that it's supposed to answer true if ratsimp returns true. But in the following equation, it is clear that this is not happening. Sorry about the mess; this was the simplest reproduction scenario I could find. (C112) is(equal(x/(2*x*sqrt(2))  1/(2*x*sqrt(2)), (x1)/(2*x*sqrt(2)))); (D112) UNKNOWN (C113) is(equal(x/(2*x*sqrt(2))  1/(2*x*sqrt(2)), (x)/(2*x*sqrt(2))1/(2*x*sqrt(2)))); (D113) TRUE (C114) ratsimp(x/(2*x*sqrt(2))  1/(2*x*sqrt(2))  (x1)/(2*x*sqrt(2))); (D114) 0 (C115) facts(); (D115) [NOT EQUAL(x, 0)] I did consider that the problem may be related to the fact that ratsimp simplifies the two sides of the equation differently, so I tried putting them on the same side. In the following, the left side of the equal ratsimp's to 0 (as seen in D114), and yet equal doesn't assert that it's equal to 0. (C130) is(equal(x/(2*x*sqrt(2))  1/(2*x*sqrt(2))  (x1)/(2*x*sqrt(2)), 0)); (D130) UNKNOWN I may be missing something obvious here I'm just learning Maxima but this seems off to me.  >Comment By: Robert Dodier (robert_dodier) Date: 20061218 22:08 Message: Logged In: YES user_id=501686 Originator: NO Fixed by r1.16 src/compar.lisp (by Barton Willis).  Comment By: Robert Dodier (robert_dodier) Date: 20060709 21:42 Message: Logged In: YES user_id=501686 Still present in 5.9.3cvs.  Comment By: Robert Dodier (robert_dodier) Date: 20060326 17:44 Message: Logged In: YES user_id=501686 Looking at src/compar.lisp, it appears that the compare and sign functions don't call ratsimp, maybe they should. Hard to tell what's going on in compar.lisp.  Comment By: Stavros Macrakis (macrakis) Date: 20030927 11:58 Message: Logged In: YES user_id=588346 You are absolutely right: this is a bug. Worse, is(equal(1/sqrt(2),sqrt(2)/2)) and even is(equal(1/sqrt (2)sqrt(2)/2,0)) return False! As you say, it should be using ratsimp(1/sqrt(2)sqrt(2)/2)  which does correctly return 0. It is also a known problem (bug?) that 1/sqrt(2) and sqrt(2)/2 do not simplify to the same thing, but as you say, even when you put them on the same side, it doesn't work.... 5.9.0 gcl 2.5.0 W2k  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=812968&group_id=4933 
From: SourceForge.net <noreply@so...>  20061219 05:07:15

Bugs item #851436, was opened at 20031129 21:53 Message generated for change (Comment added) made by robert_dodier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=851436&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: 5 Private: No Submitted By: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: is/equal fails with varying vrbl ordering Initial Comment: is(equal(rat((x+y+a)^3,x),rat((x+y+a)^3,y))) is "unable to evaluate the predicate". This is really annoying. Equal should at least check whether ratsimp(ab)=0. It is also annoying that equal disreps rat expressions for no good reason. Unfortunately, you can't simply add $equal to (mlist mequal) in simpargs because meqp gets confused. But something like that would be good when someone has the time to test thoroughly.  >Comment By: Robert Dodier (robert_dodier) Date: 20061218 22:07 Message: Logged In: YES user_id=501686 Originator: NO Fixed by r1.16 src/compar.lisp (by Barton Willis).  Comment By: Robert Dodier (robert_dodier) Date: 20060713 00:02 Message: Logged In: YES user_id=501686 Observed in 5.9.3cvs.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=851436&group_id=4933 
From: SourceForge.net <noreply@so...>  20061219 05:06:33

Bugs item #884947, was opened at 20040126 11:34 Message generated for change (Comment added) made by robert_dodier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=884947&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: Includes proposed fix >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: Is/equal doesn\'t work for [], matrix, etc./FIX Initial Comment: Currently, IS doesn't understand semanticequality of bags (lists, matrices, sets) at all: is(equal([1],[1])) => true OK is(equal([0],[1])) => Unknown NO The first case only works because the two expressions are syntactically equal (is/= or ?like). The problem is that meqp uses compare, which compares x and y by comparing xy to (scalar) 0, obviously irrelevant here. The solution is to explicitly add bags to meqp and mnqp. See code attached. With this code, we have: is(equal([1],[1])) => true is(equal([0],[1])) => false is(equal([a,0],[a,1])) => false is(equal([a,b],[a,c])) => unknown HOWEVER: a) this code ignores doscmxplus, so lists are never considered equal to matrices; b) the assume database is not consulted in cases like equal(x,[a,b]), because compar thinks this is the same as equal([xa,x b],0). I considered also adding ordering inequalities (< etc.), but I don't think it's worth it right now given the limited capabilities of compar. Also, it's not clear whether lexicographic ([a,b]<[c,d] iff (a<c or (a=c and b<d)) or dominating order (a<c and b<d  nontrichotomic) is more useful. This was originally reported by Robert Dodier in email.  >Comment By: Robert Dodier (robert_dodier) Date: 20061218 22:06 Message: Logged In: YES user_id=501686 Originator: NO Fixed by r1.16 src/compar.lisp (by Barton Willis).  Comment By: Stavros Macrakis (macrakis) Date: 20040127 13:48 Message: Logged In: YES user_id=588346 These are some design notes I posted to the Maxima mailing list on this subject. Robert Dodier said: > is(equal([1],[[1]]))) => UNKNOWN. > I would expect that different structures are always not > equal, unless they're equivalent (i.e., you could substitute > one for the other in any expression and get the same result). > So either TRUE or FALSE seems possible here, but not UNKNOWN. I had written code to assume that objects of differing dimensions were different (in particular, that nonscalars can never be equal to scalars), but ran into a whole bunch of inconsistencies in Maxima semantics. These are not accidental inconsistencies, they are not bugs; they are in fact design features to make the use of Maxima more convenient. But as is often the case, convenience conflicts with consistency. Clearly is(1=[1]) is false; remember, = performs structural (syntactic) comparison. However, it is not at all clear whether is(equal(1,[1])) is false. (And whether it is False or True depends not only on various flag settings, but also the context of use.) Consider: Lists, 1xn, and nx1 matrices are coerced into each other in various ways and with Scalarmatrixp=True (the default), a 1x1 matrix is converted to a scalar: [1,2] . matrix([3],[4]) => 11 [1,2] . matrix([3,4]) => 11 matrix([1,2]).matrix([3,4]) => 11 matrix([1],[2]).matrix([3],[4]) => 11 So perhaps 11 == [11] and [1,2] == matrix([1,2]) == matrix ([1],[2]) ? On the other hand, matrix([11]) by itself does not automatically simplify to 11 and 11[11]=>[0], not 0. Of course, outside the context of vector/matrix operations, lists, 1xn matrices, and nx1 matrices are completely distinct: after all, member(a,[a,b]) => true and member(a,matrix([a,b])) => false. Now consider symbolic expressions. You might think that a==b must be false if nonscalar(a) and scalar(b). But that's not true. If you declare(vec,nonscalar), then nonscalar (vec.vec) => True, though in fact the .product of two vectors is a scalar (nonscalar is a *syntactic* check for the presence of nonscalar objects within the expression tree). So it is wrong to assume that is(equal(vec1.vec2,0)) is false because nonscalar(vec1.vec2)=True and nonscalar(0)=False. This is not theoretical. I think it perfectly reasonable that a user might check whether q and r are perpendicular by checking is(equal(q.r,0)), where q and r are sometimes concrete vectors  in which case you might well get a valid True or False , sometimes symbols (in which case the answer should be Unknown, not False). There is another simple case that has nothing to do with vector/matrix semantics. To do bag comparisons correctly, you need to solve conjunctions: [x,x] =? [1,2] is equivalent to (x==1 and x==2), which is clearly false, but Is doesn't know it. Similarly for [x,1] =? [1,x+1]. Another limitation on the power of is/equal/bag: the compar subsystem is not currently terribly useful for vectors etc. For example, assume(equal(q,[a,b])), is(equal(q,[a,b+1])) => Unknown. I think there are several possible conclusions for all this: 1) Make Maxima more rigorous. Distinguish between lists, vectors, and 1xn matrices everywhere. Distinguish between scalars, 1vectors, and 1x1 matrices everywhere. In that case, the correct results for is/equal are much clearer. But pragmatism is one of the central characteristics of Maxima; there are certainly other systems which emphasize rigor, with its advantages and disadvantages. 2) Decide that is/equal/bag always refers to .product semantics (not list semantics and not + or * semantics): if two objects act the same in the context of a .product, then they are the same. 2ay) The result of is/equal depends on the various switches controlling vector/matrix operations. So if Scalarmatrixp and Listarith are true, then 1 == [1] == matrix([1]). 2by) Assume default settings for the various switches. 2xa) Consider an nlist, an nrow, and an ncolumn equal (with appropriate switches set), even though they don't act equally in all contexts. 2xb) Consider an nlist and an nrow equal, but not an n column. 3) Decide that is/equal/bag is true iff there is NO context in which the objects can be distinguished. This emphasizes the programmingtype aspect of Maxima over the mathematical aspect. But 'equal' is supposed to be about mathematical equality. After all, is/equal considers 1/2, 0.5, and 0.5b0 to be equal, even though 1/2 is an exact number and 0.5 and 0.5b0 are approximate. 3a) Assume that nonscalar *identifiers* (but not nonscalar expressions) are never equal to scalars. 3b) Do not take into account the nonscalar property of identifiers. 4) Maintain the current behavior, which gives Unknown for all the difficult cases. What I had started out trying to program was 2aa, but it was too messy (because when I started, I was also trying to take into account the behavior of + and *). Now that I've written out this design note, it seems like the two reasonable alternatives are 3a and 2ax (not sure whether 2aa or 2ab is better). But I suspect that in actual fact, I have already spent too much time on this, that no one but Robert will ever care, and that 4 is just fine....  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=884947&group_id=4933 
From: SourceForge.net <noreply@so...>  20061219 05:04:46

Bugs item #885795, was opened at 20040127 14:02 Message generated for change (Comment added) made by robert_dodier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=885795&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  Assume Group: None >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: f(i)==f(j) where i==j (is/equal fails) Initial Comment: As a shorthand in this note, I'll use a==b to mean is (equal(a,b)). assume(equal(i,j)) x[i] == x[j] => Unknown NO! f(i) == f(j) => Unknown NO! sin(i) == sin(j) => Unknown NO! sinh(i) == sinh(j) => True OK!!!! It turns out that it has to do with the Increasing property, even though of course that is completely irrelevant: declare(g,increasing) g(i) == g(j) => true OK Strangely, Decreasing doesn't work: declare(h,decreasing) h(i) == h(j) => Unknown ??? I guess that technically this is an enhancement request (Unknown is always a valid way to give up), but....  >Comment By: Robert Dodier (robert_dodier) Date: 20061218 22:04 Message: Logged In: YES user_id=501686 Originator: NO Fixed by r1.16 src/compar.lisp (by Barton Willis).  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=885795&group_id=4933 
From: SourceForge.net <noreply@so...>  20061219 05:03:50

Bugs item #902694, was opened at 20040223 06:58 Message generated for change (Comment added) made by robert_dodier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=902694&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: 5 Private: No Submitted By: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: equal(ind,ind) should be false; also und, NaN Initial Comment: is(ind=ind) => true OK, is/= is syntactic is(equal(ind,ind)) => true NO! is/equal should be semantic Unlike IEEE floating point, Maxima carefully distinguishes syntactic and semantic equality tests. Clearly everything, including ind / und / IEEE_NaN, is syntactically equal to itself. However, not everything is semantically equal to itself. In particular, equal(und,und), equal(ind,ind), and equal(IEEE_NaN, IEEE_NaN) (when we support it) should be false.  >Comment By: Robert Dodier (robert_dodier) Date: 20061218 22:03 Message: Logged In: YES user_id=501686 Originator: NO Fixed by r1.16 src/compar.lisp (by Barton Willis).  Comment By: Robert Dodier (robert_dodier) Date: 20060723 12:54 Message: Logged In: YES user_id=501686 Observed in 5.9.3cvs. Incidentally I'm not convinced these are errors. A useful definition of Maxima equal(a,b) is that substituting a for b in any expression yields an equivalent expression. Certainly when a and b are the same symbol, that's true. To forestall two criticisms which I can see coming: (1) ratsimp(a  b) = 0 might be suggested as an alternate definition of equal(a,b). That's too narrow, as there are interesting expressions for which a  b isn't defined. E.g. a is a set and b is a matrix. (2) equal(a,a) => true for all symbols a isn't consistent with IEEE floating point. Well, I've given up on IEEE floating point special values in Maxima because Common Lisp doesn't require them, and some implementations (Clisp, GCL at least) don't support them.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=902694&group_id=4933 
From: SourceForge.net <noreply@so...>  20061219 05:02:12

Bugs item #990924, was opened at 20040714 09:04 Message generated for change (Comment added) made by robert_dodier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=990924&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: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: is(equal(...)) takes sign(%i) Initial Comment: Sometimes is(equal(...)) fails with the message that SIGN was called on an imaginary argument. This happens on Maxima version: 5.9.0 Maxima build date: 19:20 6/28/2004 host type: i686pclinuxgnu lispimplementationtype: CMU Common Lisp lispimplementationversion: 18e but I have seen it with a later CMUCL snapshot, too. Smallest example I can find: (C1) prederror: false $ (C2) is(equal((%E^(%I*z)%E^(%I*z)), 0)); SIGN called on an imaginary argument: %I  an error. Quitting. To debug this try DEBUGMODE(TRUE);) Albert Reiner, <areiner@...>.  >Comment By: Robert Dodier (robert_dodier) Date: 20061218 22:02 Message: Logged In: YES user_id=501686 Originator: NO Fixed by r1.16 src/compar.lisp (by Barton Willis).  Comment By: Robert Dodier (robert_dodier) Date: 20060730 20:48 Message: Logged In: YES user_id=501686 Observed in 5.9.3cvs.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=990924&group_id=4933 
From: SourceForge.net <noreply@so...>  20061219 04:53:33

Bugs item #1435600, was opened at 20060220 19:24 Message generated for change (Settings changed) made by robert_dodier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1435600&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: 8 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: equal function Initial Comment: is(equal(true,true)) will return true is(equal(false,false)) will return false but is(equal(true,false) or is(equal(false,true)) will give a bug ... syntax error. Why not provide a k_delta function like in Macsymas? e.g. k_delta(true,false) returns false k_delta(true,true) returns true k_delta(1,1) returns 1 k_delta(1,0) returns 0 HuenYK v 5.9.1 Maxima Comment: there are some good features in Maxima especially on Random(n). Macsymas only give a ceiling of n = 10^8.  Comment By: Robert Dodier (robert_dodier) Date: 20060814 21:18 Message: Logged In: YES user_id=501686 Boosting the priority of this one. It's really obnoxious.  Comment By: Nobody/Anonymous (nobody) Date: 20060312 23:43 Message: Logged In: NO The problem is that at present Maxima attempts to decide all equal (and notequal) comparisons as if the arguments were comparable numbers. This policy fails with errors of different sorts when the arguments are incomparable (e.g., boolean, complex, or matrices). MEQP in src/compar.lisp calls COMPARE (numerical comparison) if LIKE (structural comparison) fails; it should instead call COMPARE only if the arguments are comparable. I can't see a good way to determine comparability. Probably it is OK to assume comparability if incomparability can't be established. Even this weak policy is problematic, due to the weakness of the assume / declare database system. It seems we should be able to let comparable = not featurep(x, real) or maybe featurep(x, nonscalar) or maybe testing for various domains featurep(x, complex) or featurep(x, boolean) or .... but various problems immediately crop up, e.g., featurep(matrix([1, 2]), nonscalar) => false, featurep(matrix([1, 2]), real) => true, no builtin boolean property (and therefore true and false aren't boolean), featurep(1 + %i, nonscalar) => false, (declare (foo, nonscalar), featurep (foo(x), nonscalar)) => false, etc etc. Robert Dodier  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1435600&group_id=4933 
From: SourceForge.net <noreply@so...>  20061219 04:51:35

Bugs item #1489164, was opened at 20060515 16:25 Message generated for change (Comment added) made by robert_dodier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1489164&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: 8 Private: No Submitted By: Barton Willis (willisbl) Assigned to: Nobody/Anonymous (nobody) Summary: is(equal(%i,0)) Initial Comment: (%i9) is(equal(%i,0)); `sign' called on an imaginary argument: (%i10) is(equal(und,0)); `sign' called on `und'. I claim that both of these should evaluate to false. It seems that equal should call csign, not $sign. Barton  >Comment By: Robert Dodier (robert_dodier) Date: 20061218 21:51 Message: Logged In: YES user_id=501686 Originator: NO Fixed by r1.16 src/compar.lisp (by Barton Willis).  Comment By: Nobody/Anonymous (nobody) Date: 20061008 21:16 Message: Logged In: NO Well, two complex numbers are equal if and only if their real and imaginary parts are equal. That is "a + ib = c + id" if and only if "a = c" and "b = d" If the complex number is in the polar form, they are equal if and only if they have the same magnitude and direction, that is "a*%e^(%i*b) = c*%e^(%i*d)" if and only if "a = c" and "b = d" Generally speaking, any two vectors are equal if and only if they are equal in its components. That is [x[1],x[2],x[3],...,x[n]] = [y[1],y[2],y[3],...y[m]] only when "n = m" and "x[i]=y[i]" for all 'i' between 1 and n Otherwise, they are not equal I hope this can help to improve Maxima Mario/Mexico  Comment By: Robert Dodier (robert_dodier) Date: 20060826 13:31 Message: Logged In: YES user_id=501686 Increase priority. This is a serious hindrance.  Comment By: Robert Dodier (robert_dodier) Date: 20060604 23:05 Message: Logged In: YES user_id=501686 Fix title of this item (equla > equal).  Comment By: Robert Dodier (robert_dodier) Date: 20060515 18:09 Message: Logged In: YES user_id=501686 Agreed, these are bugs, and these should both yield false.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1489164&group_id=4933 
From: SourceForge.net <noreply@so...>  20061219 04:50:46

Bugs item #1496329, was opened at 20060528 04:17 Message generated for change (Comment added) made by robert_dodier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1496329&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: 8 Private: No Submitted By: Barton Willis (willisbl) Assigned to: Nobody/Anonymous (nobody) Summary: is(equal(CRE matrix, ...) Initial Comment: See also bug 1495041. (%i1) equal(rat(matrix([x])),matrix([x])); (%o1) equal(matrix([x]),matrix([x])) (%i2) is(%); Maxima encountered a Lisp error: Error in AND [or a callee]: Caught fatal error With a typo, Maxima gives an Lisp error: (%i3) equal(rat(matrix([x])),matirx([x])); (%o3) equal(matrix([x]),matirx([x])) (%i4) is(%); Maxima encountered a Lisp error: Error in INFSIMP [or a callee]: #:X33554 is not of type LIST. This bug seems to require that one argument is a CRE matrix: (%i5) equal(rat(f(x)),f(x)); (%o5) equal(f(x),f(x)) (%i6) is(%); (%o6) true Barton  >Comment By: Robert Dodier (robert_dodier) Date: 20061218 21:50 Message: Logged In: YES user_id=501686 Originator: NO Fixed by r1.16 src/compar.lisp (by Barton Willis).  Comment By: Robert Dodier (robert_dodier) Date: 20060826 13:54 Message: Logged In: YES user_id=501686 Increasing priority.  Comment By: Robert Dodier (robert_dodier) Date: 20060605 20:09 Message: Logged In: YES user_id=501686 Here is a related example that appeared on the mailing list. is (equal (ident (2), rat (ident (2)))); => CAR: 1 is not a list (Maxima 5.9.3 / Clisp 2.34) => Error in PROGN [or a callee]: Caught fatal error [memory may be damaged] (Maxima 5.9.3 / GCL 2.6.7)  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1496329&group_id=4933 
From: SourceForge.net <noreply@so...>  20061219 04:49:53

Bugs item #1547584, was opened at 20060827 14:23 Message generated for change (Comment added) made by robert_dodier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1547584&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: 5 Private: No Submitted By: Barton Willis (willisbl) Assigned to: Nobody/Anonymous (nobody) Summary: is(equal([a],[a,b]) Initial Comment: is(equal([a],[a,b])) signals an error (from fullmap). That's not right. It should evaluate to false. Barton  >Comment By: Robert Dodier (robert_dodier) Date: 20061218 21:49 Message: Logged In: YES user_id=501686 Originator: NO Fixed by r1.16 src/compar.lisp (by Barton Willis).  Comment By: Barton Willis (willisbl) Date: 20060827 14:30 Message: Logged In: YES user_id=895922 Another problem with is(equal(...)): assume(equal(a,aa)); is(equal(f(a), f(aa)) > error or unknown depending on prederror (should be true), is(equal(a < b, [a,b]) > error or unknown depending on prederror (should be false) and ....  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1547584&group_id=4933 
From: SourceForge.net <noreply@so...>  20061219 03:20:06

Bugs item #1605159, was opened at 20061129 02:54 Message generated for change (Comment added) made by sfrobot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1605159&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  Plotting Group: None >Status: Closed Resolution: Fixed Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Plotting constant functions works only when they're 2^z Initial Comment: Hi Maximateam, I have the problem that I'm unable to insert constant functions into a plot. Maxima will do calculations forever and hangs (using CPU power). I found out that _some_ constant functions are indeed plotted but only those that have the form 2^z. So for example you can plot y=0.5, y=1, y=2 or y=0.03125. Things don't work are y=0.4 or y=0.028 This is in all revisions I tested so far including the recent 5.10. HTH, Phil  >Comment By: SourceForge Robot (sfrobot) Date: 20061218 19:20 Message: Logged In: YES user_id=1312539 Originator: NO 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: Robert Dodier (robert_dodier) Date: 20061203 21:36 Message: Logged In: YES user_id=501686 Originator: NO Not observed in Maxima 5.10.0cvs w/ GCL, SBCL, and Clisp. Marking this report as pending (so it will be closed automatically in 2 weeks, in case Phil comes back) since it seems to be fixed, and it is a duplicate of bug report 1571454: plot2d(0.99,[x,0,5]) is very slow.  Comment By: Raymond Toy (rtoy) Date: 20061129 09:49 Message: Logged In: YES user_id=28849 Originator: NO This was caused by the adaptive plotter. This is fixed in CVS, I think. Can you try that out?  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1605159&group_id=4933 