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}
(32) 
_{Dec}

S  M  T  W  T  F  S 





1

2

3
(2) 
4

5

6

7
(1) 
8
(3) 
9

10
(1) 
11
(4) 
12
(4) 
13
(1) 
14

15
(1) 
16

17

18

19

20
(1) 
21
(4) 
22
(5) 
23
(1) 
24

25

26
(2) 
27
(4) 
28
(4) 
29
(3) 
30
(6) 
31
(1) 
From: SourceForge.net <noreply@so...>  20040122 00:41:47

Bugs item #881461, was opened at 20040121 10:49 Message generated for change (Comment added) made by ronis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=881461&group_id=4933 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: David Ronis (ronis) Assigned to: Nobody/Anonymous (nobody) Summary: make install fails on maxima CVS Initial Comment: I've been folowing maxima via CVS for years. Recently, something has broken; maxima builds and the testsuite runs fine. However make install dies with: Making install in src make[1]: Entering directory `/home/ronis/Project/notar/maxima/src' make[2]: Entering directory `/home/ronis/Project/notar/maxima/src' /bin/sh ../mkinstalldirs /usr/local/bin /bin/install c maxima /usr/local/bin/maxima /bin/sh ../mkinstalldirs "/usr/local/lib/maxima/5.9.0.1cvs/binaryclisp" /bin/install c m 644 binaryclisp/maxima.mem "/usr/local/lib/maxima/5.9.0.1cvs/binaryclisp/maxima.mem" /bin/install c "/usr/local/lib/maxima/5.9.0.1cvs/binaryclisp/lisp.run" /bin/install: too few arguments Try `/bin/install help' for more information. make[2]: *** [installclisp] Error 1 make[2]: Leaving directory `/home/ronis/Project/notar/maxima/src' make[1]: *** [installam] Error 2 make[1]: Leaving directory `/home/ronis/Project/notar/maxima/src' make: *** [installrecursive] Error 1 It looks like configure hasn't found my clisp installation. I'm running slakware9.1  >Comment By: David Ronis (ronis) Date: 20040121 19:41 Message: Logged In: YES user_id=609364 I figured out the problem. It seems that when you don't pass configure the enableclisp flag, it doesn't initialize the clisp_runtime library (even though it does autodetect clisp). Sounds like a bug, but perhaps not; this was not the behavior in slightly older CVS's. In any event, a comment in the INSTALL file would be in order if this is not a bug.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=881461&group_id=4933 
From: SourceForge.net <noreply@so...>  20040121 23:18:26

Bugs item #880767, was opened at 20040120 10:32 Message generated for change (Comment added) made by nobody You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=880767&group_id=4933 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: can't plot 1/0, but won't stop trying... Initial Comment: plot2d(1/x,[x,1,1]); The foregoing sends maxima into an infinite loop. Also, simply typing y=1e999; causes an overflow error, requiring a restart. Is it supposed to be this fragile? system is windows XP quiasmox@...  Comment By: Nobody/Anonymous (nobody) Date: 20040121 07:03 Message: Logged In: NO The version was 5.5. Today I downloaded 5.9, and I don't know what happened, because I downloaded the 5.5 just Monday this week. In any case, the version 5.9 doesn't show the business about y=1e999. I put in y=1e10000, and it dutifully printed 10000 zeroes on the screen. I suppose I need to read the documentation about formatting. There is still a problem with plotting, though. I tried plot2d(x,[x,1,1]); and plot2d(x/1000,[x,1,1]); they both plot instantaneously. However, plot2d(x/0.001,[x,1,1]); took 55 seconds to plot. This is on the windows version 5.9 of maxima, just downloaded and installed today, 1/21/04. John  Comment By: Raymond Toy (rtoy) Date: 20040120 17:20 Message: Logged In: YES user_id=28849 What version of maxima? This doesn't happen in the CVS version of maxima, which has adaptive plotting.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=880767&group_id=4933 
From: SourceForge.net <noreply@so...>  20040121 15:49:58

Bugs item #881461, was opened at 20040121 10:49 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=881461&group_id=4933 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: David Ronis (ronis) Assigned to: Nobody/Anonymous (nobody) Summary: make install fails on maxima CVS Initial Comment: I've been folowing maxima via CVS for years. Recently, something has broken; maxima builds and the testsuite runs fine. However make install dies with: Making install in src make[1]: Entering directory `/home/ronis/Project/notar/maxima/src' make[2]: Entering directory `/home/ronis/Project/notar/maxima/src' /bin/sh ../mkinstalldirs /usr/local/bin /bin/install c maxima /usr/local/bin/maxima /bin/sh ../mkinstalldirs "/usr/local/lib/maxima/5.9.0.1cvs/binaryclisp" /bin/install c m 644 binaryclisp/maxima.mem "/usr/local/lib/maxima/5.9.0.1cvs/binaryclisp/maxima.mem" /bin/install c "/usr/local/lib/maxima/5.9.0.1cvs/binaryclisp/lisp.run" /bin/install: too few arguments Try `/bin/install help' for more information. make[2]: *** [installclisp] Error 1 make[2]: Leaving directory `/home/ronis/Project/notar/maxima/src' make[1]: *** [installam] Error 2 make[1]: Leaving directory `/home/ronis/Project/notar/maxima/src' make: *** [installrecursive] Error 1 It looks like configure hasn't found my clisp installation. I'm running slakware9.1  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=881461&group_id=4933 
From: SourceForge.net <noreply@so...>  20040121 02:11:46

Bugs item #857232, was opened at 20031209 18:23 Message generated for change (Comment added) made by rtoy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=857232&group_id=4933 Category: Lisp Core Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Robert Dodier (robert_dodier) Assigned to: Nobody/Anonymous (nobody) Summary: plot.lisp defines $norm, incorrectly Initial Comment: plot.lisp (current cvs) has "(defun $norm...)" in it. So if you do "NORM([1,2,3]);" that's what you get. There are 2 problems: (1) this function computes the sum of the elements squared (not the square root of the sum). (2) this function works only on lists containing numeric values  fails if argument is [a,b,c] for example. $norm is not called anywhere else in the Lisp source, nor is it called anywhere in the Maxima source. As defined, it is OK for its purpose within plot.lisp. But let's not confuse the user. How about if we just change $norm to plot_norm2, in the two places in plot.lisp where $norm occurs? Norm functions should be defined in the vector code somewhere, but that's another problem.  >Comment By: Raymond Toy (rtoy) Date: 20040120 21:11 Message: Logged In: YES user_id=28849 Done. Also changed $get_rotation and $cross_product, which weren't used anywhere.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=857232&group_id=4933 
From: SourceForge.net <noreply@so...>  20040121 01:20:04

Bugs item #880767, was opened at 20040120 13:32 Message generated for change (Comment added) made by rtoy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=880767&group_id=4933 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: can't plot 1/0, but won't stop trying... Initial Comment: plot2d(1/x,[x,1,1]); The foregoing sends maxima into an infinite loop. Also, simply typing y=1e999; causes an overflow error, requiring a restart. Is it supposed to be this fragile? system is windows XP quiasmox@...  >Comment By: Raymond Toy (rtoy) Date: 20040120 20:20 Message: Logged In: YES user_id=28849 What version of maxima? This doesn't happen in the CVS version of maxima, which has adaptive plotting.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=880767&group_id=4933 
From: SourceForge.net <noreply@so...>  20040120 18:32:26

Bugs item #880767, was opened at 20040120 10:32 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=880767&group_id=4933 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: can't plot 1/0, but won't stop trying... Initial Comment: plot2d(1/x,[x,1,1]); The foregoing sends maxima into an infinite loop. Also, simply typing y=1e999; causes an overflow error, requiring a restart. Is it supposed to be this fragile? system is windows XP quiasmox@...  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=880767&group_id=4933 
From: SourceForge.net <noreply@so...>  20040115 18:07:12

Bugs item #877719, was opened at 20040115 12:07 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=877719&group_id=4933 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Barton Willis (willisbl) Assigned to: Nobody/Anonymous (nobody) Summary: integrate and assume Initial Comment: This is okay: (C1) integrate(exp(a*x),x,0,inf); Is a positive, negative, or zero? pos; Integral is divergent The assumption on "a" is local  (C2) is(a > 0); MACSYMA was unable to evaluate the predicate: But integrate remembers the assumption on "a." I think this is a bad feature: (C3) integrate(exp(a*x),x,0,inf); Integral is divergent Wait! Look what happends if we trace ?assume. It seems that integrate forgets the assumption on "a" and once again asks for the sign of "a." (C4) trace(?assume)$ (C5) integrate(exp(a*x),x,0,inf); 1 Enter ?ASSUME [*Z* > 0] 1 Exit ?ASSUME *Z* > 0 ... (stuff deleted) Is a positive, negative, or zero? neg; 1 Enter ?ASSUME [x > 0] 1 Exit ?ASSUME x > 0 1 Enter ?ASSUME [x > 0] 1 Exit ?ASSUME x > 0 1 Enter ?ASSUME [INF > x] ...(stuff deleted) (D5) 1/a Is this a bug with gcl's trace? (C8) build_info(); Maxima version: 5.9.0 Maxima build date: 19:10 2/9/2003 host type: i686pcmingw32 lispimplementationtype: Kyoto Common Lisp lispimplementationversion: GCL25.0 Barton  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=877719&group_id=4933 
From: SourceForge.net <noreply@so...>  20040113 18:41:31

Bugs item #876274, was opened at 20040113 11:41 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=876274&group_id=4933 Category: Lisp Core Group: None Status: Open Resolution: None Priority: 5 Submitted By: Robert Dodier (robert_dodier) Assigned to: Nobody/Anonymous (nobody) Summary: TRANSLATE_FILE emits obsolete code for hashed arrays Initial Comment: TRANSLATE_FILE emits code containing MASET calls for assigning values to hashed array elements. LOADFILE barfs on attempting to load the code so translated. To judge from trace output, it appears that ARRSTORE should be called to store hashed array elements. Indeed, replacing MASET calls with ARRSTORE calls yields a file which can be loaded successfully by LOADFILE:  tmp.mac  a[foo]:11111; a[bar]:22222; a[baz]:33333;  end   TRANSLATE_FILE output: LOADFILE barfs !!  (MASET 11111 $a (TRDMSYMEVAL $foo '$foo)) (MASET 22222 $a (TRDMSYMEVAL $bar '$bar)) (MASET 33333 $a (TRDMSYMEVAL $baz '$baz))  end   patched with ARRSTORE calls: LOADFILE happy  (ARRSTORE '(($a SIMP ARRAY) $foo) 11111) (ARRSTORE '(($a SIMP ARRAY) $bar) 22222) (ARRSTORE '(($a SIMP ARRAY) $baz) 33333)  end   Maxima session  (C1) LOADFILE("tmp.LISPpatched")$ (C2) ARRAYINFO(a); (D2) [HASHED,1,[bar],[baz],[foo]] (C3) LISTARRAY(a); (D3) [22222,33333,11111]  end   You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=876274&group_id=4933 
From: SourceForge.net <noreply@so...>  20040112 21:30:24

Bugs item #873244, was opened at 20040108 13:15 Message generated for change (Comment added) made by willisbl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=873244&group_id=4933 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: limit(x=0,x,0) wrong Initial Comment: limit(x=0,x,0) => 0=0. limit(equal(x,0),x,0) => equal(x,0) Let's leave aside the fact that 0=0 could simplify to True  that is not a limit issue, but a broader issue in Maxima. The real problem is that limit(x=0,x,0) is in fact FALSE, not TRUE. Since x=0 is FALSE for all x#0, it is FALSE in particular for all 0<x<epsilon. Presumably the problem here is that Limit is assuming that "=" is a continuous function of its arguments. On the other hand, limit is *too* careful with other relationals: limit(x>0,x,0,plus) => noun limit(x>=0,x,0,plus) => noun These could perfectly well return TRUE. But that is a feature request, not a bug.  >Comment By: Barton Willis (willisbl) Date: 20040112 15:30 Message: Logged In: YES user_id=895922 The idom "Take the <limit, derivative, cube, ...> of both sides" is uttered a few thousand times per hour; for that reason, I think mapping limit, diff, and cube over an equality is sensible (not always correct, but GIGO) If, as you suggest (x = x) == true we'd also have to live with diff(x = x,x) > diff(true,x) > huh? I doubt this is what most users expect or want. Polemics aside, Maxima is lackadiasical about mapping functions over mbags. This needs to be cleaned up and (as you and I have discusssed) too much (possibly all) Maxima code assumes that the result of mapping a function over an mbag doesn't need simplification. That's another story. Barton  Comment By: Stavros Macrakis (macrakis) Date: 20040112 13:42 Message: Logged In: YES user_id=588346 Whether 0=0 should simplify to true is a side issue. I don't follow your argument about 0=0 representing the set of all numbers. ANY true statement represents the universal set (if you believe in that), whether it is {x  0=0} or {x  true} or {x  Socrates is mortal}. Note by the way that there is nothing telling you the domain. 0=0 could equally well represent the set of all determinant1 matrices or all the 5th degree polynomials over Z7, if that's the domain of x's you are manipulating.  Comment By: Wolfgang Jenkner (wjenkner) Date: 20040112 13:42 Message: Logged In: YES user_id=581700 > The real problem is that limit(x=0,x,0) is in fact FALSE, > not TRUE. Since x=0 is FALSE for all x#0, it is FALSE in > particular for all 0<x<epsilon. Do you mean that in some punctured neighbourhood of 0, is(limit(x=0,x,0)) == is(0=0) == TRUE, limit(is(x=0),x,0) == limit(FALSE,x,0) == FALSE But this just shows that IS and LIMIT don't commute and, in particular, that IS(? = 0) is not continuous at 0. But... where is Maxima wrong?  Comment By: Stavros Macrakis (macrakis) Date: 20040112 13:37 Message: Logged In: YES user_id=588346 But mapping limit over an *equation* (not a generic mbag) is in general wrong if you consider an equation to be a boolean valued object. Remember, limit is defined for epsilon > 0, not epsilon >= 0. Limit(x=0,x,0) really is false, since x=0 is false for all abs(x)>0. On the other hand, limit(sin(x)=sin(x),x,inf) is true, even though limit(sin(x),x,inf) is ind, and in general ind does not equal ind (like NaN). And limit(x=x^2,x,inf) is false, even though limit(x,x,inf)=limit(x^2,x,inf)=inf.  Comment By: Barton Willis (willisbl) Date: 20040111 15:12 Message: Logged In: YES user_id=895922 I think mapping limit over an mbag is sensible and consistent with much of Maxima. 0 = 0 could reasonally simplify to true, but it could just as well represent the set of all real (or complex) numbers. [ If 0 = 0, then 0 x = 0; the solution set of 0 x = 0 is everything.] I think Maxima shouldn't simplify 0 = 0 to true or anything else. Barton  Comment By: Barton Willis (willisbl) Date: 20040111 15:11 Message: Logged In: YES user_id=895922 I think mapping limit over an mbag is sensible and consistent with much of Maxima. 0 = 0 could reasonally simplify to true, but it could just as well represent the set of all real (or complex) numbers. [ If 0 = 0, then 0 x = 0; the solution set of 0 x = 0 is everything.] I think Maxima shouldn't simplify 0 = 0 to true or anything else. Barton  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=873244&group_id=4933 
From: SourceForge.net <noreply@so...>  20040112 19:42:12

Bugs item #873244, was opened at 20040108 14:15 Message generated for change (Comment added) made by macrakis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=873244&group_id=4933 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: limit(x=0,x,0) wrong Initial Comment: limit(x=0,x,0) => 0=0. limit(equal(x,0),x,0) => equal(x,0) Let's leave aside the fact that 0=0 could simplify to True  that is not a limit issue, but a broader issue in Maxima. The real problem is that limit(x=0,x,0) is in fact FALSE, not TRUE. Since x=0 is FALSE for all x#0, it is FALSE in particular for all 0<x<epsilon. Presumably the problem here is that Limit is assuming that "=" is a continuous function of its arguments. On the other hand, limit is *too* careful with other relationals: limit(x>0,x,0,plus) => noun limit(x>=0,x,0,plus) => noun These could perfectly well return TRUE. But that is a feature request, not a bug.  >Comment By: Stavros Macrakis (macrakis) Date: 20040112 14:42 Message: Logged In: YES user_id=588346 Whether 0=0 should simplify to true is a side issue. I don't follow your argument about 0=0 representing the set of all numbers. ANY true statement represents the universal set (if you believe in that), whether it is {x  0=0} or {x  true} or {x  Socrates is mortal}. Note by the way that there is nothing telling you the domain. 0=0 could equally well represent the set of all determinant1 matrices or all the 5th degree polynomials over Z7, if that's the domain of x's you are manipulating.  Comment By: Wolfgang Jenkner (wjenkner) Date: 20040112 14:42 Message: Logged In: YES user_id=581700 > The real problem is that limit(x=0,x,0) is in fact FALSE, > not TRUE. Since x=0 is FALSE for all x#0, it is FALSE in > particular for all 0<x<epsilon. Do you mean that in some punctured neighbourhood of 0, is(limit(x=0,x,0)) == is(0=0) == TRUE, limit(is(x=0),x,0) == limit(FALSE,x,0) == FALSE But this just shows that IS and LIMIT don't commute and, in particular, that IS(? = 0) is not continuous at 0. But... where is Maxima wrong?  Comment By: Stavros Macrakis (macrakis) Date: 20040112 14:37 Message: Logged In: YES user_id=588346 But mapping limit over an *equation* (not a generic mbag) is in general wrong if you consider an equation to be a boolean valued object. Remember, limit is defined for epsilon > 0, not epsilon >= 0. Limit(x=0,x,0) really is false, since x=0 is false for all abs(x)>0. On the other hand, limit(sin(x)=sin(x),x,inf) is true, even though limit(sin(x),x,inf) is ind, and in general ind does not equal ind (like NaN). And limit(x=x^2,x,inf) is false, even though limit(x,x,inf)=limit(x^2,x,inf)=inf.  Comment By: Barton Willis (willisbl) Date: 20040111 16:12 Message: Logged In: YES user_id=895922 I think mapping limit over an mbag is sensible and consistent with much of Maxima. 0 = 0 could reasonally simplify to true, but it could just as well represent the set of all real (or complex) numbers. [ If 0 = 0, then 0 x = 0; the solution set of 0 x = 0 is everything.] I think Maxima shouldn't simplify 0 = 0 to true or anything else. Barton  Comment By: Barton Willis (willisbl) Date: 20040111 16:11 Message: Logged In: YES user_id=895922 I think mapping limit over an mbag is sensible and consistent with much of Maxima. 0 = 0 could reasonally simplify to true, but it could just as well represent the set of all real (or complex) numbers. [ If 0 = 0, then 0 x = 0; the solution set of 0 x = 0 is everything.] I think Maxima shouldn't simplify 0 = 0 to true or anything else. Barton  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=873244&group_id=4933 
From: SourceForge.net <noreply@so...>  20040112 19:42:06

Bugs item #873244, was opened at 20040108 20:15 Message generated for change (Comment added) made by wjenkner You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=873244&group_id=4933 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: limit(x=0,x,0) wrong Initial Comment: limit(x=0,x,0) => 0=0. limit(equal(x,0),x,0) => equal(x,0) Let's leave aside the fact that 0=0 could simplify to True  that is not a limit issue, but a broader issue in Maxima. The real problem is that limit(x=0,x,0) is in fact FALSE, not TRUE. Since x=0 is FALSE for all x#0, it is FALSE in particular for all 0<x<epsilon. Presumably the problem here is that Limit is assuming that "=" is a continuous function of its arguments. On the other hand, limit is *too* careful with other relationals: limit(x>0,x,0,plus) => noun limit(x>=0,x,0,plus) => noun These could perfectly well return TRUE. But that is a feature request, not a bug.  >Comment By: Wolfgang Jenkner (wjenkner) Date: 20040112 20:42 Message: Logged In: YES user_id=581700 > The real problem is that limit(x=0,x,0) is in fact FALSE, > not TRUE. Since x=0 is FALSE for all x#0, it is FALSE in > particular for all 0<x<epsilon. Do you mean that in some punctured neighbourhood of 0, is(limit(x=0,x,0)) == is(0=0) == TRUE, limit(is(x=0),x,0) == limit(FALSE,x,0) == FALSE But this just shows that IS and LIMIT don't commute and, in particular, that IS(? = 0) is not continuous at 0. But... where is Maxima wrong?  Comment By: Stavros Macrakis (macrakis) Date: 20040112 20:37 Message: Logged In: YES user_id=588346 But mapping limit over an *equation* (not a generic mbag) is in general wrong if you consider an equation to be a boolean valued object. Remember, limit is defined for epsilon > 0, not epsilon >= 0. Limit(x=0,x,0) really is false, since x=0 is false for all abs(x)>0. On the other hand, limit(sin(x)=sin(x),x,inf) is true, even though limit(sin(x),x,inf) is ind, and in general ind does not equal ind (like NaN). And limit(x=x^2,x,inf) is false, even though limit(x,x,inf)=limit(x^2,x,inf)=inf.  Comment By: Barton Willis (willisbl) Date: 20040111 22:12 Message: Logged In: YES user_id=895922 I think mapping limit over an mbag is sensible and consistent with much of Maxima. 0 = 0 could reasonally simplify to true, but it could just as well represent the set of all real (or complex) numbers. [ If 0 = 0, then 0 x = 0; the solution set of 0 x = 0 is everything.] I think Maxima shouldn't simplify 0 = 0 to true or anything else. Barton  Comment By: Barton Willis (willisbl) Date: 20040111 22:11 Message: Logged In: YES user_id=895922 I think mapping limit over an mbag is sensible and consistent with much of Maxima. 0 = 0 could reasonally simplify to true, but it could just as well represent the set of all real (or complex) numbers. [ If 0 = 0, then 0 x = 0; the solution set of 0 x = 0 is everything.] I think Maxima shouldn't simplify 0 = 0 to true or anything else. Barton  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=873244&group_id=4933 
From: SourceForge.net <noreply@so...>  20040112 19:37:40

Bugs item #873244, was opened at 20040108 14:15 Message generated for change (Comment added) made by macrakis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=873244&group_id=4933 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: limit(x=0,x,0) wrong Initial Comment: limit(x=0,x,0) => 0=0. limit(equal(x,0),x,0) => equal(x,0) Let's leave aside the fact that 0=0 could simplify to True  that is not a limit issue, but a broader issue in Maxima. The real problem is that limit(x=0,x,0) is in fact FALSE, not TRUE. Since x=0 is FALSE for all x#0, it is FALSE in particular for all 0<x<epsilon. Presumably the problem here is that Limit is assuming that "=" is a continuous function of its arguments. On the other hand, limit is *too* careful with other relationals: limit(x>0,x,0,plus) => noun limit(x>=0,x,0,plus) => noun These could perfectly well return TRUE. But that is a feature request, not a bug.  >Comment By: Stavros Macrakis (macrakis) Date: 20040112 14:37 Message: Logged In: YES user_id=588346 But mapping limit over an *equation* (not a generic mbag) is in general wrong if you consider an equation to be a boolean valued object. Remember, limit is defined for epsilon > 0, not epsilon >= 0. Limit(x=0,x,0) really is false, since x=0 is false for all abs(x)>0. On the other hand, limit(sin(x)=sin(x),x,inf) is true, even though limit(sin(x),x,inf) is ind, and in general ind does not equal ind (like NaN). And limit(x=x^2,x,inf) is false, even though limit(x,x,inf)=limit(x^2,x,inf)=inf.  Comment By: Barton Willis (willisbl) Date: 20040111 16:12 Message: Logged In: YES user_id=895922 I think mapping limit over an mbag is sensible and consistent with much of Maxima. 0 = 0 could reasonally simplify to true, but it could just as well represent the set of all real (or complex) numbers. [ If 0 = 0, then 0 x = 0; the solution set of 0 x = 0 is everything.] I think Maxima shouldn't simplify 0 = 0 to true or anything else. Barton  Comment By: Barton Willis (willisbl) Date: 20040111 16:11 Message: Logged In: YES user_id=895922 I think mapping limit over an mbag is sensible and consistent with much of Maxima. 0 = 0 could reasonally simplify to true, but it could just as well represent the set of all real (or complex) numbers. [ If 0 = 0, then 0 x = 0; the solution set of 0 x = 0 is everything.] I think Maxima shouldn't simplify 0 = 0 to true or anything else. Barton  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=873244&group_id=4933 
From: SourceForge.net <noreply@so...>  20040111 21:43:24

Bugs item #875102, was opened at 20040111 15:43 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=875102&group_id=4933 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Barton Willis (willisbl) Assigned to: Nobody/Anonymous (nobody) Summary: integrands involving false Initial Comment: When ?defint isn't able to find the value of a definite integral, it returns false, and it's the job of $defint to return a correct noun form. Maxima allows false to be used as an identifer  this allows $defint to get mixed up; for example (C1) defint(false,x,0,1); (D1) 'INTEGRATE(FALSE,x,0,1) (C2) defint(false,x,0,2); (D2) 2*FALSE (C3) build_info(); Maxima version: 5.9.0 Maxima build date: 19:10 2/9/2003 host type: i686pcmingw32 lispimplementationtype: Kyoto Common Lisp lispimplementationversion: GCL25.0 This bug may not be worth fixing; it might be better to disallow true, false, und, ... to be used this way. Barton  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=875102&group_id=4933 
From: SourceForge.net <noreply@so...>  20040111 21:36:13

Bugs item #875089, was opened at 20040111 15: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=875089&group_id=4933 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Barton Willis (willisbl) Assigned to: Nobody/Anonymous (nobody) Summary: defint(f(x)=g(x),x,0,1) > false = false Initial Comment: (C1) defint(f(x)=g(x),x,0,1); (D1) FALSE = FALSE Here is proposed fix (DEFUN $DEFINT (EXP VAR LL UL) (let ((globaldefintassumptions ()) (integerinfo ()) (integerl integerl) (nonintegerl nonintegerl)) (withnewcontext (context) (unwindprotect (let ((defintassumptions ()) (*def2* ()) (rad polyrecur ()) (sincosrecur ()) (dintexprecur ()) (dintlogrecur 0.) (ans nil) (origexp exp) (origvar var) (origll ll) (origul ul) (pcprntd nil) (*NODIVerg nil) ($logabs t) (limitp t) (rppolylogp ()) ($domain '$real) ($m1pbranch ())) ;Try this out. (FINDFUNCTION '$LIMIT) (makeglobalassumptions) ;sets global defintassumptions (FINDFUNCTION '$RESIDUE) (SETQ EXP (RATDISREP EXP)) (SETQ VAR (RATDISREP VAR)) (SETQ LL (RATDISREP LL)) (SETQ UL (RATDISREP UL)) (COND (($CONSTANTP VAR) (merror "Variable of integration not a variable: ~M" VAR)) (($SUBVARP VAR) (SETQ VAR (STRIPDOLLAR (CAAR VAR))) (SETQ EXP ($SUBSTITUTE VAR orig VAR EXP)))) (COND ((NOT (ATOM VAR)) (merror "Improper variable of integration: ~M" VAR)) ((OR (AMONG VAR UL) (AMONG VAR LL)) (SETQ VAR (STRIPDOLLAR VAR)) (SETQ EXP ($SUBSTITUTE VAR orig VAR EXP)))) (cond ((not (equal ($ratsimp ($imagpart ll)) 0)) (merror "Defint: Lower limit of integration must be real")) ((not (equal ($ratsimp ($imagpart ul)) 0)) (merror "Defint: Upper limit of integration must be real"))) ;; fix starts here (COND ((mbagp exp) (simplify `((,(mop exp)) ,@(mapcar #'(lambda (e) ($defint e var ll ul)) (margs exp))))) ;; fix ends here ((SETQ ANS (DEFINT EXP VAR LL UL)) (SETQ ANS (SUBST origVAR VAR ANS)) (COND ((atom ans) ans) ((and (free ans '%limit) (free ans '%integrate) (OR (not (free ans '$INF)) (not (free ans '$MINF)) (not (free ans '$INFINITY)))) (diverg)) ((not (free ans '$und)) `((%integrate) ,orig exp ,origvar ,origll ,origul)) (t ANS))) (t `((%integrate) ,origexp ,orig var ,origll ,origul)))) (forgetglobalassumptions)))))  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=875089&group_id=4933 
From: SourceForge.net <noreply@so...>  20040111 21:12:03

Bugs item #873244, was opened at 20040108 13:15 Message generated for change (Comment added) made by willisbl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=873244&group_id=4933 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: limit(x=0,x,0) wrong Initial Comment: limit(x=0,x,0) => 0=0. limit(equal(x,0),x,0) => equal(x,0) Let's leave aside the fact that 0=0 could simplify to True  that is not a limit issue, but a broader issue in Maxima. The real problem is that limit(x=0,x,0) is in fact FALSE, not TRUE. Since x=0 is FALSE for all x#0, it is FALSE in particular for all 0<x<epsilon. Presumably the problem here is that Limit is assuming that "=" is a continuous function of its arguments. On the other hand, limit is *too* careful with other relationals: limit(x>0,x,0,plus) => noun limit(x>=0,x,0,plus) => noun These could perfectly well return TRUE. But that is a feature request, not a bug.  >Comment By: Barton Willis (willisbl) Date: 20040111 15:12 Message: Logged In: YES user_id=895922 I think mapping limit over an mbag is sensible and consistent with much of Maxima. 0 = 0 could reasonally simplify to true, but it could just as well represent the set of all real (or complex) numbers. [ If 0 = 0, then 0 x = 0; the solution set of 0 x = 0 is everything.] I think Maxima shouldn't simplify 0 = 0 to true or anything else. Barton  Comment By: Barton Willis (willisbl) Date: 20040111 15:11 Message: Logged In: YES user_id=895922 I think mapping limit over an mbag is sensible and consistent with much of Maxima. 0 = 0 could reasonally simplify to true, but it could just as well represent the set of all real (or complex) numbers. [ If 0 = 0, then 0 x = 0; the solution set of 0 x = 0 is everything.] I think Maxima shouldn't simplify 0 = 0 to true or anything else. Barton  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=873244&group_id=4933 
From: SourceForge.net <noreply@so...>  20040111 21:11:25

Bugs item #873244, was opened at 20040108 13:15 Message generated for change (Comment added) made by willisbl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=873244&group_id=4933 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: limit(x=0,x,0) wrong Initial Comment: limit(x=0,x,0) => 0=0. limit(equal(x,0),x,0) => equal(x,0) Let's leave aside the fact that 0=0 could simplify to True  that is not a limit issue, but a broader issue in Maxima. The real problem is that limit(x=0,x,0) is in fact FALSE, not TRUE. Since x=0 is FALSE for all x#0, it is FALSE in particular for all 0<x<epsilon. Presumably the problem here is that Limit is assuming that "=" is a continuous function of its arguments. On the other hand, limit is *too* careful with other relationals: limit(x>0,x,0,plus) => noun limit(x>=0,x,0,plus) => noun These could perfectly well return TRUE. But that is a feature request, not a bug.  >Comment By: Barton Willis (willisbl) Date: 20040111 15:11 Message: Logged In: YES user_id=895922 I think mapping limit over an mbag is sensible and consistent with much of Maxima. 0 = 0 could reasonally simplify to true, but it could just as well represent the set of all real (or complex) numbers. [ If 0 = 0, then 0 x = 0; the solution set of 0 x = 0 is everything.] I think Maxima shouldn't simplify 0 = 0 to true or anything else. Barton  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=873244&group_id=4933 
From: SourceForge.net <noreply@so...>  20040110 09:33:07

Bugs item #874337, was opened at 20040110 01:33 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=874337&group_id=4933 Category: Xmaxima Group: Fix for 5.9.0 Status: Open Resolution: None Priority: 5 Submitted By: Brian P. Wilfley (bwilfley) Assigned to: Nobody/Anonymous (nobody) Summary: read prompt string appears "late" Initial Comment: In the Windows version of Xmaxima, the "read" function misbehaves: the prompt string appears _after_ the user types a value for read to return. The program below: test():=( print("program to test character output in Windows"), f:read("enter a string"), print("f = ",f) )$ produces the following results: (C3) test(); program to test character output in Windows teststring;enter a string f = teststring (D3) teststring Note that the response typed by the user is "teststring;". But the prompt: "enter a string" appears after the response has been typed. This bug affects all packages that prompt the user for input, such as ENTERMATRIX.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=874337&group_id=4933 
From: SourceForge.net <noreply@so...>  20040108 20:39:37

Bugs item #873301, was opened at 20040108 15:39 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=873301&group_id=4933 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: Gradef doesn't understand diff (workaround) Initial Comment: Suppose that f(x)=exp(g(x)). Then f'(x)=f(x)*g'(x). So how do we define this using gradef? Let's try the obvious solution: gradef( f(x), f(x) * diff(g(x),x) ) Now diff(f(x^2),x) => f(x1)*'DIFF(g(x1),x1,1) Oops! That isn't right! It is substituting x1 for x in the *second* argument of diff as well as the first! So we have to work around this doing something like gradef( f(x), f(x) * g1(x) ) gradef( g(x), g1(x) )  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=873301&group_id=4933 
From: SourceForge.net <noreply@so...>  20040108 19:59:03

Bugs item #866706, was opened at 20031228 12:00 Message generated for change (Comment added) made by macrakis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=866706&group_id=4933 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: ('m)[1] (meval) Initial Comment: ('m)[1] currently returns m(1). It should return m[1].  >Comment By: Stavros Macrakis (macrakis) Date: 20040108 14:59 Message: Logged In: YES user_id=588346 Peculiarly, (m)[1] => m[1]  actually parses as m[1] (1,'m)[1] => m[1] (0+'m)[1] => m[1]  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=866706&group_id=4933 
From: SourceForge.net <noreply@so...>  20040108 19:15:49

Bugs item #873244, was opened at 20040108 14:15 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=873244&group_id=4933 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: limit(x=0,x,0) wrong Initial Comment: limit(x=0,x,0) => 0=0. limit(equal(x,0),x,0) => equal(x,0) Let's leave aside the fact that 0=0 could simplify to True  that is not a limit issue, but a broader issue in Maxima. The real problem is that limit(x=0,x,0) is in fact FALSE, not TRUE. Since x=0 is FALSE for all x#0, it is FALSE in particular for all 0<x<epsilon. Presumably the problem here is that Limit is assuming that "=" is a continuous function of its arguments. On the other hand, limit is *too* careful with other relationals: limit(x>0,x,0,plus) => noun limit(x>=0,x,0,plus) => noun These could perfectly well return TRUE. But that is a feature request, not a bug.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=873244&group_id=4933 
From: SourceForge.net <noreply@so...>  20040107 15:00:21

Bugs item #872433, was opened at 20040107 09:00 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=872433&group_id=4933 Category: Share Libraries Group: None Status: Open Resolution: None Priority: 5 Submitted By: Barton Willis (willisbl) Assigned to: Nobody/Anonymous (nobody) Summary: rncombine broken Initial Comment: The function rncombine is broken. (C1) load("rncomb")$ Lines d2 and d3 are okay, but d4 is bogus (C2) rncombine(x+y/x); (D2) y/x+x (C3) rncombine(x+y/x); (D3) y/x+x (C4) rncombine(y+x/y); (D4) y+x (C5) build_info(); Maxima version: 5.9.0 Maxima build date: 19:10 2/9/2003 host type: i686pcmingw32 lispimplementationtype: Kyoto Common Lisp lispimplementationversion: GCL25.0 Notes: 1. The function rncombine is supposed to work like combine, except that it combines terms that have denominators that differ by a numerical factor. 2. When rncombine is fixed, either the function should autoload, or the user documentation should explain that one must first load rncomb.mac. Barton  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=872433&group_id=4933 
From: SourceForge.net <noreply@so...>  20040103 14:32:14

Bugs item #835287, was opened at 20031104 07:54 Message generated for change (Comment added) made by billingd You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=835287&group_id=4933 Category: None Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Barton Willis (willisbl) Assigned to: Nobody/Anonymous (nobody) Summary: solve('diff(y,x),'diff(y,x)) fails Initial Comment: (C1) solve('diff(y,x),'diff(y,x)); Error: #:G21849 is not of type LIST. Fast links are on: do (si::usefastlinks nil) for debugging Error signalled by MACSYMATOPLEVEL. Broken at MACSYMATOPLEVEL. Type :H for Help. MAXIMA>>:q This one is okay (C2)solve(x,x); (D2) [x = 0] (C3) build_info(); Maxima version: 5.9.0 Maxima build date: 19:10 2/9/2003 host type: i686pcmingw32 lispimplementationtype: Kyoto Common Lisp lispimplementationversion: GCL25.0 Barton  >Comment By: David Billinghurst (billingd) Date: 20040104 01:32 Message: Logged In: YES user_id=365569 Patch tested and commited. Also fixed bug 866510  Comment By: Barton Willis (willisbl) Date: 20031120 01:49 Message: Logged In: YES user_id=895922 This same bug appears with solve(x[1],x[1]). The error happens when the function easycases tries to caar an atom; for example (C1) trace(?easy\cases); (D1) [EASY CASES] (C2) solve(x[1],x[1]); 1 Enter ?EASY\CASES [G21847, G21847] Error: #:G21847 is not of type LIST. Fast links are on: do (si::usefastlinks nil) for debugging Error signalled by MACSYMATOPLEVEL. Broken at MACSYMATOPLEVEL. Type :H for Help. MAXIMA>> A fix is to check for an atom at the top of easycases; I don't think (car *exp) should ever be an atom, but I put in a check for that as well. Another thing: In easycases, I think ((EQ (CAAR *EXP) 'MEXP) should be ((EQ (CAAR *EXP) 'MEXPT)) Changing this allows equations of the form (exp)^positive integer to be solved sooner. (DEFUN EASYCASES (*EXP *VAR) (COND ((or (atom *exp) (atom (car *exp))) nil) ((EQ (CAAR *EXP) 'MTIMES) (DO ((TERMS (CDR *EXP) (CDR TERMS))) ((NULL TERMS)) (SOLVE (CAR TERMS) *VAR 1)) 'MTIMES) ((EQ (CAAR *EXP) 'MEXPT) (COND ((AND (INTEGERP (CADDR *EXP)) (PLUSP (CADDR *EXP))) (SOLVE (CADR *EXP) *VAR (CADDR *EXP)) 'MEXPRAT))))) Barton  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=835287&group_id=4933 
From: SourceForge.net <noreply@so...>  20040103 14:28:08

Bugs item #866510, was opened at 20031228 12:24 Message generated for change (Comment added) made by billingd You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=866510&group_id=4933 Category: None Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: David Billinghurst (billingd) Assigned to: Nobody/Anonymous (nobody) Summary: ode2 fails on dy/dx=0 Initial Comment: ode2() crashes on the trivial ode dy/dx=0 The problem occurs in solve1() in ode2.{lisp,mac), and can reproduce the problem from the command line as solve('diff(y,x),'diff(y,x)). This is already reported as bug 835287. Output from CVS maxima / clisp2.31 below. ##################################### (C1) ode2('diff(y,x),y,x); ***  CAR: #:G7885 is not a LIST The following restarts are available: MACSYMAQUIT :R1 Macsyma toplevel 1. Break [1]> :R1 Maxima restarted. ;; Loading file /usr/share/maxima/5.9.0.1cvs/share/maxima init.lisp ... ;; Loaded file /usr/share/maxima/5.9.0.1cvs/share/maximainit.lisp (C2) solve('diff(y,x),'diff(y,x)); ***  CAR: #:G7921 is not a LIST The following restarts are available: MACSYMAQUIT :R1 Macsyma toplevel 1. Break [2]> :R1 Maxima restarted. ;; Loading file /usr/share/maxima/5.9.0.1cvs/share/maxima init.lisp ... ;; Loaded file /usr/share/maxima/5.9.0.1cvs/share/maximainit.lisp  >Comment By: David Billinghurst (billingd) Date: 20040104 01:28 Message: Logged In: YES user_id=365569 Fixed by patch to solve.lisp. (see bug 835287)  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=866510&group_id=4933 