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}
(8) 
_{Sep}

_{Oct}

_{Nov}

_{Dec}

S  M  T  W  T  F  S 

1
(1) 
2

3
(4) 
4
(1) 
5
(2) 
6

7

8
(2) 
9
(4) 
10
(5) 
11
(4) 
12

13

14
(2) 
15

16
(3) 
17

18
(1) 
19

20
(1) 
21
(8) 
22
(2) 
23
(5) 
24
(1) 
25

26
(5) 
27

28

29

30
(7) 
31





From: SourceForge.net <noreply@so...>  20061030 15:32:47

Bugs item #1577267, was opened at 20061014 10:59 Message generated for change (Comment added) made by robert_dodier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1577267&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: Problem not in Maxima Group: None >Status: Pending >Resolution: Rejected Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Windows DEP Execution Problem Initial Comment: CPU: AMD64 dualcore OS: Windows XP Maxima: 5.10.0 DEP (Data Execution Prevention) is turned on. maxima.bat fails to execute maxima.exe. XMaxima and wxMaxima report a missing connection to Maxima. There is no warning, no hint to the real problem. I was confused, Filemon/Regmon did not help. In the wxMaxima discussion forum I found the solution. Workaround: include the full program path of maxima.exe C:\Program Files\Maxima5.10.0\lib\maxima\5.10.0\binarygcl\maxima.exe in the list of DEP exceptions (Control Panel>System>Advanced>Performance>DEP) Problem: It seems that the LISP interpreter in maxima.exe is executing binary code in data sections. This should be fixed.  >Comment By: Robert Dodier (robert_dodier) Date: 20061030 08:32 Message: Logged In: YES user_id=501686 Assigning category="Problem not in Maxima" and resolution=rejected and status=pending (will be closed automatically in 2 weeks). Notes: (1) I posted a note about this problem to the gcldevel mailing list, with no reply as of this writing. (2) But I did find this statement by Camm Maguire. Not sure exactly what this means. "GCL does not require executable stack, but does require nonrandomized sbrk. GCL autodetects when the OS is trying to do this and resets its 'personality'. All GCL apps work is such a mode on the latest security setups." (from http://groups.google.com/group/comp.lang.lisp/msg/f062ed80b68cbcda) (3) I added a note about Windows DEP to the wiki page for Runtime problems: http://maxima.sourceforge.net/wiki/index.php/Runtime%20problems  Comment By: Raymond Toy (rtoy) Date: 20061016 07:23 Message: Logged In: YES user_id=28849 I don't know about GCL in particular, but I believe this is how most Lisp implementations work.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1577267&group_id=4933 
From: SourceForge.net <noreply@so...>  20061030 15:09:07

Bugs item #1587235, was opened at 20061030 07:08 Message generated for change (Comment added) made by robert_dodier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1587235&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  Limit Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: limit(floor(x),x,1) wrong Initial Comment: With Maxima version: 5.10.0, I get the following : (%i1) limit(floor(x),x,1); (%o1) 1 should be und (%i2) limit(floor(x),x,1,minus); (%o2) 1 should be 0 Eric Reyssat email : reyssat@...  >Comment By: Robert Dodier (robert_dodier) Date: 20061030 08:09 Message: Logged In: YES user_id=501686 limit is mistakenly assuming that floor is continuous. I don't know how to make limit recognize that floor is discontinuous. Assigning this report to the "Lisp Core  Limit" category.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1587235&group_id=4933 
From: SourceForge.net <noreply@so...>  20061030 15:05:13

Bugs item #1583312, was opened at 20061023 21:43 Message generated for change (Comment added) made by robert_dodier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1583312&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  Integration Group: None >Status: Closed >Resolution: Rejected Priority: 5 Private: No Submitted By: Robert Dodier (robert_dodier) Assigned to: Nobody/Anonymous (nobody) Summary: integrate(3^log(x), x); => incorrect, but risch => OK Initial Comment: integrate(3^log(x), x); => 3^((1/log(3)+1)*log(x))/((1/log(3)+1)*log(3)) and then ratsimp(diff(%, x)); => 3^(log(x)/log(3)+log(x))/x but integrate(3^log(x), x), risch; => x*%e^(log(3)*log(x))/(log(3)+1) and then ratsimp(diff(%, x)); => %e^(log(3)*log(x)) See discussion on the mailing list 2002/04/05 & following.  >Comment By: Robert Dodier (robert_dodier) Date: 20061030 08:05 Message: Logged In: YES user_id=501686 Andrej, you are correct, it is not a bug. Sorry for the unnecessary report. Closing this report.  Comment By: Andrej Vodopivec (andrejv) Date: 20061026 11:43 Message: Logged In: YES user_id=1179910 I don't know what the discuission was, but I don't think there is a bug here: (%i1) integrate(3^log(x), x); (%o1) 3^((1/log(3)+1)*log(x))/((1/log(3)+1)*log(3)) (%i2) diff(%, x); (%o2) 3^((1/log(3)+1)*log(x))/x (%i3) radcan(%); (%o3) 3^log(x) Andrej  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1583312&group_id=4933 
From: SourceForge.net <noreply@so...>  20061030 14:35:32

Bugs item #1586927, was opened at 20061029 18: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=1586927&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: Pending >Resolution: Rejected Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: to plotting the coordinates x,y are blur Initial Comment: Maxima version: 5.10.0 Maxima build date: 10:46 10/8/2006 host type: i686pcmingw32 lispimplementationtype: GNU Common Lisp (GCL) lispimplementationversion: GCL 2.6.8  The problem rise when I change the windows graphics into the other in minimal mode and I Clicking in the graph the coordinates x,y are blur and disapear the problem when maximize the window. I atacched both windows in a file bmp José Luis González fotonluz@...  >Comment By: Robert Dodier (robert_dodier) Date: 20061030 07:35 Message: Logged In: YES user_id=501686 It turns out this bug is already known in the Gnuplot bug tracker. See: http://sourceforge.net/tracker/index.php?func=detail&aid=1520692&group_id=2055&atid=102055 Marking this report with resolution=rejected (because the bug is in Gnuplot and there is no way for Maxima to work around it), and status=pending (so that it will remain open for 2 weeks before being closed automatically, in case the original poster comes back).  Comment By: Robert Dodier (robert_dodier) Date: 20061029 23:49 Message: Logged In: YES user_id=501686 I have observed the same behavior sometimes. Just to clarify for the benefit of other readers, the coordinates of the mouse pointer are supposed to be displayed in the lower lefthand corner, but instead some blickies are displayed. The jpeg attached to this report shows the behavior very clearly. This is probably a Gnuplot bug  I'll forward this report to their bug tracker in hope of getting some resolution.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1586927&group_id=4933 
From: SourceForge.net <noreply@so...>  20061030 14:08:48

Bugs item #1587235, was opened at 20061030 06:08 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=1587235&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: limit(floor(x),x,1) wrong Initial Comment: With Maxima version: 5.10.0, I get the following : (%i1) limit(floor(x),x,1); (%o1) 1 should be und (%i2) limit(floor(x),x,1,minus); (%o2) 1 should be 0 Eric Reyssat email : reyssat@...  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1587235&group_id=4933 
From: SourceForge.net <noreply@so...>  20061030 06:49:35

Bugs item #1586927, was opened at 20061029 18: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=1586927&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: Open Resolution: None Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: to plotting the coordinates x,y are blur Initial Comment: Maxima version: 5.10.0 Maxima build date: 10:46 10/8/2006 host type: i686pcmingw32 lispimplementationtype: GNU Common Lisp (GCL) lispimplementationversion: GCL 2.6.8  The problem rise when I change the windows graphics into the other in minimal mode and I Clicking in the graph the coordinates x,y are blur and disapear the problem when maximize the window. I atacched both windows in a file bmp José Luis González fotonluz@...  >Comment By: Robert Dodier (robert_dodier) Date: 20061029 23:49 Message: Logged In: YES user_id=501686 I have observed the same behavior sometimes. Just to clarify for the benefit of other readers, the coordinates of the mouse pointer are supposed to be displayed in the lower lefthand corner, but instead some blickies are displayed. The jpeg attached to this report shows the behavior very clearly. This is probably a Gnuplot bug  I'll forward this report to their bug tracker in hope of getting some resolution.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1586927&group_id=4933 
From: SourceForge.net <noreply@so...>  20061030 01:25:32

Bugs item #1586927, was opened at 20061029 17:25 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1586927&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: Open Resolution: None Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: to plotting the coordinates x,y are blur Initial Comment: Maxima version: 5.10.0 Maxima build date: 10:46 10/8/2006 host type: i686pcmingw32 lispimplementationtype: GNU Common Lisp (GCL) lispimplementationversion: GCL 2.6.8  The problem rise when I change the windows graphics into the other in minimal mode and I Clicking in the graph the coordinates x,y are blur and disapear the problem when maximize the window. I atacched both windows in a file bmp José Luis González fotonluz@...  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1586927&group_id=4933 
From: SourceForge.net <noreply@so...>  20061026 23:58:56

Bugs item #1585491, was opened at 20061027 01:58 Message generated for change (Comment added) made by thomas001 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1585491&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  Floating point Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Thomas Weidner (thomas001) Assigned to: Nobody/Anonymous (nobody) Summary: float() doesn't descend into exp() expressions Initial Comment: (%i1) exp(%pi); %pi (%o1) %e (%i2) float(%o1); %pi (%o2) 2.718281828459045 (%i3) bfloat(%o1); (%o3) 2.314069263277927b1 i guess float should convert %pi and calculate the float value of %o1 completely,as bfloat does.  >Comment By: Thomas Weidner (thomas001) Date: 20061027 01:58 Message: Logged In: YES user_id=289936 Maxima version: 5.10.0 Maxima build date: 0:33 10/19/2006 host type: x86_64unknownlinuxgnu lispimplementationtype: GNU Common Lisp (GCL) lispimplementationversion: GCL 2.6.7  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1585491&group_id=4933 
From: SourceForge.net <noreply@so...>  20061026 23:58:14

Bugs item #1585491, was opened at 20061027 01:58 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=1585491&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  Floating point Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Thomas Weidner (thomas001) Assigned to: Nobody/Anonymous (nobody) Summary: float() doesn't descend into exp() expressions Initial Comment: (%i1) exp(%pi); %pi (%o1) %e (%i2) float(%o1); %pi (%o2) 2.718281828459045 (%i3) bfloat(%o1); (%o3) 2.314069263277927b1 i guess float should convert %pi and calculate the float value of %o1 completely,as bfloat does.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1585491&group_id=4933 
From: Gronw Vangorder <rodgeusafford@ar...>  20061026 18:15:27

a chemistry experiment. Which is completely beside the point. I Reasonable VlAGHRA http://www.asedinkafunjasesertion.com =20 can before you go out of the sealed terminal. Then he will move to the 
From: SourceForge.net <noreply@so...>  20061026 17:43:57

Bugs item #1583312, was opened at 20061024 05:43 Message generated for change (Comment added) made by andrejv You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1583312&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  Integration Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Robert Dodier (robert_dodier) Assigned to: Nobody/Anonymous (nobody) Summary: integrate(3^log(x), x); => incorrect, but risch => OK Initial Comment: integrate(3^log(x), x); => 3^((1/log(3)+1)*log(x))/((1/log(3)+1)*log(3)) and then ratsimp(diff(%, x)); => 3^(log(x)/log(3)+log(x))/x but integrate(3^log(x), x), risch; => x*%e^(log(3)*log(x))/(log(3)+1) and then ratsimp(diff(%, x)); => %e^(log(3)*log(x)) See discussion on the mailing list 2002/04/05 & following.  >Comment By: Andrej Vodopivec (andrejv) Date: 20061026 19:43 Message: Logged In: YES user_id=1179910 I don't know what the discuission was, but I don't think there is a bug here: (%i1) integrate(3^log(x), x); (%o1) 3^((1/log(3)+1)*log(x))/((1/log(3)+1)*log(3)) (%i2) diff(%, x); (%o2) 3^((1/log(3)+1)*log(x))/x (%i3) radcan(%); (%o3) 3^log(x) Andrej  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1583312&group_id=4933 
From: SourceForge.net <noreply@so...>  20061026 15:13:50

Bugs item #1579852, was opened at 20061018 13:15 Message generated for change (Settings changed) made by rtoy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1579852&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  Integration Group: None >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Mark Peloquin (incripshin) Assigned to: Nobody/Anonymous (nobody) Summary: bad integral evaluation Initial Comment: The following integral should evaluate to infinity: integrate(x/sqrt(1+x^4), x, 1, inf); This should be obvious since it's essentially integrating 1/x up to infinity, which diverges. Do the work if you like ... it diverges. Maxima evaluates this to: log((2*sqrt(2)+3)/(24*sqrt(2)+34))/4 However, maxima can tell that this diverges: limit(integrate(x/sqrt(1+x^4), x), x, inf)  Comment By: Nobody/Anonymous (nobody) Date: 20061022 11:02 Message: Logged In: NO In version 5.10.0 maxima gives the correct answer: (%i28) integrate(x/sqrt(1+x^4), x, 1, inf); Integral is divergent  an error. Quitting. To debug this try debugmode(true);  Comment By: Nobody/Anonymous (nobody) Date: 20061022 10:53 Message: Logged In: NO In version 5.10.0 maxima gives the correct answer: (%i28) integrate(x/sqrt(1+x^4), x, 1, inf); Integral is divergent  an error. Quitting. To debug this try debugmode(true);  Comment By: Raymond Toy (rtoy) Date: 20061021 15:41 Message: Logged In: YES user_id=28849 What version? 5.10.0 says the integrate(x/sqrt(1+x^4),x,1,inf) is divergent.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1579852&group_id=4933 
From: SourceForge.net <noreply@so...>  20061024 03:43:08

Bugs item #1583312, was opened at 20061023 21: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=1583312&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  Integration Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Robert Dodier (robert_dodier) Assigned to: Nobody/Anonymous (nobody) Summary: integrate(3^log(x), x); => incorrect, but risch => OK Initial Comment: integrate(3^log(x), x); => 3^((1/log(3)+1)*log(x))/((1/log(3)+1)*log(3)) and then ratsimp(diff(%, x)); => 3^(log(x)/log(3)+log(x))/x but integrate(3^log(x), x), risch; => x*%e^(log(3)*log(x))/(log(3)+1) and then ratsimp(diff(%, x)); => %e^(log(3)*log(x)) See discussion on the mailing list 2002/04/05 & following.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1583312&group_id=4933 
From: SourceForge.net <noreply@so...>  20061023 17:57:16

Bugs item #1582625, was opened at 20061023 00:22 Message generated for change (Comment added) made by rtoy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1582625&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  Integration Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: integrate(t^2*log(t)/((t^21)*(t^4+1)), t, 0, 1) wrong? Initial Comment: Symbolic integration seems to return an incorrect result: (%i1) integrate(t^2*log(t)/((t^21)*(t^4+1)), t, 0, 1); (sqrt(2) + 1) %pi (%o1)  16 sqrt(2) (%i2) float(%); (%o2) 1.053029287545515 (%i3) romberg(t^2*log(t)/((t^21)*(t^4+1)), t, 0.0000001, 0.9999999); (%o3) 0.1806718095951 (%i4) float(%pi^2/(16*(2+sqrt(2)))); (%o4) 0.18067126259065  >Comment By: Raymond Toy (rtoy) Date: 20061023 13:57 Message: Logged In: YES user_id=28849 Maxima uses the substitution t = exp(y) to change the integral from 0 to 1 to 0 to inf. Then it uses its routine to handle this infinite integral by converting it to an integral from minf to inf, because the integrand is even. Finally, it uses rectzto%pi2 to integrate this final integrand. rectzto%pi2 needs to find the poles of the denominator. I'm guessing it's getting that wrong.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1582625&group_id=4933 
From: SourceForge.net <noreply@so...>  20061023 14:55:26

Bugs item #1582661, was opened at 20061023 00:52 Message generated for change (Settings changed) made by robert_dodier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1582661&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  Integration Group: None >Status: Closed Resolution: Duplicate Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: integrate(t^2*log(t)/((t^21)*(t^4+1)), t, 0, 1) wrong? Initial Comment: Symbolic integration seems to return an incorrect result: (%i1) integrate(t^2*log(t)/((t^21)*(t^4+1)), t, 0, 1); (sqrt(2) + 1) %pi (%o1)  16 sqrt(2) (%i2) float(%); (%o2) 1.053029287545515 (%i3) romberg(t^2*log(t)/((t^21)*(t^4+1)), t, 0.0000001, 0.9999999); (%o3) 0.1806718095951 (%i4) float(%pi^2/(16*(2+sqrt(2)))); (%o4) 0.18067126259065  Comment By: Barton Willis (willisbl) Date: 20061023 04:39 Message: Logged In: YES user_id=895922 duplication of bug 1582625  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1582661&group_id=4933 
From: SourceForge.net <noreply@so...>  20061023 10:39:18

Bugs item #1582661, was opened at 20061023 01:52 Message generated for change (Comment added) made by willisbl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1582661&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  Integration Group: None Status: Open >Resolution: Duplicate Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: integrate(t^2*log(t)/((t^21)*(t^4+1)), t, 0, 1) wrong? Initial Comment: Symbolic integration seems to return an incorrect result: (%i1) integrate(t^2*log(t)/((t^21)*(t^4+1)), t, 0, 1); (sqrt(2) + 1) %pi (%o1)  16 sqrt(2) (%i2) float(%); (%o2) 1.053029287545515 (%i3) romberg(t^2*log(t)/((t^21)*(t^4+1)), t, 0.0000001, 0.9999999); (%o3) 0.1806718095951 (%i4) float(%pi^2/(16*(2+sqrt(2)))); (%o4) 0.18067126259065  >Comment By: Barton Willis (willisbl) Date: 20061023 05:39 Message: Logged In: YES user_id=895922 duplication of bug 1582625  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1582661&group_id=4933 
From: SourceForge.net <noreply@so...>  20061023 06:52:49

Bugs item #1582661, was opened at 20061022 23:52 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=1582661&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  Integration Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: integrate(t^2*log(t)/((t^21)*(t^4+1)), t, 0, 1) wrong? Initial Comment: Symbolic integration seems to return an incorrect result: (%i1) integrate(t^2*log(t)/((t^21)*(t^4+1)), t, 0, 1); (sqrt(2) + 1) %pi (%o1)  16 sqrt(2) (%i2) float(%); (%o2) 1.053029287545515 (%i3) romberg(t^2*log(t)/((t^21)*(t^4+1)), t, 0.0000001, 0.9999999); (%o3) 0.1806718095951 (%i4) float(%pi^2/(16*(2+sqrt(2)))); (%o4) 0.18067126259065  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1582661&group_id=4933 
From: SourceForge.net <noreply@so...>  20061023 04:22:02

Bugs item #1582625, was opened at 20061022 21:22 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=1582625&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  Integration Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: integrate(t^2*log(t)/((t^21)*(t^4+1)), t, 0, 1) wrong? Initial Comment: Symbolic integration seems to return an incorrect result: (%i1) integrate(t^2*log(t)/((t^21)*(t^4+1)), t, 0, 1); (sqrt(2) + 1) %pi (%o1)  16 sqrt(2) (%i2) float(%); (%o2) 1.053029287545515 (%i3) romberg(t^2*log(t)/((t^21)*(t^4+1)), t, 0.0000001, 0.9999999); (%o3) 0.1806718095951 (%i4) float(%pi^2/(16*(2+sqrt(2)))); (%o4) 0.18067126259065  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1582625&group_id=4933 
From: SourceForge.net <noreply@so...>  20061022 15:02:42

Bugs item #1579852, was opened at 20061018 10:15 Message generated for change (Comment added) made by nobody You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1579852&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  Integration Group: None Status: Open Resolution: None Priority: 5 Submitted By: Mark Peloquin (incripshin) Assigned to: Nobody/Anonymous (nobody) Summary: bad integral evaluation Initial Comment: The following integral should evaluate to infinity: integrate(x/sqrt(1+x^4), x, 1, inf); This should be obvious since it's essentially integrating 1/x up to infinity, which diverges. Do the work if you like ... it diverges. Maxima evaluates this to: log((2*sqrt(2)+3)/(24*sqrt(2)+34))/4 However, maxima can tell that this diverges: limit(integrate(x/sqrt(1+x^4), x), x, inf)  Comment By: Nobody/Anonymous (nobody) Date: 20061022 08:02 Message: Logged In: NO In version 5.10.0 maxima gives the correct answer: (%i28) integrate(x/sqrt(1+x^4), x, 1, inf); Integral is divergent  an error. Quitting. To debug this try debugmode(true);  Comment By: Nobody/Anonymous (nobody) Date: 20061022 07:53 Message: Logged In: NO In version 5.10.0 maxima gives the correct answer: (%i28) integrate(x/sqrt(1+x^4), x, 1, inf); Integral is divergent  an error. Quitting. To debug this try debugmode(true);  Comment By: Raymond Toy (rtoy) Date: 20061021 12:41 Message: Logged In: YES user_id=28849 What version? 5.10.0 says the integrate(x/sqrt(1+x^4),x,1,inf) is divergent.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1579852&group_id=4933 
From: SourceForge.net <noreply@so...>  20061022 14:53:48

Bugs item #1579852, was opened at 20061018 10:15 Message generated for change (Comment added) made by nobody You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1579852&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  Integration Group: None Status: Open Resolution: None Priority: 5 Submitted By: Mark Peloquin (incripshin) Assigned to: Nobody/Anonymous (nobody) Summary: bad integral evaluation Initial Comment: The following integral should evaluate to infinity: integrate(x/sqrt(1+x^4), x, 1, inf); This should be obvious since it's essentially integrating 1/x up to infinity, which diverges. Do the work if you like ... it diverges. Maxima evaluates this to: log((2*sqrt(2)+3)/(24*sqrt(2)+34))/4 However, maxima can tell that this diverges: limit(integrate(x/sqrt(1+x^4), x), x, inf)  Comment By: Nobody/Anonymous (nobody) Date: 20061022 07:53 Message: Logged In: NO In version 5.10.0 maxima gives the correct answer: (%i28) integrate(x/sqrt(1+x^4), x, 1, inf); Integral is divergent  an error. Quitting. To debug this try debugmode(true);  Comment By: Raymond Toy (rtoy) Date: 20061021 12:41 Message: Logged In: YES user_id=28849 What version? 5.10.0 says the integrate(x/sqrt(1+x^4),x,1,inf) is divergent.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1579852&group_id=4933 
From: SourceForge.net <noreply@so...>  20061021 20:26:12

Bugs item #1575120, was opened at 20061011 02:54 Message generated for change (Comment added) made by robert_dodier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1575120&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: Pending >Resolution: Rejected Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Some laws are still missing Initial Comment: is(equal((x/y)^z,(x^z/y^z))); is(equal((x*y)^z,(x^z*y^z))); is(equal((x^y)^z,(x^(y*z)))); of course they are equal! Those are laws! Mario/Mexico  >Comment By: Robert Dodier (robert_dodier) Date: 20061021 14:26 Message: Logged In: YES user_id=501686 As mentioned by Barton, Maxima's default behavior is correct (since there are examples for which those equations fail to hold). I find that assuming x > 0 and y > 0, Maxima does evaluate those to true; I believe that is correct. assume(x>0,y>0); is(equal((x/y)^z,(x^z/y^z))); => true is(equal((x*y)^z,(x^z*y^z))); => true is(equal((x^y)^z,(x^(y*z)))); => true A possible enhancement (very far away at this point) would be for is(equal(...)) to return a result with one or more guard clauses specifying the applicability of various particular results. I won't try to spec that here. Marking this report "rejected" and "pending" (so that it will be closed automatically in 2 weeks, in case the original poster comes back).  Comment By: Barton Willis (willisbl) Date: 20061011 04:09 Message: Logged In: YES user_id=895922 For real x,y,z, the equation (x*y)^z = x^z*y^z isn't an identity. To see this, let x > 1, y > 1, and z > 1/2. If Maxima did is(equal((x*y)^z,(x^z*y^z))) > true that would be a bug. Similarly, all your other laws are not valid for all real numbers. (1) We're working on improving the function equal; it has many known problems. (2) The function 'radcan' does (%i16) radcan((x*y)^z); (%o16) x^z*y^z Maybe you would like to use it.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1575120&group_id=4933 
From: SourceForge.net <noreply@so...>  20061021 19:41:32

Bugs item #1579852, was opened at 20061018 13:15 Message generated for change (Comment added) made by rtoy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1579852&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  Integration Group: None Status: Open Resolution: None Priority: 5 Submitted By: Mark Peloquin (incripshin) Assigned to: Nobody/Anonymous (nobody) Summary: bad integral evaluation Initial Comment: The following integral should evaluate to infinity: integrate(x/sqrt(1+x^4), x, 1, inf); This should be obvious since it's essentially integrating 1/x up to infinity, which diverges. Do the work if you like ... it diverges. Maxima evaluates this to: log((2*sqrt(2)+3)/(24*sqrt(2)+34))/4 However, maxima can tell that this diverges: limit(integrate(x/sqrt(1+x^4), x), x, inf)  >Comment By: Raymond Toy (rtoy) Date: 20061021 15:41 Message: Logged In: YES user_id=28849 What version? 5.10.0 says the integrate(x/sqrt(1+x^4),x,1,inf) is divergent.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1579852&group_id=4933 
From: SourceForge.net <noreply@so...>  20061021 18:46:45

Bugs item #1553324, was opened at 20060906 05:09 Message generated for change (Comment added) made by robert_dodier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1553324&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: Wont Fix Priority: 5 Submitted By: Barton Willis (willisbl) Assigned to: Nobody/Anonymous (nobody) Summary: equalp Initial Comment: The user documentation makes me think that is(equalp(a,b)) is the same as is(equal(a,b)), prederror : false. But it isn't: (%i1) is(equalp(x,x)); Maxima was unable to evaluate the predicate: equalp(x,x) (%i2) is(equalp(x,x)), prederror : false; (%o2) unknown If is(equalp(a,b)) is the same as is(equal(a,b)) with prederror : false, do we really need equalp? Barton  >Comment By: Robert Dodier (robert_dodier) Date: 20061021 12:46 Message: Logged In: YES user_id=501686 Well, equalp is defined in share/calculus/fourie.mac (Fourier series) and it is not autoloading. load(fourie); is(equalp(x,x)); => true as expected. fourie.mac contains several convenience functions. I don't know how useful equalp is outside of fourie, but since it is in an addon package I am inclined to leave it. Closing this report as "won't fix". Feel free to reopen it if you still consider this to be a bug.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1553324&group_id=4933 
From: SourceForge.net <noreply@so...>  20061021 18:39:44

Bugs item #1567694, was opened at 20060929 07: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=1567694&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: 5 Submitted By: Barton Willis (willisbl) Assigned to: Nobody/Anonymous (nobody) Summary: no tag signimagerr Initial Comment: When signimagerrp is false, I think $sign shouldn't signal an error for a nonreal argument. But ... (defun $gr (a b) (let ((signimagerrp nil)) (eq t (mgrp a b)))) (%i107) gr(5,%i); Maxima encountered a Lisp error: Error in LET [or callee]: The tag SIGNIMAGERR is undefined.  >Comment By: Robert Dodier (robert_dodier) Date: 20061021 12:39 Message: Logged In: YES user_id=501686 Without looking at the code, I am inclined to agree that SIGNIMAGERRP should quiet SIGNIMAGERR.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1567694&group_id=4933 
From: SourceForge.net <noreply@so...>  20061021 18:38:27

Bugs item #1571099, was opened at 20061004 21:51 Message generated for change (Comment added) made by robert_dodier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1571099&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: 5 Submitted By: Julien B. O. (jul059) Assigned to: Nobody/Anonymous (nobody) Summary: handling of large factorials Initial Comment: evaluation of large factorials, such as 143311! leads to a value stack overflow when evaluated in wxMaxima 0.7.0a, but not in the command line version of maxima: Maxima encountered a Lisp error: Error in FORMAT [or a callee]: Value stack overflow.Automatically continuing.To reenable the Lisp debugger set *debuggerhook* to nil. The error is explicit enough to understand it is an overflow... but when trying to evaluate even larger factorials, such as 1433115!, windows simply reports a standard program failure with no message from maxima regardless of the interface you use. version used: Maxima version: 5.10.0 Maxima build date: 19:9 9/21/2006 host type: i686pcmingw32 lispimplementationtype: GNU Common Lisp (GCL) lispimplementationversion: GCL 2.6.7 also using Windows XP profesionnal with SP2.  >Comment By: Robert Dodier (robert_dodier) Date: 20061021 12:38 Message: Logged In: YES user_id=501686 Interesting problem. If I had to guess I would say that GCL is not verifying whether some memory allocation has succeeded. Some additional data. (1) With Maxima 5.10.0cvs + GCL 2.6.7 + Linux, computations of a:143311!$ succeeds (3 s) and a2:1433115$ succeeds (76 s). Note that display of a and a2 is suppressed by $. (2) (Again with GCL 2.6.7) Display of a and a2 fails, however. a; yields (after a short delay) some garbage (spaces and backslashes observed on some occasions and random characters on another) and a2; causes a segfault. (3) Maxima 5.10.0 + clisp 2.38 + Linux: 143311!; yields "overflow during multiplication of large numbers". (4) Maxima 5.10.0cvs + sbcl 0.9.16: a:143311!$ takes about 100 s, and a2:1433115!$ didn't terminate within an hour. Display a; seems to take longer than I'm willing to wait.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1571099&group_id=4933 