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

_{Feb}

_{Mar}

_{Apr}

_{May}

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

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

_{May}

_{Jun}

_{Jul}

_{Aug}

_{Sep}

_{Oct}

_{Nov}

_{Dec}

S  M  T  W  T  F  S 






1
(3) 
2
(9) 
3
(1) 
4
(7) 
5
(4) 
6
(2) 
7
(6) 
8
(2) 
9
(2) 
10
(4) 
11
(3) 
12

13
(11) 
14
(1) 
15
(4) 
16

17

18
(1) 
19
(5) 
20

21
(3) 
22
(2) 
23
(1) 
24

25
(1) 
26

27
(4) 
28
(1) 
29
(11) 
30
(2) 
From: SourceForge.net <noreply@so...>  20070630 20:47:56

Bugs item #1650226, was opened at 20070201 23:47 Message generated for change (Comment added) made by cwitty You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1650226&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  Polynomials Group: None Status: Open Resolution: None Priority: 6 Private: No Submitted By: Barton Willis (willisbl) Assigned to: Nobody/Anonymous (nobody) Summary: Bind stack overflow for factor 7th degree Initial Comment: (%i1) 156*x^7+4808*x^6182041*x^51266489*x^4+43104271*x^3 +29839285*x^22542327662*x+7826952672$ (%i2) factor(%); Maxima encountered a Lisp error: Error in MACSYMATOPLEVEL [or a callee]: Bind stack overflow. The factors are all linear: (%i3) berlefact : false; (%o3) false (%i4) factor(%i1); (%o4) (x16)*(x+14)*(x+49)*(2*x11)*(2*x+21)*(3*x49)*(13*x63)  Comment By: Carl Witty (cwitty) Date: 20070630 20:47 Message: Logged In: YES user_id=14517 Originator: NO Here's another example of (presumably) the same problem: (%i1) factor(351039744*u^47  4146785280*u^46 + 21010752000*u^45  51641487360*u^44 + 22909388544*u^43 + 226995397632*u^42  609312557056*u^41 + 241407713280*u^40 + 1862346686208*u^39  4143913640960*u^38 + 1996259731968*u^37 + 5683411390464*u^36  10233183569664*u^35 + 3570312475776*u^34 + 5427479744256*u^33  14632753159296*u^32 + 35014067381760*u^31 + 919601276544*u^30  120004234261760*u^29 + 89792759938176*u^28 + 146430616799232*u^27  174447418437376*u^26  83088089063424*u^25 + 152708862935040*u^24 + 39789942893600*u^23  68867281548288*u^22  84869607997440*u^21 + 59149909463040*u^20 + 167176883404800*u^19  202290559266816*u^18 + 26574158757888*u^17 + 66648721563648*u^16  38084983750656*u^15 + 6347497291776*u^14); Maxima encountered a Lisp error: ... (I'm pretty sure it doesn't matter, but just in case: Debian x86 32bit, maxima package version 5.12.01; Maxima version: 5.12.0 Maxima build date: 8:49 5/4/2007 host type: i686pclinuxgnu lispimplementationtype: GNU Common Lisp (GCL) lispimplementationversion: GCL 2.6.7 )  Comment By: Barton Willis (willisbl) Date: 20070206 12:46 Message: Logged In: YES user_id=895922 Originator: YES I think the bug happens when choozp (called from fact5) returns 'splitcase. When this happens, eventually fact5 calls nalgfac. Either nalgfac is called with the wrong arguments (see comment in nalgfa.lisp), or nalgfac (or friends) is broken. Also, I see that nalgfa has several undocumented user level functions. That makes me wonder if nalgfac was never fully tested. It's possible to make choozp less likely to return spiltcase. To do change the test (in choozp) (> algcont 6) to something like (> algcont 100). I'm guessing that changing this test is harmless (the test suite is OK with it). And the change eliminates this particular bug. But changing (> algcont 6) > (> algcont 100) *doesn't* fix the bug. So I'm not going the change the source.  Comment By: Vadim V. Zhytnikov (vvzhy) Date: 20070203 13:22 Message: Logged In: YES user_id=366498 Originator: NO Another manifestation of the same bug is factor(taylor(sin(x),x,%pi/4,20); Notice also that error message "Bind stack overflow" is (a) GCL specific and (b) misleading. Other lisps (clisp, sbcl, cmucl) complain that "NIL is not of numeric type".  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1650226&group_id=4933 
From: SourceForge.net <noreply@so...>  20070630 19:23:11

Bugs item #1709444, was opened at 20070428 17: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=1709444&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: Tests Group: To be reviewed >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: run_testsuite has problems with error breaks Initial Comment: When there is an "error break" (whatever that is  shouldn't run_testsuite catch all errors?), run_testsuite gives no useful information about what the error is or where it occurred (e.g. after test #200). You have to do run_testsuite(true,true) and eyeball the results to see what the problem is, and the summary still isn't very useful....  >Comment By: Robert Dodier (robert_dodier) Date: 20070630 13:23 Message: Logged In: YES user_id=501686 Originator: NO Recent test suite code in src/mload.lisp corrects this problem. Closing this report.  Comment By: Robert Dodier (robert_dodier) Date: 20070629 17:47 Message: Logged In: YES user_id=501686 Originator: NO Test suite stuff has been revised lately. Marking this report for review.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1709444&group_id=4933 
From: SourceForge.net <noreply@so...>  20070629 23:47:05

Bugs item #1709444, was opened at 20070428 17: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=1709444&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: Tests >Group: To be reviewed Status: Open Resolution: None Priority: 5 Private: No Submitted By: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: run_testsuite has problems with error breaks Initial Comment: When there is an "error break" (whatever that is  shouldn't run_testsuite catch all errors?), run_testsuite gives no useful information about what the error is or where it occurred (e.g. after test #200). You have to do run_testsuite(true,true) and eyeball the results to see what the problem is, and the summary still isn't very useful....  >Comment By: Robert Dodier (robert_dodier) Date: 20070629 17:47 Message: Logged In: YES user_id=501686 Originator: NO Test suite stuff has been revised lately. Marking this report for review.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1709444&group_id=4933 
From: SourceForge.net <noreply@so...>  20070629 23:45:57

Bugs item #1709420, was opened at 20070428 16:21 Message generated for change (Comment added) made by robert_dodier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1709420&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: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: Inconsistent filename syntax in clisp/gcl versions Initial Comment: Running on Cygwin/Windows 2000, filename syntax is incompatible between Clisp and GCL. Under Maxima 5.11.0cvs CLISP 2.31 load("c:/maximacvs/maxima/src/float.lisp") => could not find ... using paths... load("c:\\maximacvs\\maxima\\src\\float.lisp") => Maxima encountered a Lisp error load("/root/maximacvs/maxima/src/float.lisp") => OK Under 5.11.0 GCL 2.6.8 load("c:/maximacvs/maxima/src/float.lisp") => OK load("c:\\maximacvs\\maxima\\src\\float.lisp") => OK load("/root/maximacvs/maxima/src/float.lisp") => could not find ... using paths... I believe all three syntaxes should work on all implementations. (The double backslashes are necessary because backslash is a Maxima escape character.) PS There doesn't seem to be a Sourceforge bug tracker category for systemsy problems....  >Comment By: Robert Dodier (robert_dodier) Date: 20070629 17:45 Message: Logged In: YES user_id=501686 Originator: NO My guess as to what's going on here is that Clisp and/or Cygwin is trying to be clever. GCL probably just passes the path string verbatim to fopen in some C library, so it's more likely to act as expected. This is not a problem of our making, and I'm pretty hesitant to try to fix it. I'm inclined to close this report as "won't fix". Maybe someone wants to talk me out of it.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1709420&group_id=4933 
From: SourceForge.net <noreply@so...>  20070629 23:37:25

Bugs item #1700056, was opened at 20070413 07: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=1700056&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: Duplicate Priority: 5 Private: No Submitted By: Nikos Apostolakis (nikos_ap) Assigned to: Nobody/Anonymous (nobody) Summary: solve in systems returns 0 denominators Initial Comment: With Maxima 5.11.0, Using Lisp CLISP 2.41 (20061013) q1 : 2/x + 5/y = 19/15; q2 : 1/y 5/x = 4/3; sys :[q1,q2]; var : [x,y]; solve(sys,var); /*==> [[x = 5,y = 3],[x = 0,y = 0]] This seems to happen only with systems. I was not able to reproduce this bug with a single equation and a single variable.  >Comment By: Robert Dodier (robert_dodier) Date: 20070629 17:37 Message: Logged In: YES user_id=501686 Originator: NO Duplicate of bug report # 1708293. Content of this report has been merged with that one.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1700056&group_id=4933 
From: SourceForge.net <noreply@so...>  20070629 23:36:38

Bugs item #1708293, was opened at 20070426 12:13 Message generated for change (Comment added) made by robert_dodier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1708293&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: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) >Summary: Spurious solutions (zero denominators) returned by solve Initial Comment: I was trying to calculate the equation of a hyperbola of the type x^2/a^2  y^2/b^2 = 1, given two points. Maxima finds, among others, also a wrong solution [a=0,b=0]. (%i4) hyp:x^2/a^2y^2/b^2=1$ (%i4) eq1:hyp,x=5/2,y=3/4$ (%i4) eq2:hyp,x=10/3,y=4/3$ (%i4) solve([eq1,eq2],[a,b]); (%o4) [[a=2,b=1],[a=2,b=1],[a=2,b=1],[a=2,b=1],[a=0,b=0]] F. Buratti (Italy) bufranz@... Maxima version: 5.11.99rc2 Maxima build date: 20:46 4/19/2007 host type: i686pcmingw32 lispimplementationtype: GNU Common Lisp (GCL) lispimplementationversion: GCL 2.6.8  >Comment By: Robert Dodier (robert_dodier) Date: 20070629 17:36 Message: Logged In: YES user_id=501686 Originator: NO Merging bug report # 1700056 (same problem); I'll mark 1700056 as a dup. Also revise summary to make it more descriptive.  begin 1700056  With Maxima 5.11.0, Using Lisp CLISP 2.41 (20061013) q1 : 2/x + 5/y = 19/15; q2 : 1/y 5/x = 4/3; sys :[q1,q2]; var : [x,y]; solve(sys,var); /*==> [[x = 5,y = 3],[x = 0,y = 0]] This seems to happen only with systems. I was not able to reproduce this bug with a single equation and a single variable.  end 1700056   Comment By: Stavros Macrakis (macrakis) Date: 20070501 12:57 Message: Logged In: YES user_id=588346 Originator: NO Yes, this is a bug. Here is a simpler example: solve([1/a1/b=1,a=b],[a,b]) => [[a=0,b=0]]  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1708293&group_id=4933 
From: SourceForge.net <noreply@so...>  20070629 23:32:08

Bugs item #1707955, was opened at 20070426 04:30 Message generated for change (Comment added) made by robert_dodier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1707955&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: Open Resolution: None Priority: 4 Private: No Submitted By: Barton Willis (willisbl) Assigned to: Nobody/Anonymous (nobody) >Summary: transpose noun / verb confusion / FIX Initial Comment: transpose('(transpose(x))) should simplify to x, but it doesn't: (%i1) transpose('(transpose(x))); (%o1) transpose(transpose(x)) Proposed fix: (defmfun $transpose (mat) (cond ((not (mxorlistp mat)) (cond ((and (not (atom mat)) (memq (mop mat) '($transpose %transpose))) (cadr mat)) ...  >Comment By: Robert Dodier (robert_dodier) Date: 20070629 17:32 Message: Logged In: YES user_id=501686 Originator: NO Append FIX to subject line to indicate that report contains a proposed fix.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1707955&group_id=4933 
From: SourceForge.net <noreply@so...>  20070629 23:30:20

Bugs item #1699445, was opened at 20070412 12:11 Message generated for change (Comment added) made by robert_dodier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1699445&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: Stavros Macrakis (macrakis) Assigned to: Jaime E. Villate (villate) Summary: plot2d in very narrow range Initial Comment: I was looking at the behavior of floatingpoint sin near %pi/2, so I did: plot2d(sin(x),[x,1.57079628,1.570796326794897], [nticks,1000]); There are several problems with the result. First of all, the x and y axes are labelled with only 5 digits of precision, so x goes from 1.5708 to 1.5708, and y goes from 1 to 1. Not very useful. Similarly, the coordinates shown in the bottom left have only 6 digits. Secondly, about 5/6 of the way across the plot, there is a short line *outside* the plotting box. I don't know if this represents a value larger than the other values or some sort of plotting glitch. Maxima 5.11.0 GCL Windows Gnuplot 4.0  >Comment By: Robert Dodier (robert_dodier) Date: 20070629 17:30 Message: Logged In: YES user_id=501686 Originator: NO It appears that the display generated by Maxima 5.12.0 is even less informative ... in 5.12.0 the vertical range of the display is 0.99 to 1.01 which is many orders of magnitude greater than the range of sin over [1.57079628, 1.570796326794897]. At least with 5.11.0 you get stair steps as expected. The range [0.99, 1.01] might be imposed by Gnuplot (5.12.0 ships with Gnuplot 4.1, 5.11.0 ships with 4.0), or it might be imposed by Maxima, dunno which.  Comment By: Stavros Macrakis (macrakis) Date: 20070412 12:13 Message: Logged In: YES user_id=588346 Originator: YES nticks not necessary to evoke this bug  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1699445&group_id=4933 
From: SourceForge.net <noreply@so...>  20070629 23:23:06

Bugs item #1694782, was opened at 20070404 23:49 Message generated for change (Comment added) made by robert_dodier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1694782&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: 3 Private: No Submitted By: Stavros Macrakis (macrakis) Assigned to: Jaime E. Villate (villate) Summary: plot2d ... [y,0,1/2] Initial Comment: plot2d doesn't allow rational numbers or bfloats in the Yrange: plot2d(sin(x),[x,0,5],[y,0,1/2]) => 1/2 is not of the right type in y list  >Comment By: Robert Dodier (robert_dodier) Date: 20070629 17:22 Message: Logged In: YES user_id=501686 Originator: NO Not observed in Maxima 5.12.0. Already fixed as noted by J Villate. Closing this report.  Comment By: Jaime E. Villate (villate) Date: 20070410 10:03 Message: Logged In: YES user_id=28692 Originator: NO This bug was already fixed on 26032007. You must be using a version of plot.lisp older than 1.89.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1694782&group_id=4933 
From: SourceForge.net <noreply@so...>  20070629 23:23:06

Bugs item #1695573, was opened at 20070406 06:49 Message generated for change (Settings changed) made by robert_dodier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1695573&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  Taylor Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Taylor around coth singulariities Initial Comment: Using Maxima 5.11.0 on Windows. The following behavior is expected: (%i55) coth(x); (%o55) coth(x) (%i56) taylor(%, x, 0, 1); 1 x (%o56)/T/  +  + . . . x 3 (%i57) taylor(%, x, 0, 0); 1 (%o57)/T/  + . . . x Now shift to another singularity of coth: (%i51) coth(x+%i*%pi); (%o51) coth(x + %i %pi) (%i52) taylor(%, x, 0, 1); 1 x (%o52)/T/  +  + . . . x 3 (%i53) taylor(%, x, 0, 0); 1 x (%o53)/T/  +  + . . . x 3 (%i54) taylor(%, x, 0, 0); 1 (%o54)/T/  + . . . x Oddly enough, an extra step is needed in this case to get rid of the firstorder term.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1695573&group_id=4933 
From: SourceForge.net <noreply@so...>  20070629 23:18:22

Bugs item #1692729, was opened at 20070402 02:46 Message generated for change (Settings changed) made by robert_dodier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1692729&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  Polynomials Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: coeff, ratcoef on Taylor series around inf Initial Comment: It seems that coeff() and ratcoef() have trouble extracting coefficients from Taylor expansions around infinity: (%i119) taylor(1/x, x, inf, 1); 1 (%o119)/T/  + . . . x (%i120) ratcoef(taylor(1/x, x, inf, 1), x, 1); (%o120)/R/ 0 (%i121) coeff(taylor(1/x, x, inf, 1), x, 1); (%o121)/R/ 0 A workaround is to get rid of the Taylor property, e.g., by wrapping the expression in subst(0, 0, ...).  Comment By: Stavros Macrakis (macrakis) Date: 20070404 23:45 Message: Logged In: YES user_id=588346 Originator: NO Yes, ratcoeff is a bit confused by taylor expansions at infinity: qq: taylor(sum((i3+100)*x^(i3),i,0,5),x,inf,10) => 102*x^2+101*x+100+99/x+98/x^2+97/x^3 + ... makelist(ratcoeff(qq,x,i),i,3,4) => => [0, 102, 101, 100, 99, 98, 97, 0] In other words, it treats the 1/x^2 as the ratcoeff(...,x,2) term. So the workaround is to negate the power... but of course that will become exactly wrong when the bug is fixed....  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1692729&group_id=4933 
From: SourceForge.net <noreply@so...>  20070629 01:39:10

Bugs item #1692082, was opened at 20070331 12:21 Message generated for change (Settings changed) made by robert_dodier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1692082&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: tlimit(s/(1+s^2)/sinh(x*T), s, inf) Initial Comment: In Maxima 5.11.0: tlimit(s/(1+s^2)/sinh(x*T), s, inf); Is T positive, negative, or zero? p Invalid call to varexpand. (Cf. Maxima list: March 31, 2007, "bug in tlimit?"). Stavros mentioned on the list that taylor(exp(x)exp(x), x, inf, 2) returns a sensible result whereas taylor((exp(x)exp(x))/2, x, inf, 2) triggers an internal error.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1692082&group_id=4933 
From: SourceForge.net <noreply@so...>  20070629 01:38:41

Bugs item #1692078, was opened at 20070331 12:07 Message generated for change (Settings changed) made by robert_dodier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1692078&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 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: enhance partfrac for 1/(x^4+20*x^2+120) Initial Comment: As discussed on the mailing list (March 31, 2007; subject "A partfrac limitation"), partfrac(1/(120+20*x^2+x^4), x) does not work although it can easily be computed.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1692078&group_id=4933 
From: SourceForge.net <noreply@so...>  20070628 02:20:06

Bugs item #1736216, was opened at 20070612 20:16 Message generated for change (Comment added) made by sfrobot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1736216&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: Closed Resolution: None Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: integration integrate(1/((x3)^4+1/2),x,0,1);=0???? Initial Comment: In the Moses tutorial, there is the integration %i1) integrate(1/((x3)^4+1/2),x,0,1); (%o1) 0 while the true result is 0.02880...... which was obtained using romberg (%i2) romberg(1/((x3)^4+1/2),x,0,1); Is that a bug, or is there a trick. (%o2) 0.028806333924554  >Comment By: SourceForge Robot (sfrobot) Date: 20070627 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: Raymond Toy (rtoy) Date: 20070613 08:36 Message: Logged In: YES user_id=28849 Originator: NO Recent CVS version doesn't return 0. It returns some really long and hairy expression that can't be printed because it's too wide. But radcan(sqrtdenest(integrate(1/((x3)^4+1/2),x,0,1))); returns something sensible, which evaluates to 0.028806... What version of maxima? Marking this as pending.  Comment By: Harald Geyer (hgeyer) Date: 20070613 06:22 Message: Logged In: YES user_id=929336 Originator: NO I don't know, what the submitter (alas he left no contact info) did wrong, but I can't reproduce this bug with 5.11.0 and 5.12.0 (both clisp). Maxima gives a very long expression, which is evaluated by float() to something almost equal to the result of romberg().  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1736216&group_id=4933 
From: SourceForge.net <noreply@so...>  20070627 20:47:10

Bugs item #1197361, was opened at 20050507 11:24 Message generated for change (Comment added) made by robert_dodier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1197361&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: 7 Private: No Submitted By: Robert Dodier (robert_dodier) Assigned to: Nobody/Anonymous (nobody) Summary: discrete plot doesn\'t work for openmath or ps plot formats Initial Comment: x: [1, 2, 3]$ y: [1, 2, 3]$ set_plot_option ([plot_format, openmath])$ plot2d ([discrete, x, y])$ => No range given. Must supply range of the form [variable,min,max] set_plot_option ([plot_format, ps ])$ plot2d ([discrete, x, y])$ => No range given. Must supply range of the form [variable,min,max] set_plot_option ([plot_format, gnuplot])$ plot2d ([discrete, x, y])$ => OK set_plot_option ([plot_format, mgnuplot])$ plot2d ([discrete, x, y])$ => OK Maxima version: 5.9.1.1cvs Maxima build date: 6:59 5/5/2005 host type: i686redhatlinuxgnu lispimplementationtype: CLISP lispimplementationversion: 2.33.2 (20040602)  >Comment By: Robert Dodier (robert_dodier) Date: 20070627 14:47 Message: Logged In: YES user_id=501686 Originator: YES plot2d([discrete, x, y]) + openmath format works OK now. Closing this report as fixed.  Comment By: Robert Dodier (robert_dodier) Date: 20060812 09:16 Message: Logged In: YES user_id=501686 Don't bother to fix the ps_format stuff. I'm going to recommend soon to cut it entirely. On the other hand discrete plots do need to work for openmath.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1197361&group_id=4933 
From: SourceForge.net <noreply@so...>  20070627 20:44:08

Bugs item #1190421, was opened at 20050426 10: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=1190421&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: Robert Dodier (robert_dodier) Summary: lisp error in plot3d() Initial Comment: Here is the error: (%i1) plot3d(x**y,[x,0,1],[y,0,1]); Maxima encountered a Lisp error: Error in CATCH [or a callee]: Expected a LONGFLOAT Automatically continuing. To reenable the Lisp debugger set *debuggerhook* to nil. (%i2)  >Comment By: Robert Dodier (robert_dodier) Date: 20070627 14:44 Message: Logged In: YES user_id=501686 Originator: NO Still present in Maxima 5.12.0 (both Clisp and GCL, in different forms). This is annoying; assigning this report to myself in hope that I'll get around to it soon.  Comment By: Raymond Toy (rtoy) Date: 20050819 12:18 Message: Logged In: YES user_id=28849 The actual problem is that when we compute 0.0^0.0, the function returns T. (I think this was done to support adaptive plotting where nonnumber means a singularity of some sort. But we don't do adaptive 3D plotting.) I'd really like it if we could use Lisp conditions to signal these kinds of errors so we can handle them better.  Comment By: Barton Willis (willisbl) Date: 20050426 20:36 Message: Logged In: YES user_id=895922 Avoiding x=0 and y=0 is a workaround plot3d(x^y,[x,0.01,1],[y,0.01,1]); But the error message ' Error in CATCH [or a callee]: Expected a LONGFLOAT' is goofy. There is something wrong that needs to be fixed. Barton  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1190421&group_id=4933 
From: SourceForge.net <noreply@so...>  20070627 20:35:29

Bugs item #1366253, was opened at 20051125 05: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=1366253&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: To be reviewed >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: plot2d(log(x),[x.5,5]) Initial Comment: Using Maxima5.9.2 plot2d(log(x),[x.5,5]) Result is a graph of the log(x)including a mirrored graph concerning the yaxis. When i use wgnuplot.exe directly, this problem does not occur.  >Comment By: Robert Dodier (robert_dodier) Date: 20070627 14:35 Message: Logged In: YES user_id=501686 Originator: NO Just tried the plot_realpart flag in plot2d (both true and false, Windows and Linux, openmath and gnuplot formats). In each case the result is as expected. Closing this report as fixed.  Comment By: Robert Dodier (robert_dodier) Date: 20060813 22:43 Message: Logged In: YES user_id=501686 Code to modify plotting when function value is complex was committed as r1.64 src/plot.lisp. I find with Maxima 5.9.3cvs plot2d(log(x), [x, 5, 5], [plot_format, openmath]); plot2d(log(x), [x, 5, 5], [plot_format, gnuplot]); both show only the region [0, 5] and only one curve (it appears to work for openmath as well as gnuplot). Jaime or someone, can you verify that you also get only one curve in each plot2d ? If so we can close this report as fixed.  Comment By: Jaime E. Villate (villate) Date: 20060627 06:16 Message: Logged In: YES user_id=28692 The previous behavior (plotting the real part when the function gives a complex number) has now been changed. plot2d(log(x),[x,5,5]) will now only show the region where the funtion gives real numbers (x>0). However, the change has not been made for the openmath case. I will work on it. I also think that if the user asks for a plot from x=5, to x=5, the domain should be shown exactly as that, without being cut to x=0 to x=5.  Comment By: Raymond Toy (rtoy) Date: 20051129 12:28 Message: Logged In: YES user_id=28849 This is caused by plot2d plotting the realpart of the function. Not sure if that's what's wanted or not.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1366253&group_id=4933 
From: SourceForge.net <noreply@so...>  20070627 16:50:53

Bugs item #1714044, was opened at 20070507 01:21 Message generated for change (Comment added) made by rtoy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1714044&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: Robert Dodier (robert_dodier) Assigned to: Nobody/Anonymous (nobody) Summary: Maxima asks unnecessary questions in integration Initial Comment: Following example shows Maxima asking a lot of questions, although the result doesn't depend on the answers; I consider that a bug. This is from the mailing list 20070413, "integration asks to many questions". (%i1) p:(1+a*cos(kp*x1)+a*cos(kp*x2)+a*a*cos(kp*x1)*cos(kp*x2))*sin(kp*(x1x2)/4); (%i2) p2:p*(1+c*cos(kp*(x1+x2)/2)); (%i3) integrate(integrate(p2^2,x1,4*%pi/kp,4*%pi/kp),x2,5*%pi/kp/2,7*% pi/kp/2); Is kp positive or negative? p; Is a zero or nonzero? n; Is a c positive, negative, or zero? n; Is c zero or nonzero? n; Is a positive or negative? n; Is c positive or negative? p; Is cos(kp x2) positive, negative, or zero? p; Is kp positive or negative? p; <result here>  >Comment By: Raymond Toy (rtoy) Date: 20070627 12:50 Message: Logged In: YES user_id=28849 Originator: NO A slightly different version of easysubs has been checked in. Problem 209 in rtest15 passes. Closing this report.  Comment By: Raymond Toy (rtoy) Date: 20070613 17:26 Message: Logged In: YES user_id=28849 Originator: NO Oops. There is one difference. Problem 209 in rtest15 returns 2/3/sqrt(2) instead of sqrt(2)/3. But these are equivalent.  Comment By: Raymond Toy (rtoy) Date: 20070613 17:11 Message: Logged In: YES user_id=28849 Originator: NO Here is a replacement for easysubs. If the antiderivative doesn't involve the inverse of a trig function, or hyperbolic function or isn't a log, we can substitute in the limits directly (if they're finite). If the limit succeeds, we are done. This change gets rid of all the questions and doesn't introduce any additional issues in the testsuite. The change is the new line containing involve. (defun easysubs (e ll ul) (cond ((or (infinityp ll) (infinityp ul)) ()) (t (cond ((or (polyinx e var ()) (not (involve e '(%log %asin %acos %atan %asinh %acosh %atanh)))) (let ((llval (noerrsub ll e)) (ulval (noerrsub ul e))) (cond ((and llval ulval) (m ulval llval)) (t ())))) (t ())))))  Comment By: Raymond Toy (rtoy) Date: 20070613 15:01 Message: Logged In: YES user_id=28849 Originator: NO FWIW, the maxima is computing this integral via methodradicalpoly. It can find the antiderivative and is now carefully substituting the limits in via intsubs. Since the antiderivative only involves trig functions (no inverses), there shouldn't be a problem just substituting in the limits. Perhaps easysubs needs to be extended to handle this case?  Comment By: Nobody/Anonymous (nobody) Date: 20070612 23:18 Message: Logged In: NO I had the same silly question when integrating exp(ïky)*hermite(n,x)*x^j  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1714044&group_id=4933 
From: SourceForge.net <noreply@so...>  20070625 23:49:35

Bugs item #1737272, was opened at 20070614 09: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=1737272&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: Closed >Resolution: Wont Fix Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: SELinux blocking maxima startup Initial Comment: (Fedora 7 on a Dell Latitude D510, SELinux running with default policies, maxima 5.12) Starting maxima at the command line or with xmaxima gives: SELinux is preventing /usr/lib/maxima/5.12.0/binarygcl/maxima from changing a writable memory segment executable. SELinux is preventing /usr/lib/maxima/5.12.0/binarygcl/maxima from changing the access protection of memory on the heap. SELinux is preventing /usr/lib/maxima/5.12.0/binarygcl/maxima from loading /usr/lib/maxima/5.12.0/binarygcl/maxima which requires text relocation. I can fix this by turning off the appropriate SELinux Booleans for memory protection, but this isn't that great for system security.  >Comment By: Robert Dodier (robert_dodier) Date: 20070625 17:49 Message: Logged In: YES user_id=501686 Originator: NO Marking this report as "Problem not in Maxima" and "Won't fix". Closing this report.  Comment By: Robert Dodier (robert_dodier) Date: 20070614 19:06 Message: Logged In: YES user_id=501686 Originator: NO I believe this problem is essentially unfixable, given that various Lisp implementations (apparently GCL is among them to judge by the complaints made by SELinux) do things like executing instructions in data areas and other stuff which used to be no big deal, but which are now flagged as dodgy by securityaware systems such as SELinux and WEP (Windows Execution Prevention). So making this problem go away means either (1) telling SELinux to ignore it (maybe you can get SELinux to ignore the problem just for Maxima), or (2) modifying the Lisp implementation (i.e. invest a year or two resolving the problem) or (3) using a different Lisp implementation (unfortunately I do not know which ones avoid the techniques which SELinux complains about; maybe you can ask on comp.lang.lisp or something like that). Sorry I can't be more helpful!  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1737272&group_id=4933 
From: SourceForge.net <noreply@so...>  20070623 23:09:12

Bugs item #1742275, was opened at 20070624 01:09 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=1742275&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: Open Resolution: None Priority: 5 Private: No Submitted By: Harald Geyer (hgeyer) Assigned to: Nobody/Anonymous (nobody) Summary: featurep(false, 'complex) Initial Comment: Currently featurep(false, 'complex) returns true. This is not what I would expect. After looking at the definition of featurep() it becomes obvious, that it returns always true for complex. This test is pointless. I'm not sure in which cases besides true/false this test should be negative. I'm not sure in which cases this test is useful at all. Perhaps this should just be removed from maxima?  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1742275&group_id=4933 
From: SourceForge.net <noreply@so...>  20070622 16:27:36

Bugs item #1552789, was opened at 20060905 12:08 Message generated for change (Comment added) made by rtoy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1552789&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: Raymond Toy (rtoy) Assigned to: Nobody/Anonymous (nobody) Summary: integrate(1/(sin(x)^2+1),x,1,1+%pi) takes forever Initial Comment: This is a followon to Bug [ 1044318 ] defint(1/(sin(x)^2+1),x,0,3*%pi) wrong. integrate(1/(sin(x)^2+1),x,1,1+%pi) seems to take forever. But if the limits are 0 and %pi, the integral is evaluated instantly with the correct value.  >Comment By: Raymond Toy (rtoy) Date: 20070622 12:27 Message: Logged In: YES user_id=28849 Originator: YES This integral no longer takes forever. Don't know how it got fixed. The result is wrong, though. See bug 1741705 Closing this since it no longer directly applies.  Comment By: Raymond Toy (rtoy) Date: 20060906 09:12 Message: Logged In: YES user_id=28849 Looking at the code for ldefint shows why it returns 0. As the docs say, it evaluates the antiderivative and plugs in the limits. I believe this is why defint uses the routine intsubs and samesheetsubs to handle these issues. Perhaps they're not doing what they're supposed to do, but in this particular case, maxima is stuck computing the antiderivative. I don't understand why.  Comment By: Barton Willis (willisbl) Date: 20060906 07:38 Message: Logged In: YES user_id=895922 ldefint gives a wrong answer (basically bug 1044318) (%i10) ldefint(1/(sin(x)^2+1),x,1,1+%pi); (%o10) 0 integrate gives an antiderivative that isn't continuous at odd integer multiples of %pi / 2 (%i11) integrate(1/(sin(x)^2+1),x); (%o11) atan((2*tan(x))/sqrt(2))/sqrt(2) The expression atan(2*tan(x)/sqrt(2))/sqrt(2)+sqrt(2)*%pi*floor(x/%pi1/2)/2 might be a valid antiderivative on all of R provided the first term is assumed left continuous at each odd integer multiple of %pi/2, I think. Barton  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1552789&group_id=4933 
From: SourceForge.net <noreply@so...>  20070622 15:59:28

Bugs item #1741705, was opened at 20070622 11:59 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=1741705&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: Raymond Toy (rtoy) Assigned to: Nobody/Anonymous (nobody) Summary: integrate(1/(sin(x)^2+1),x,0,8) wrong Initial Comment: integrate(1/(sin(x)^2+1),x,0,8) returns sqrt(2)/2*atan(sqrt(2)*tan(8)) + %pi/sqrt(2) This is not right. But integrate(1/(sin(x)^2+1),x,0,5*%pi/2) returns 5*sqrt(2)*%pi/4, which is probably correct according to quad_qags. This latter integral works because intsc1 notices that the interval length is a rational multiple of %pi and breaks up the integral. However, for the former integral, intsc1 gives up because the interval length is not a multiple of %pi. Since we now have a floor function that works well, we should try to extend intsc1 to accept all numeric limits. This issue affects all integrals of trig functions that are handled by intsc1. See also the related bug 1552789.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1741705&group_id=4933 
From: SourceForge.net <noreply@so...>  20070621 16:16:48

Bugs item #1636106, was opened at 20070115 13:17 Message generated for change (Comment added) made by rtoy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1636106&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: Kirill Smelkov (kirr) Assigned to: Nobody/Anonymous (nobody) Summary: integrate(%e^(%i*phi) * A + %e^(%i*phi) * A, phi, 0,2*%pi) Initial Comment: integrate(%e^(%i*phi) * A + %e^(%i*phi) * A, phi, 0,2*%pi) unnessecary ask whether A is pos, neg or zero:: kirr@...:~/study/maxima$ maxima q (%i1) f: %e^(%i*phi) * A + %e^(%i*phi) * A; %i phi  %i phi (%o1) %e A + %e A (%i2) integrate(f, phi, 0,2*%pi); Is A positive, negative, or zero? pos; (%o2) 0 (%i3) build_info(); Maxima version: 5.11.0cvs Maxima build date: 19:58 1/12/2007 host type: i686pclinuxgnu lispimplementationtype: GNU Common Lisp (GCL) lispimplementationversion: GCL 2.6.6  >Comment By: Raymond Toy (rtoy) Date: 20070621 12:16 Message: Logged In: YES user_id=28849 Originator: NO The change to EASYSUBS fixes this issue and maxima doesn't ask questions anymore.  Comment By: Raymond Toy (rtoy) Date: 20070115 19:51 Message: Logged In: YES user_id=28849 Originator: NO FWIW, it asks this question because maxima is looking at limit(2*a*sin(phi), phi, 0, 'plus). I think maxima has already computed the antiderivative and is now substituting the limits of integration (carefully).  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1636106&group_id=4933 
From: SourceForge.net <noreply@so...>  20070621 16:14:57

Bugs item #1671527, was opened at 20070301 04:18 Message generated for change (Comment added) made by rtoy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1671527&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: Pending Resolution: None Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: integrate loops Initial Comment: Hello I had to interrupt maxima when it was at calculating the following integral: (%i101) m(r,th); 2 2 (%o101) SQRT(z + 2 r rM (1  COS(th)) + (rM  r) ) (%i102) F(d); 2 2 d0 4 A d0 (epsi   + 1) w 2 d (%o102)   3 d (%i103) integrate(1/m(th,r)^2*F(m(th,r))*z^2,th,0,%PI); 2 2 2 2 Is z  COS (r) rM + rM positive, negative, or zero? pos; 2 2 2 Is z + (1  COS (r)) rM positive, negative, or zero? pos; Maxima encountered a Lisp error: Console interrupt. Best wishes, Jocelyn  >Comment By: Raymond Toy (rtoy) Date: 20070621 12:14 Message: Logged In: YES user_id=28849 Originator: NO No additional information from poster. Marking as Pending  Comment By: Raymond Toy (rtoy) Date: 20070307 10:30 Message: Logged In: YES user_id=28849 Originator: NO What is the integrand? You have the function m(r,th), but the integral says m(th,r). Given the limits of 0 and %pi, I think your integrand is wrong. Did you really want m(r,th)?  Comment By: Raymond Toy (rtoy) Date: 20070302 21:59 Message: Logged In: YES user_id=28849 Originator: NO It does seem to loop. Not sure if it really does, because I didn't wait for very long. Note, however, that all of the integrals are of the form 1/(th^2+a*th*b)^(n/2) where n is odd (5 or 7 here). Maxima can evaluate all of these integrals quite quickly. I think, but I'm not sure, that maxima is busy simplifying complicated intermediate expressions because the coefficients are not simple.  Comment By: Nobody/Anonymous (nobody) Date: 20070301 04:22 Message: Logged In: NO sorry about the mess... the functions are: m(r,th):=sqrt(z^2+(rMr)^2+2*rM*r*(1cos(th))); and F(d):=4*w/d*(d0/d)^2*(1+epsi(d0/d)^2)*A;  Comment By: Nobody/Anonymous (nobody) Date: 20070301 04:19 Message: Logged In: NO Version is Maxima 5.9.1  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1671527&group_id=4933 
From: SourceForge.net <noreply@so...>  20070621 15:13:14

Bugs item #1732298, was opened at 20070606 12:47 Message generated for change (Comment added) made by robert_dodier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1732298&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: Ted Woollett (woollett) >Assigned to: Vadim V. Zhytnikov (vvzhy) Summary: postscript eps file error Initial Comment: use of standard eps file generation, as in: (%i2) plot2d( sin(x),[x,%pi, %pi] ,[gnuplot_term,ps], [gnuplot_out_file,"c:/work2/test2.eps" ] ) $ Output file "c:/work2/test2.eps". results in the generation of test2.eps which is 2kb and contains no plot instructions. The end of the file has an apparent error message(? I am no expert in postscript language ): ... /hpt hpt_ def /vpt vpt_ def Level1 {} { /SDict 10 dict def systemdict /pdfmark known not { userdict /pdfmark systemdict /cleartomark get put } if SDict begin [ /Title (c:/work2/test2.eps) /Subject (gnuplot plot) /Creator (gnuplot 4.2 patchlevel 0) /Author (Edwin Woollett) % /Producer (gnuplot) % /Keywords () /CreationDate (Wed Jun 06 10:38:32 2007) /DOCINFO pdfmark end } ifelse When viewed with gsview32, there in no plot. Direct use of wguplot32 software results in a file of size about 14 kb. This error observed with both v 5.11.xx and 5.12: My build info: Maxima version: 5.12.0 Maxima build date: 19:33 5/3/2007 host type: i686pcmingw32 lispimplementationtype: GNU Common Lisp (GCL) lispimplementationversion: GCL 2.6.8 Edwin (Ted) Woollett  >Comment By: Robert Dodier (robert_dodier) Date: 20070621 09:13 Message: Logged In: YES user_id=501686 Originator: NO >From what I can tell, the Maxima 5.12.0 Windows installation is missing a file that Gnuplot wants, namely prologue.ps. I've taken the liberty of attaching the prologue.ps from Gnuplot 4.2 to this report. That file should be copied to ...\Maxima5.12.0\bin\share\PostScript\prologue.ps in the Maxima installation. Please give that a try and let us know how it turns out. File Added: prologue.ps  Comment By: Ted Woollett (woollett) Date: 20070607 11:36 Message: Logged In: YES user_id=1806103 Originator: YES I observed this eps file bug on my Win XP box and using Maxima 5.11.99 and 5.12.0 A milder version appears in ver 5.9.3 in which Maxima complained but produced a viewable plot as viewed with gsview32. The 5.9.3 complaint looks like: Maxima 5.9.3 http://maxima.sourceforge.net Using Lisp GNU Common Lisp (GCL) GCL 2.6.7 (aka GCL) (%i1) plot2d( sin(x),[x,%pi, %pi] ,[gnuplot_term,ps], [gnuplot_out_file,"c:/work2/test6.eps" ] ) $ 'ghostview' is not recognized as an internal or external command, operable program or batch file. Output file "c:/work2/test6.eps". (%i2)  Comment By: Robert Dodier (robert_dodier) Date: 20070606 19:02 Message: Logged In: YES user_id=501686 Originator: NO Same error observed on my Win XP box + Maxima 5.12.0. However it works as expected with Maxima 5.11.0 on same Win XP box, and with Maxima 5.12.0 on Linux.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1732298&group_id=4933 