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}
(17) 
_{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...>  20061221 14:29:21

Bugs item #1620165, was opened at 20061221 06:29 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=1620165&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: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Strange error Initial Comment: The following maxima code alphas=[]; alpha(n):=assoc(n,alphas); alpha(5); gives the error ======================================================== Maxima encountered a Lisp error: Error in PROGN [or a callee]: Caught fatal error [memory may be damaged] Automatically continuing. ======================================================== On the other hand assoc(5,[]); returns false (as it should). ==================================================== This is the banner of maxima Maxima 5.9.3 http://maxima.sourceforge.net Using Lisp GNU Common Lisp (GCL) GCL 2.6.7 (aka GCL)  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1620165&group_id=4933 
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 
From: SourceForge.net <noreply@so...>  20061218 03:36:56

Bugs item #1617688, was opened at 20061217 22:36 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=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  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1617688&group_id=4933 
From: SourceForge.net <noreply@so...>  20061216 07:34:28

Bugs item #1616873, was opened at 20061215 23:34 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=1616873&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: Installation Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Spelling error in windows installation Initial Comment: In the "Select Component" in the Windows installer there are the options "Full installation", "Compact installation" and "Custom istalation". The last one has two spelling errors in the same word.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1616873&group_id=4933 
From: SourceForge.net <noreply@so...>  20061215 11:02:01

Bugs item #1614821, was opened at 20061213 14:21 Message generated for change (Comment added) made by andrejv You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1614821&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  Solving equations Group: None >Status: Closed Resolution: None Priority: 5 Private: No Submitted By: Germel (gzintel) Assigned to: Nobody/Anonymous (nobody) Summary: solver.mac still not working as expected Initial Comment: I tried to solve the following equation in version 5.10.99rc1 without success. This is working in verion 5.9.1 and gives a correct result. Here are the iput lines:  snip  /* some initializing stuff */ EquationP(e):=if part(e,0)="=" then true else false$ load("solver/solver"); load("solver/misc"); /* Defining the equations */ Equations: [ p12=T11*p11+T12*u11+T13*p21+T14*u21, u12=T21*p11+T22*u11+T23*p21+T24*u21, p22=T31*p11+T32*u11+T33*p21+T34*u21, u22=T41*p11+T42*u11+T43*p21+T44*u21, p21=p11, Zo=p11/(u21+u11) ]$ /* Defining the parameters remaining in the result */ Parameters: [T11,T12,T13,T14,T21,T22,T23,T24,T31,T32,T33,T34,T41,T42,T43,T44,Zo,p22,u22]$ /* Solving the equations with respect to parameters */ Solver(Equations,[p12,u12],Parameters)$ /* Factorizing the result so that p22 and u22 are the main factors */ facsum(%[1],p22,u22)$ /* finding a more compact representation */ disolate(%,p22,u22);  snip  The results from version 5.9.1 are: (%t6) 1/(T33 T44 Zo + T31 T44 Zo  T34 T43 Zo + T32 T43 Zo  T33 T42 Zo  T31 T42 Zo  T34 T41 Zo + T32 T41 Zo + T32 T44  T34 T42) (%t7) T13 T34 Zo + T11 T34 Zo  T14 T33 Zo + T12 T33 Zo  T13 T32 Zo  T11 T32 Zo  T14 T31 Zo + T12 T31 Zo + T12 T34  T14 T32 (%t8) T13 T44 Zo + T11 T44 Zo  T14 T43 Zo + T12 T43 Zo  T13 T42 Zo  T11 T42 Zo  T14 T41 Zo + T12 T41 Zo + T12 T44  T14 T42 (%t9) T23 T34 Zo + T21 T34 Zo  T24 T33 Zo + T22 T33 Zo  T23 T32 Zo  T21 T32 Zo  T24 T31 Zo + T22 T31 Zo + T22 T34  T24 T32 (%t10) T23 T44 Zo + T21 T44 Zo  T24 T43 Zo + T22 T43 Zo  T23 T42 Zo  T21 T42 Zo  T24 T41 Zo + T22 T41 Zo + T22 T44  T24 T42 (%o10) [p12 = %t6 (%t8 p22  %t7 u22), u12 = %t6 (%t10 p22  %t9 u22)]  The result from version 5.10.99rc1 is a "Division by 0" error in lines: linsolve.mac line 39 solver.mac line 1312 solver.mac line 500  PS: to make it work in 5.9.1 I had to correct the solver.mac script. I changed the following lines: load( "solver/linsolve.mac" )$ load( "solver/slvrtbox.mac" )$ load( "solver/slvrmsgs.mac" )$ This fix is already done in version 5.10.99rc1 PS2: Thank you for this great program Thank you for reading Gerhard  >Comment By: Andrej Vodopivec (andrejv) Date: 20061215 12:01 Message: Logged In: YES user_id=1179910 Originator: NO This has been fixed in cvs. The cvs version of solver.mac returns the same result as in 5.9.1. Andrej  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1614821&group_id=4933 
From: SourceForge.net <noreply@so...>  20061213 13:21:05

Bugs item #1614821, was opened at 20061213 13:21 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=1614821&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  Solving equations Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Germel (gzintel) Assigned to: Nobody/Anonymous (nobody) Summary: solver.mac still not working as expected Initial Comment: I tried to solve the following equation in version 5.10.99rc1 without success. This is working in verion 5.9.1 and gives a correct result. Here are the iput lines:  snip  /* some initializing stuff */ EquationP(e):=if part(e,0)="=" then true else false$ load("solver/solver"); load("solver/misc"); /* Defining the equations */ Equations: [ p12=T11*p11+T12*u11+T13*p21+T14*u21, u12=T21*p11+T22*u11+T23*p21+T24*u21, p22=T31*p11+T32*u11+T33*p21+T34*u21, u22=T41*p11+T42*u11+T43*p21+T44*u21, p21=p11, Zo=p11/(u21+u11) ]$ /* Defining the parameters remaining in the result */ Parameters: [T11,T12,T13,T14,T21,T22,T23,T24,T31,T32,T33,T34,T41,T42,T43,T44,Zo,p22,u22]$ /* Solving the equations with respect to parameters */ Solver(Equations,[p12,u12],Parameters)$ /* Factorizing the result so that p22 and u22 are the main factors */ facsum(%[1],p22,u22)$ /* finding a more compact representation */ disolate(%,p22,u22);  snip  The results from version 5.9.1 are: (%t6) 1/(T33 T44 Zo + T31 T44 Zo  T34 T43 Zo + T32 T43 Zo  T33 T42 Zo  T31 T42 Zo  T34 T41 Zo + T32 T41 Zo + T32 T44  T34 T42) (%t7) T13 T34 Zo + T11 T34 Zo  T14 T33 Zo + T12 T33 Zo  T13 T32 Zo  T11 T32 Zo  T14 T31 Zo + T12 T31 Zo + T12 T34  T14 T32 (%t8) T13 T44 Zo + T11 T44 Zo  T14 T43 Zo + T12 T43 Zo  T13 T42 Zo  T11 T42 Zo  T14 T41 Zo + T12 T41 Zo + T12 T44  T14 T42 (%t9) T23 T34 Zo + T21 T34 Zo  T24 T33 Zo + T22 T33 Zo  T23 T32 Zo  T21 T32 Zo  T24 T31 Zo + T22 T31 Zo + T22 T34  T24 T32 (%t10) T23 T44 Zo + T21 T44 Zo  T24 T43 Zo + T22 T43 Zo  T23 T42 Zo  T21 T42 Zo  T24 T41 Zo + T22 T41 Zo + T22 T44  T24 T42 (%o10) [p12 = %t6 (%t8 p22  %t7 u22), u12 = %t6 (%t10 p22  %t9 u22)]  The result from version 5.10.99rc1 is a "Division by 0" error in lines: linsolve.mac line 39 solver.mac line 1312 solver.mac line 500  PS: to make it work in 5.9.1 I had to correct the solver.mac script. I changed the following lines: load( "solver/linsolve.mac" )$ load( "solver/slvrtbox.mac" )$ load( "solver/slvrmsgs.mac" )$ This fix is already done in version 5.10.99rc1 PS2: Thank you for this great program Thank you for reading Gerhard  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1614821&group_id=4933 
From: SourceForge.net <noreply@so...>  20061211 18:18:39

Bugs item #1607567, was opened at 20061202 16:49 Message generated for change (Comment added) made by macrakis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1607567&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  Trigonometry Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: trigreduce([atan(sin(a)/cos(a))]) => [ atan(tan(a)) ] (FIX) Initial Comment: trigexpand( [ atan(sin(a)/cos(a)) ] ) => atan(tan(a)) (UNSIMPLIFIED!) whereas trigexpand( atan(sin(a)/cos(a)) ) => a and atan(tan(a)) => a Though the simplification atan(tan(a))=> is questionable (it needs to do reduction), it is weird that putting the argument to trigexpand in a list changes the behavior.  >Comment By: Stavros Macrakis (macrakis) Date: 20061211 13:18 Message: Logged In: YES user_id=588346 Originator: YES Here is an example of one handled by the new and not the old code: trigreduce([sin(x)^2]) => [ (22*cos(2*x))/4 ] WRONG => [ (1cos(2*x))/2 ] Fixed Also, leaving the bag unsimplified is more correct in general, though it doesn't currently matter. It will matter if (for example) sets get added to mbagp.  Comment By: Raymond Toy (rtoy) Date: 20061211 12:45 Message: Logged In: YES user_id=28849 Originator: NO I'm applying your fix. Could you send some examples where your original fix didn't work. I'd like them for regression tests.  Comment By: Stavros Macrakis (macrakis) Date: 20061210 15:17 Message: Logged In: YES user_id=588346 Originator: YES Actually, my suggested fix only works in some cases. Better would be the following: BEFORE: ((mbagp e) (cons (car e) (mapcar #'sp1 (cdr e)))) AFTER: ((mbagp e) (cons (list (caar e)) (mapcar #'(lambda (u) (gcdred (sp1 u))) (cdr e)))))) Note two things here: any "simp" flags on the bag are dropped (so this will work if bags come to include sets some day) and gcdred is applied as in the top level of $trigreduce. Sorry I didn't get it right the first time.  Comment By: Raymond Toy (rtoy) Date: 20061208 21:13 Message: Logged In: YES user_id=28849 Originator: NO This change works for me. I get a and [a] for results. I'll apply the fix soon.  Comment By: Stavros Macrakis (macrakis) Date: 20061208 14:31 Message: Logged In: YES user_id=588346 Originator: YES The problem is that sp1 isn't handling simplification quite right. The result is ((MLIST SIMP) ((%ATAN) ((%TAN SIMP) $A))) The %ATAN doesn't have a SIMP flag, though it is within a SIMP expression. The fix is simple. In trgred.lisp, function sp1: BEFORE: ((mbagp e) (cons (car e) (mapcar #'sp1 (cdr e)))) AFTER: ((mbagp e) (cons (car e) (mapcar #'(lambda (q) (simplifya (sp1 q))) (cdr e)))) Interestingly, trigreduce doesn't go inside unknown functions at all, e.g. trigreduce( f(sin(x)/cos(x)) ) doesn't do anything at all. I wonder if there is a good reason for this?  Comment By: Raymond Toy (rtoy) Date: 20061208 13:15 Message: Logged In: YES user_id=28849 Originator: NO With current CVS, the example with sin(x)^2 gives the same results whether it's a list or not. Also, if you :lisp (trace $trigreduce), you can see that trigreduce([atan(sin(a)/cos(a))]) returns [atan(tan(a))] and trigreduce(atan(sin(a)/cos(a)) returns atan(tan(a)). Something after trigreduce returns causes the simplification to happen. Perhaps in meval or something?  Comment By: Stavros Macrakis (macrakis) Date: 20061204 12:40 Message: Logged In: YES user_id=588346 Originator: YES Other simplifications also don't happen: trigreduce( sin(x)^2 ) => (1 cos(2*x))/2 (OK) trigreduce([sin(x)^2]) => [ (22*cos(2*x))/4 ] (?)  Comment By: Stavros Macrakis (macrakis) Date: 20061204 12:30 Message: Logged In: YES user_id=588346 Originator: YES Sorry, it's trigreduce in Maxima 5.10.0 GCL 2.6.8 Windows2k Athlon trigreduce(atan(sin(a)/cos(a))) => a trigreduce([atan(sin(a)/cos(a))]) => [atan(tan(a))] PS I should always cut and paste rather than retyping....  Comment By: Raymond Toy (rtoy) Date: 20061204 11:49 Message: Logged In: YES user_id=28849 Originator: NO What version? With 5.10.0 and cmucl, trigexpand([atan(sin(a)/cos(a))]) => [atan(sin(a)/cos(a))] Corresponding result if the arg is not a list.  Comment By: Stavros Macrakis (macrakis) Date: 20061202 16:53 Message: Logged In: YES user_id=588346 Originator: YES Oops, it's actually trigexpand( [ atan(sin(a)/cos(a)) ] ) => [ atan(tan(a)) ] (UNSIMPLIFIED!) It doesn't simplify atan of tan, but it does preserve the list...  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1607567&group_id=4933 
From: SourceForge.net <noreply@so...>  20061211 18:17:55

Bugs item #1613390, was opened at 20061211 10:17 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=1613390&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: Share Libraries Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: find_root evaluates its arguments strangely Initial Comment: Someone asked a question on the mailing list about using the output of solve to do numerical root finding. we found that you could not use the output of solve directly in find_root because it evaluates its first argument strangely. Instead it required explicit evaluation with the '' operator. This behavior is very confusing even for relatively advanced maxima users, but especially for new users. example of the problem below: Transcript Maxima 5.10.0 http://maxima.sourceforge.net Using Lisp GNU Common Lisp (GCL) GCL 2.6.7 (aka GCL) (%i1) h1(s):=1/(1+tau[1]*s); h2(s):=1/(1+tau[2]*s); x(s):=1/s; tau[1]:33e6; tau[2]:33e6; eqn:first(solve(ilt(h1(s)*h2(s)*x(s),s,t)=0.1,t)); 1 (%o1) h1(s) :=  1 + tau s 1 (%i2) 1 (%o2) h2(s) :=  1 + tau s 2 (%i3) 1 (%o3) x(s) :=  s (%i4) (%o4) 3.2999999999999996E5 (%i5) (%o5) 3.2999999999999996E5 (%i6) `rat' replaced 3.2999999999999996E5 by 33//1000000 = 3.3000000000000003E5 `rat' replaced 0.9 by 9//10 = 0.9 1000000 t  33 297 %e  330 (%o6) t =  10000000 (%i7) find_root(%,t,0,2); Maxima encountered a Lisp error: Error in MACSYMATOPLEVEL [or a callee]: ((MEQUAL SIMP) $T ((MTIMES SIMP) ((RAT SIMP) 1 10000000) ((MPLUS SIMP) 330 ((MTIMES SIMP) 297 ((MEXPT SIMP) $%E ((MTIMES SIMP) ((RAT SIMP) 1000000 33) $T)))))) is not of type (OR RATIONAL LISP:FLOAT).  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1613390&group_id=4933 
From: SourceForge.net <noreply@so...>  20061211 17:45:51

Bugs item #1607567, was opened at 20061202 16:49 Message generated for change (Comment added) made by rtoy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1607567&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  Trigonometry Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: trigreduce([atan(sin(a)/cos(a))]) => [ atan(tan(a)) ] (FIX) Initial Comment: trigexpand( [ atan(sin(a)/cos(a)) ] ) => atan(tan(a)) (UNSIMPLIFIED!) whereas trigexpand( atan(sin(a)/cos(a)) ) => a and atan(tan(a)) => a Though the simplification atan(tan(a))=> is questionable (it needs to do reduction), it is weird that putting the argument to trigexpand in a list changes the behavior.  >Comment By: Raymond Toy (rtoy) Date: 20061211 12:45 Message: Logged In: YES user_id=28849 Originator: NO I'm applying your fix. Could you send some examples where your original fix didn't work. I'd like them for regression tests.  Comment By: Stavros Macrakis (macrakis) Date: 20061210 15:17 Message: Logged In: YES user_id=588346 Originator: YES Actually, my suggested fix only works in some cases. Better would be the following: BEFORE: ((mbagp e) (cons (car e) (mapcar #'sp1 (cdr e)))) AFTER: ((mbagp e) (cons (list (caar e)) (mapcar #'(lambda (u) (gcdred (sp1 u))) (cdr e)))))) Note two things here: any "simp" flags on the bag are dropped (so this will work if bags come to include sets some day) and gcdred is applied as in the top level of $trigreduce. Sorry I didn't get it right the first time.  Comment By: Raymond Toy (rtoy) Date: 20061208 21:13 Message: Logged In: YES user_id=28849 Originator: NO This change works for me. I get a and [a] for results. I'll apply the fix soon.  Comment By: Stavros Macrakis (macrakis) Date: 20061208 14:31 Message: Logged In: YES user_id=588346 Originator: YES The problem is that sp1 isn't handling simplification quite right. The result is ((MLIST SIMP) ((%ATAN) ((%TAN SIMP) $A))) The %ATAN doesn't have a SIMP flag, though it is within a SIMP expression. The fix is simple. In trgred.lisp, function sp1: BEFORE: ((mbagp e) (cons (car e) (mapcar #'sp1 (cdr e)))) AFTER: ((mbagp e) (cons (car e) (mapcar #'(lambda (q) (simplifya (sp1 q))) (cdr e)))) Interestingly, trigreduce doesn't go inside unknown functions at all, e.g. trigreduce( f(sin(x)/cos(x)) ) doesn't do anything at all. I wonder if there is a good reason for this?  Comment By: Raymond Toy (rtoy) Date: 20061208 13:15 Message: Logged In: YES user_id=28849 Originator: NO With current CVS, the example with sin(x)^2 gives the same results whether it's a list or not. Also, if you :lisp (trace $trigreduce), you can see that trigreduce([atan(sin(a)/cos(a))]) returns [atan(tan(a))] and trigreduce(atan(sin(a)/cos(a)) returns atan(tan(a)). Something after trigreduce returns causes the simplification to happen. Perhaps in meval or something?  Comment By: Stavros Macrakis (macrakis) Date: 20061204 12:40 Message: Logged In: YES user_id=588346 Originator: YES Other simplifications also don't happen: trigreduce( sin(x)^2 ) => (1 cos(2*x))/2 (OK) trigreduce([sin(x)^2]) => [ (22*cos(2*x))/4 ] (?)  Comment By: Stavros Macrakis (macrakis) Date: 20061204 12:30 Message: Logged In: YES user_id=588346 Originator: YES Sorry, it's trigreduce in Maxima 5.10.0 GCL 2.6.8 Windows2k Athlon trigreduce(atan(sin(a)/cos(a))) => a trigreduce([atan(sin(a)/cos(a))]) => [atan(tan(a))] PS I should always cut and paste rather than retyping....  Comment By: Raymond Toy (rtoy) Date: 20061204 11:49 Message: Logged In: YES user_id=28849 Originator: NO What version? With 5.10.0 and cmucl, trigexpand([atan(sin(a)/cos(a))]) => [atan(sin(a)/cos(a))] Corresponding result if the arg is not a list.  Comment By: Stavros Macrakis (macrakis) Date: 20061202 16:53 Message: Logged In: YES user_id=588346 Originator: YES Oops, it's actually trigexpand( [ atan(sin(a)/cos(a)) ] ) => [ atan(tan(a)) ] (UNSIMPLIFIED!) It doesn't simplify atan of tan, but it does preserve the list...  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1607567&group_id=4933 
From: SourceForge.net <noreply@so...>  20061210 20:17:54

Bugs item #1607567, was opened at 20061202 16:49 Message generated for change (Comment added) made by macrakis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1607567&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  Trigonometry Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: trigreduce([atan(sin(a)/cos(a))]) => [ atan(tan(a)) ] (FIX) Initial Comment: trigexpand( [ atan(sin(a)/cos(a)) ] ) => atan(tan(a)) (UNSIMPLIFIED!) whereas trigexpand( atan(sin(a)/cos(a)) ) => a and atan(tan(a)) => a Though the simplification atan(tan(a))=> is questionable (it needs to do reduction), it is weird that putting the argument to trigexpand in a list changes the behavior.  >Comment By: Stavros Macrakis (macrakis) Date: 20061210 15:17 Message: Logged In: YES user_id=588346 Originator: YES Actually, my suggested fix only works in some cases. Better would be the following: BEFORE: ((mbagp e) (cons (car e) (mapcar #'sp1 (cdr e)))) AFTER: ((mbagp e) (cons (list (caar e)) (mapcar #'(lambda (u) (gcdred (sp1 u))) (cdr e)))))) Note two things here: any "simp" flags on the bag are dropped (so this will work if bags come to include sets some day) and gcdred is applied as in the top level of $trigreduce. Sorry I didn't get it right the first time.  Comment By: Raymond Toy (rtoy) Date: 20061208 21:13 Message: Logged In: YES user_id=28849 Originator: NO This change works for me. I get a and [a] for results. I'll apply the fix soon.  Comment By: Stavros Macrakis (macrakis) Date: 20061208 14:31 Message: Logged In: YES user_id=588346 Originator: YES The problem is that sp1 isn't handling simplification quite right. The result is ((MLIST SIMP) ((%ATAN) ((%TAN SIMP) $A))) The %ATAN doesn't have a SIMP flag, though it is within a SIMP expression. The fix is simple. In trgred.lisp, function sp1: BEFORE: ((mbagp e) (cons (car e) (mapcar #'sp1 (cdr e)))) AFTER: ((mbagp e) (cons (car e) (mapcar #'(lambda (q) (simplifya (sp1 q))) (cdr e)))) Interestingly, trigreduce doesn't go inside unknown functions at all, e.g. trigreduce( f(sin(x)/cos(x)) ) doesn't do anything at all. I wonder if there is a good reason for this?  Comment By: Raymond Toy (rtoy) Date: 20061208 13:15 Message: Logged In: YES user_id=28849 Originator: NO With current CVS, the example with sin(x)^2 gives the same results whether it's a list or not. Also, if you :lisp (trace $trigreduce), you can see that trigreduce([atan(sin(a)/cos(a))]) returns [atan(tan(a))] and trigreduce(atan(sin(a)/cos(a)) returns atan(tan(a)). Something after trigreduce returns causes the simplification to happen. Perhaps in meval or something?  Comment By: Stavros Macrakis (macrakis) Date: 20061204 12:40 Message: Logged In: YES user_id=588346 Originator: YES Other simplifications also don't happen: trigreduce( sin(x)^2 ) => (1 cos(2*x))/2 (OK) trigreduce([sin(x)^2]) => [ (22*cos(2*x))/4 ] (?)  Comment By: Stavros Macrakis (macrakis) Date: 20061204 12:30 Message: Logged In: YES user_id=588346 Originator: YES Sorry, it's trigreduce in Maxima 5.10.0 GCL 2.6.8 Windows2k Athlon trigreduce(atan(sin(a)/cos(a))) => a trigreduce([atan(sin(a)/cos(a))]) => [atan(tan(a))] PS I should always cut and paste rather than retyping....  Comment By: Raymond Toy (rtoy) Date: 20061204 11:49 Message: Logged In: YES user_id=28849 Originator: NO What version? With 5.10.0 and cmucl, trigexpand([atan(sin(a)/cos(a))]) => [atan(sin(a)/cos(a))] Corresponding result if the arg is not a list.  Comment By: Stavros Macrakis (macrakis) Date: 20061202 16:53 Message: Logged In: YES user_id=588346 Originator: YES Oops, it's actually trigexpand( [ atan(sin(a)/cos(a)) ] ) => [ atan(tan(a)) ] (UNSIMPLIFIED!) It doesn't simplify atan of tan, but it does preserve the list...  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1607567&group_id=4933 
From: SourceForge.net <noreply@so...>  20061210 12:19:53

Bugs item #1556627, was opened at 20060911 15:07 Message generated for change (Comment added) made by willisbl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1556627&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  Solving equations Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Barton Willis (willisbl) Assigned to: Nobody/Anonymous (nobody) Summary: solve & sign called on imaginary Initial Comment: This example is ridiculous, but this error shouldn't happen: x^1616*x^15+120*x^14560*x^13+1800*x^124128*x^11+6688*x^107040*x^9+2304*x^8+9728*x^729120*x^6+48768*x^558560*x^4+56576* x^343008*x^2+20992*x4544=0 (%i165) solve(%,x); `sign' called on an imaginary argument: sqrt(125*sqrt(6)) Barton  >Comment By: Barton Willis (willisbl) Date: 20061210 06:19 Message: Logged In: YES user_id=895922 Originator: YES I'm guessing that I had algebraic : true. Then: (%i1) x^1616*x^15+120*x^14560*x^13+1800*x^124128*x^11+6688*x^107040*x^9+2304*x^8+9728*x^7 29120*x^6+48768*x^558560*x^4+56576* x^343008*x^2+20992*x4544=0$ (%i2) solve(%i1,x), algebraic : true; `sign' called on an imaginary argument: sqrt(125*sqrt(6))  an error. Quitting. To debug this try debugmode(true); (%i3) solve(%i1,x), algebraic : false; (%o3) [x=1sqrt(sqrt(4*6^(1/4)*sqrt(52*sqrt(6))*%i6*sqrt(6)+5)), < deleted> Maxima version: 5.10.0 Maxima build date: 17:18 10/24/2006 host type: i686pcmingw32 lispimplementationtype: GNU Common Lisp (GCL) lispimplementationversion: GCL 2.6.8  Comment By: Robert Dodier (robert_dodier) Date: 20061210 00:09 Message: Logged In: YES user_id=501686 Originator: NO I don't see this error. I get the following from solve(%, x). [x = 1sqrt(sqrt(4*6^(1/4)*sqrt(52*sqrt(6))*%i6*sqrt(6)+5)), x = sqrt(sqrt(4*6^(1/4)*sqrt(52*sqrt(6))*%i6*sqrt(6)+5))+1, x = 1(4*6^(1/4)*sqrt(52*sqrt(6))*%i6*sqrt(6)+5)^(1/4), x = (4*6^(1/4)*sqrt(52*sqrt(6))*%i6*sqrt(6)+5)^(1/4)+1, x = 1sqrt(sqrt(4*6^(1/4)*sqrt(52*sqrt(6))*%i6*sqrt(6)+5)), x = sqrt(sqrt(4*6^(1/4)*sqrt(52*sqrt(6))*%i6*sqrt(6)+5))+1, x = 1(4*6^(1/4)*sqrt(52*sqrt(6))*%i6*sqrt(6)+5)^(1/4), x = (4*6^(1/4)*sqrt(52*sqrt(6))*%i6*sqrt(6)+5)^(1/4)+1, x = 1(4*6^(1/4)*sqrt(2*sqrt(6)+5)+6*sqrt(6)+5)^(1/4)*%i, x = (4*6^(1/4)*sqrt(2*sqrt(6)+5)+6*sqrt(6)+5)^(1/4)*%i+1, x = 1(4*6^(1/4)*sqrt(2*sqrt(6)+5)+6*sqrt(6)+5)^(1/4), x = (4*6^(1/4)*sqrt(2*sqrt(6)+5)+6*sqrt(6)+5)^(1/4)+1, x = 1(4*6^(1/4)*sqrt(2*sqrt(6)+5)+6*sqrt(6)+5)^(1/4)*%i, x = (4*6^(1/4)*sqrt(2*sqrt(6)+5)+6*sqrt(6)+5)^(1/4)*%i+1, x = 1(4*6^(1/4)*sqrt(2*sqrt(6)+5)+6*sqrt(6)+5)^(1/4), x = (4*6^(1/4)*sqrt(2*sqrt(6)+5)+6*sqrt(6)+5)^(1/4)+1]$ Above result is from Clisp: Maxima version: 5.10.0cvs Maxima build date: 23:10 11/30/2006 host type: i686pclinuxgnu lispimplementationtype: CLISP lispimplementationversion: 2.38 (20060124) (built 3355931855) (memory 3373942297) I believe I get the same thing from SBCL (looks similar). Maxima version: 5.10.0cvs Maxima build date: 23:9 12/5/2006 host type: i686pclinuxgnu lispimplementationtype: SBCL lispimplementationversion: 1.0  Comment By: Nobody/Anonymous (nobody) Date: 20061118 10:09 Message: Logged In: NO On my copy of wxMaxima, it didn't show any error!  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1556627&group_id=4933 
From: SourceForge.net <noreply@so...>  20061210 08:08:02

Bugs item #1612391, was opened at 20061210 01:00 Message generated for change (Comment added) made by andrejv You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1612391&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: Xmaxima or other UI Group: None >Status: Closed Resolution: None Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Andrej Vodopivec (andrejv) Summary: wxmaxima inchar fails Initial Comment: inchar:"c"; returns an error outchar:"d"; is OK both are OK with xmaxima frm@...  >Comment By: Andrej Vodopivec (andrejv) Date: 20061210 09:08 Message: Logged In: YES user_id=1179910 Originator: NO The inchar can not be changed in wxmaxima. wxmaxima expects inchar to be %i and would not work properly if it was changed to something else. Andrej  Comment By: Robert Dodier (robert_dodier) Date: 20061210 07:27 Message: Logged In: YES user_id=501686 Originator: NO Andrej, I've assigned this item to you. Is this a bug in Maxima or in WxMaxima ? If it is not in Maxima, please make a note here and close this report.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1612391&group_id=4933 
From: SourceForge.net <noreply@so...>  20061210 06:50:40

Bugs item #1612489, was opened at 20061209 23:50 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=1612489&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  Simplification Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Robert Dodier (robert_dodier) Assigned to: Nobody/Anonymous (nobody) Summary: quoted nested nary expressions flattened incompletely Initial Comment: Quoted (unevaluated) nested nary expressions are flattened incompletely. Evaluated nested nary expressions appear to be flattened completely. Completely flattened: nary ("aa"); declare ("aa", nary); a aa (b aa (c aa (d aa (e aa (f aa g))))); => a aa b aa c aa d aa e aa f aa g Incompletely flattened: '(a aa (b aa (c aa (d aa (e aa (f aa g)))))); => a aa b aa (c aa d aa (e aa f aa g)) When the operator has the properties OPERS and $NARY, then NARY1 is called to flatten. Plus, times, and nctimes (maybe others) aren't affected by this because flattening for those operators is handled by their simplification functions, not NARY1. It would be nice to use this mechanism (OPERS + $NARY + NARY1) to flatten MAND and MOR. (This will become more of an issue when unevaluated boolean expressions are in use.)  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1612489&group_id=4933 