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}
(24) 
_{Feb}

_{Mar}

_{Apr}

_{May}

_{Jun}

_{Jul}

_{Aug}

_{Sep}

_{Oct}

_{Nov}

_{Dec}

S  M  T  W  T  F  S 



1
(2) 
2
(3) 
3
(12) 
4
(12) 
5
(6) 
6
(1) 
7
(2) 
8

9
(3) 
10
(4) 
11
(4) 
12
(6) 
13
(3) 
14
(1) 
15
(4) 
16

17

18

19
(6) 
20
(5) 
21

22
(2) 
23
(1) 
24
(4) 
25

26

27
(1) 
28

29
(2) 
30
(1) 



From: SourceForge.net <noreply@so...>  20100630 02:20:05

Bugs item #3014845, was opened at 20100611 14:10 Message generated for change (Settings changed) made by sfrobot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3014845&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: Closed Resolution: Wont Fix Priority: 5 Private: No Submitted By: Derek O'Connor (derekroconnor) Assigned to: Nobody/Anonymous (nobody) Summary: sin(1e22) is wrong Initial Comment: sin(1e22); (%o1) 0.41214336710708 The correct answer is 8.522008497671888 Please note that 10^22 is exactly representable as an IEEE double precision floating point number, whose binary representation is 10^22 = 1000011110000110011110000011001001101110101011001001 x 2^22 This incorrect result suggests that the rangereduction step, where the argument x is reduced to lie in a small interval around 0, such as [pi/2,+pi/2], has not been done properly. This means that the other trigonometric functions will be incorrect. This value 10^22 was carefully chosen by Ng to uncover faulty range reduction: http://www.derekroconnor.net/Software/NgArgReduction.pdf Maxima is not alone: R, Octave, Freemat, Euler, Python, and Lua have the same problem. Matlab used to have this problem but fixed it. I am neither a systems programmer nor a Maxima developer so I don't know what is going on in the background. I suspect that the mingw32 system may be at fault. If so, this prompts the question: do Maxima developers not check the components they are using? Maxima version: 5.21.1 Maxima build date: 8:13 4/26/2010 Host type: i686pcmingw32 Lisp implementation type: GNU Common Lisp (GCL) Lisp implementation version: GCL 2.6.8 Dell Precision 690, Intel 2xQuadCore E5345 @ 2.33GHz 16GB RAM, Windows7 64bit Professional. Derek O'Connor  >Comment By: SourceForge Robot (sfrobot) Date: 20100630 02:20 Message: This Tracker item was closed automatically by the system. It was previously set to a Pending status, and the original submitter did not respond within 14 days (the time period specified by the administrator of this Tracker).  Comment By: Robert Dodier (robert_dodier) Date: 20100615 05:20 Message: For the record, Clozure CL (Version 1.4r13122 on Windows Vista) returns (sin 1d22) => 0.41214336710708466D0. I agree with Ray T that these are bugs in the Lisp implementation. I don't think Maxima should try to replace all of the math functions in Lisp, so we have to rely on the Lisp implementation for sin and other functions. If someone has time to report these bugs to the Lisp implementations bug trackers, that would be terrific.  Comment By: Raymond Toy (rtoy) Date: 20100615 02:05 Message: I think it would be best to ask on the mailing list to see if someone can do a windows build with gcl using ming64. Or ask on the gcl list if there's a mingw64 version. Setting this to pending/wontfix again.  Comment By: Derek O'Connor (derekroconnor) Date: 20100613 09:54 Message: The bug is not really in gcl but in ming32. R 2.11.0 under ming32 gives the wrong answer while R 2.11.0 under ming64 gives the right answer. Is it possible to get a version of Maxima (or gcl) that uses ming64?  Comment By: Raymond Toy (rtoy) Date: 20100613 02:00 Message: As I mentioned, I consider this a bug in gcl, not maxima. Although I could fix it, I'm not inclined to do so. It would be a lot of work to do and to support just for gcl when ccl, I think, produces the correct result. (It does on Mac OS X.)  Comment By: Derek O'Connor (derekroconnor) Date: 20100612 22:56 Message: I am NOT concerned about bfloat(sin(10^22)) or sin(bfloat(10^22)). I am concerned that sin(10^22) gives the wrong answer on my system, and presumably, on many similar systems.  Comment By: Aleksas Domarkas (alex108) Date: 20100612 09:30 Message: (%i1) fpprec : 32; (%o1) 32 (%i2) bfloat(sin(10^22)); (%o2) 8.5220084976718880177270589375303b1 (%i3) build_info()$ Maxima version: 5.21.1 Maxima build date: 8:13 4/26/2010 Host type: i686pcmingw32 Lisp implementation type: GNU Common Lisp (GCL) Lisp implementation version: GCL 2.6.8  Comment By: Raymond Toy (rtoy) Date: 20100611 22:40 Message: Maxima computes sin(1e22) by defering to the Lisp implementation to evaluate it. Gcl produces the incorrect answer. Maxima with cmucl produces 0.8522008497671888, as you expect. I consider this a bug in gcl, not maxima. Marking as pending/wontfix.  Comment By: Derek O'Connor (derekroconnor) Date: 20100611 18:38 Message: CORRECTION: 8.522008497671888 should be 0.8522008497671888 Derek O'Connor  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3014845&group_id=4933 
From: SourceForge.net <noreply@so...>  20100629 16:03:27

Bugs item #3022819, was opened at 20100629 14:34 Message generated for change (Comment added) made by l_butler You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3022819&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: Maxima crashes Initial Comment: Maxima version: 5.17.1 Maxima build date: 14:9 7/13/2009 host type: i686pclinuxgnu lispimplementationtype: GNU Common Lisp (GCL) lispimplementationversion: GCL 2.6.7 wolong@...:~$ maxima Maxima 5.17.1 http://maxima.sourceforge.net Using Lisp GNU Common Lisp (GCL) GCL 2.6.7 (aka GCL) Distributed under the GNU Public License. See the file COPYING. Dedicated to the memory of William Schelter. The function bug_report() provides bug reporting information. (%i1) sqrt(9); Universal error handler called recursively (:ERROR NIL CONDITIONS::CLCSUNIVERSALERRORHANDLER "" "Couldn't protect") Universal error handler called recursively (:ERROR NIL CONDITIONS::CLCSUNIVERSALERRORHANDLER "" "Couldn't protect") Maxima encountered a Lisp error: Error in CONDITIONS::CLCSUNIVERSALERRORHANDLER [or a callee]: Caught fatal error [memory may be damaged] Automatically continuing. To reenable the Lisp debugger set *debuggerhook* to nil. (%i2)  >Comment By: Leo Butler (l_butler) Date: 20100629 17:03 Message: Could you tell me if you installed this package from your linux distribution's repository? If so, which distribution?  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3022819&group_id=4933 
From: SourceForge.net <noreply@so...>  20100629 13:34:04

Bugs item #3022819, was opened at 20100629 13:34 Message generated for change (Tracker Item Submitted) made by nobody You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3022819&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: Maxima crashes Initial Comment: Maxima version: 5.17.1 Maxima build date: 14:9 7/13/2009 host type: i686pclinuxgnu lispimplementationtype: GNU Common Lisp (GCL) lispimplementationversion: GCL 2.6.7 wolong@...:~$ maxima Maxima 5.17.1 http://maxima.sourceforge.net Using Lisp GNU Common Lisp (GCL) GCL 2.6.7 (aka GCL) Distributed under the GNU Public License. See the file COPYING. Dedicated to the memory of William Schelter. The function bug_report() provides bug reporting information. (%i1) sqrt(9); Universal error handler called recursively (:ERROR NIL CONDITIONS::CLCSUNIVERSALERRORHANDLER "" "Couldn't protect") Universal error handler called recursively (:ERROR NIL CONDITIONS::CLCSUNIVERSALERRORHANDLER "" "Couldn't protect") Maxima encountered a Lisp error: Error in CONDITIONS::CLCSUNIVERSALERRORHANDLER [or a callee]: Caught fatal error [memory may be damaged] Automatically continuing. To reenable the Lisp debugger set *debuggerhook* to nil. (%i2)  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3022819&group_id=4933 
From: SourceForge.net <noreply@so...>  20100627 10:39:11

Bugs item #3021964, was opened at 20100627 11:39 Message generated for change (Tracker Item Submitted) made by hbraviner You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3021964&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: Harry Braviner (hbraviner) Assigned to: Nobody/Anonymous (nobody) Summary: taylor can return wrong answer on sqrt(abs()) Initial Comment: Suppose I wish to expand sqrt(abs(r^21)) for large r. In the large r limit we can take r^2 1 to be positive and abs(r^2  1) evaluates to r^2  1. I then pull out a factor of r from the sqrt() and do a Taylor expansion in negative powers of r. The series I get should be r  (1/2)*r^(1)  (1/8) *r^(3) + ... To do this in maxima, I should call the function taylor(sqrt(abs(r^21)),[r,0,3,'asymp]). However, this returns %i*r%i/(2*r)%i/(8*r^3)+... I believe this is because the abs() function is evaluated at r=0 (as indeed it should be if we were taking a Taylor series in positive powers of r about 0), since expanding instead around r=2 produces the same answer regardless of whether of not abs() is present.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3021964&group_id=4933 
From: SourceForge.net <noreply@so...>  20100624 19:57:27

Bugs item #3020243, was opened at 20100623 11:53 Message generated for change (Comment added) made by rtoy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3020243&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: defint(exp(cos(x))*cos(sin(x)),x,0,2*%pi) wrong result 0 Initial Comment: The correct result is 2*%pi. This is a new bug appearing in version 5.21.1. Previous versions (<= 5.20.1 ) return just the integral expression unevaluated, which is fair enough, but most importantly is not a wrong result. Maxima version: 5.21.1 Maxima build date: 8:13 4/26/2010 Host type: i686pcmingw32 also on linux system (fedora11) Lisp implementation type: GNU Common Lisp (GCL) also with cmucl Lisp implementation version: GCL 2.6.8 also with cmucl 19f  >Comment By: Raymond Toy (rtoy) Date: 20100624 15:57 Message: Expanding does produce a better answer. The derivative does equal the integrand. Plotting realpart(%o3 )shows a discontinuity near %pi. (Perhaps it's a bug, but plot2d(%o3,[x,0,%pi]) produces a warning that a nonnumeric value occurs somewhere. It seems as if it occurs everywhere except at 0.)  Comment By: Dieter Kaiser (crategus) Date: 20100624 14:42 Message: We get a more simple result when expanding the function gamma_incomplete: (%i3) integrate(exp(cos(x))*cos(sin(x)),x),gamma_expand:true; (%o3) (%i*expintegral_ei(%e^(%i*x))%i*expintegral_ei(%e^(%i*x)))/2 I think this result is correct, as a reference I have compared the result with wolfram alpha. But nevertheless, the definite integral is wrong and I am wondering why the conjugate function is introduced in the unsimplified result. Dieter Kaiser  Comment By: Raymond Toy (rtoy) Date: 20100624 14:18 Message: This particular integral is evaluated by computing the antiderivative. Perhaps in earlier versions, maxima could not, but maxima can now. So integrate(exp(cos(x))*cos(sin(x)),x) returns: (%i*conjugate(gamma_incomplete(0,%e^(%i*x))) %i*conjugate(gamma_incomplete(0,%e^(%i*x))) %i*gamma_incomplete(0,%e^(%i*x))+%i*gamma_incomplete(0,%e^(%i*x))) /4 Somehow this doesn't look right. Don't know if this is the correct antiderivative or not, but that's how maxima gets zero for the answer. At x=0, the result is zero, and by periodicity x=2*%pi is also zero. The wrong branch cut is taken, assuming the antiderivative is correct.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3020243&group_id=4933 
From: SourceForge.net <noreply@so...>  20100624 18:42:51

Bugs item #3020243, was opened at 20100623 17:53 Message generated for change (Comment added) made by crategus You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3020243&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: defint(exp(cos(x))*cos(sin(x)),x,0,2*%pi) wrong result 0 Initial Comment: The correct result is 2*%pi. This is a new bug appearing in version 5.21.1. Previous versions (<= 5.20.1 ) return just the integral expression unevaluated, which is fair enough, but most importantly is not a wrong result. Maxima version: 5.21.1 Maxima build date: 8:13 4/26/2010 Host type: i686pcmingw32 also on linux system (fedora11) Lisp implementation type: GNU Common Lisp (GCL) also with cmucl Lisp implementation version: GCL 2.6.8 also with cmucl 19f  >Comment By: Dieter Kaiser (crategus) Date: 20100624 20:42 Message: We get a more simple result when expanding the function gamma_incomplete: (%i3) integrate(exp(cos(x))*cos(sin(x)),x),gamma_expand:true; (%o3) (%i*expintegral_ei(%e^(%i*x))%i*expintegral_ei(%e^(%i*x)))/2 I think this result is correct, as a reference I have compared the result with wolfram alpha. But nevertheless, the definite integral is wrong and I am wondering why the conjugate function is introduced in the unsimplified result. Dieter Kaiser  Comment By: Raymond Toy (rtoy) Date: 20100624 20:18 Message: This particular integral is evaluated by computing the antiderivative. Perhaps in earlier versions, maxima could not, but maxima can now. So integrate(exp(cos(x))*cos(sin(x)),x) returns: (%i*conjugate(gamma_incomplete(0,%e^(%i*x))) %i*conjugate(gamma_incomplete(0,%e^(%i*x))) %i*gamma_incomplete(0,%e^(%i*x))+%i*gamma_incomplete(0,%e^(%i*x))) /4 Somehow this doesn't look right. Don't know if this is the correct antiderivative or not, but that's how maxima gets zero for the answer. At x=0, the result is zero, and by periodicity x=2*%pi is also zero. The wrong branch cut is taken, assuming the antiderivative is correct.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3020243&group_id=4933 
From: SourceForge.net <noreply@so...>  20100624 18:18:39

Bugs item #3020243, was opened at 20100623 11:53 Message generated for change (Comment added) made by rtoy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3020243&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: defint(exp(cos(x))*cos(sin(x)),x,0,2*%pi) wrong result 0 Initial Comment: The correct result is 2*%pi. This is a new bug appearing in version 5.21.1. Previous versions (<= 5.20.1 ) return just the integral expression unevaluated, which is fair enough, but most importantly is not a wrong result. Maxima version: 5.21.1 Maxima build date: 8:13 4/26/2010 Host type: i686pcmingw32 also on linux system (fedora11) Lisp implementation type: GNU Common Lisp (GCL) also with cmucl Lisp implementation version: GCL 2.6.8 also with cmucl 19f  >Comment By: Raymond Toy (rtoy) Date: 20100624 14:18 Message: This particular integral is evaluated by computing the antiderivative. Perhaps in earlier versions, maxima could not, but maxima can now. So integrate(exp(cos(x))*cos(sin(x)),x) returns: (%i*conjugate(gamma_incomplete(0,%e^(%i*x))) %i*conjugate(gamma_incomplete(0,%e^(%i*x))) %i*gamma_incomplete(0,%e^(%i*x))+%i*gamma_incomplete(0,%e^(%i*x))) /4 Somehow this doesn't look right. Don't know if this is the correct antiderivative or not, but that's how maxima gets zero for the answer. At x=0, the result is zero, and by periodicity x=2*%pi is also zero. The wrong branch cut is taken, assuming the antiderivative is correct.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3020243&group_id=4933 
From: SourceForge.net <noreply@so...>  20100624 03:46:15

Bugs item #3020589, was opened at 20100624 13:46 Message generated for change (Tracker Item Submitted) made by peterc_555 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3020589&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: Peter Cusack (peterc_555) Assigned to: Nobody/Anonymous (nobody) Summary: xlabel and ylabel don't change plot3d axis labels Initial Comment: WhenI use plot2d(Bxt(x,0),[x,0,Rs*2],[xlabel,"x [m]"],[ylabel,"Bx [T]"],[legend,"0mm"])$ the label on the x axis is changed as I expect. When I use plot3d(Bxt(x,r),[x,0,L],[r,0,R],[xlabel,"x [m]"],[ylabel,"r [m]"],[zlabel,"Bx [T]"],[legend,"Axial field"])$ only the z axis label is changed. The x axis label is simply "x" and the y axis is simply "r" as picked up from the expression. Manually editing maxout.gnuplot (from wxMaxima) works, so it doesn't seem like gnuplot ignores the input. Maxima version: 5.21.1 Maxima build date: 8:13 4/26/2010 Host type: i686pcmingw32 Lisp implementation type: GNU Common Lisp (GCL) Lisp implementation version: GCL 2.6.8  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3020589&group_id=4933 
From: SourceForge.net <noreply@so...>  20100623 15:53:28

Bugs item #3020243, was opened at 20100623 15:53 Message generated for change (Tracker Item Submitted) made by nobody You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3020243&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: defint(exp(cos(x))*cos(sin(x)),x,0,2*%pi) wrong result 0 Initial Comment: The correct result is 2*%pi. This is a new bug appearing in version 5.21.1. Previous versions (<= 5.20.1 ) return just the integral expression unevaluated, which is fair enough, but most importantly is not a wrong result. Maxima version: 5.21.1 Maxima build date: 8:13 4/26/2010 Host type: i686pcmingw32 also on linux system (fedora11) Lisp implementation type: GNU Common Lisp (GCL) also with cmucl Lisp implementation version: GCL 2.6.8 also with cmucl 19f  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3020243&group_id=4933 
From: SourceForge.net <noreply@so...>  20100622 19:01:13

Bugs item #859902, was opened at 20031214 10: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=859902&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: Robert Dodier (robert_dodier) Assigned to: Nobody/Anonymous (nobody) >Summary: recursive calls not correctly accounted in timing Initial Comment: TIMER_INFO gets units of time mixed up  in the example below, should show 0.25 seconds instead of 25 seconds; setting TIMER_DEVALUE:TRUE before calling FF(200) makes the time come out as 0.25 seconds as expected. Note that the time reported for GG is 25 seconds while the time for FF is 0.25 seconds  the two should be identical or nearly so. See also bug report #572835 ("timer_info gives incorrect time"). Maxima 5.9.0 cvs version of 20031128, clisp 2.31, redhat linux 7.1 (kernel 2.4.2).  begin example about timing_info  (C1) GG(n):=if equal(n,0) then 0 else n+GG(n1); (D1) GG(n) := IF EQUAL(n, 0) THEN 0 ELSE n + GG(n  1) (C2) FF(n):=GG(n); (D2) FF(n) := GG(n) (C3) timer(FF,GG); (D3) [FF, GG] (C4) timer_info(); [ FUNCTION TIME//CALL CALLS RUNTIME GCTIME ] [ ] [ GG 0 0 0 0 ] (D4) [ ] [ FF 0 0 0 0 ] [ ] [ TOTAL 0 0 0 0 ] (C5) FF(200); (D5) 20100 (C6) timer_info(); [ FUNCTION TIME//CALL CALLS RUNTIME GCTIME ] [ ] [ GG .1262686567164179 SEC 201 25.38 SEC 0 ] (D6) [ ] [ FF 0.25 SEC 1 0.25 SEC 0 ] [ ] [ TOTAL .1268811881188119 SEC 202 25.63 SEC 0 ]  end example about timing_info   >Comment By: Robert Dodier (robert_dodier) Date: 20100622 13:01 Message: Looks like problem was misidentified before, therefore changing summary.  Comment By: Robert Dodier (robert_dodier) Date: 20100622 10:35 Message: Reopening this report. On looking at this again, it appears that the problem is that Maxima is not correctly accounting for time spent in recursive calls in GG, and that this problem still exists.  Comment By: SourceForge Robot (sfrobot) Date: 20091117 19:20 Message: 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: Dieter Kaiser (crategus) Date: 20091103 15:09 Message: I think we have no longer a problem with the function timer_info. The time per call for the reported example is not very accurate, but the values are sumed correctly. (%i3) GG(n):=if equal(n,0) then 0 else GG(n1)+n (%i4) FF(n):=GG(n) (%i5) timer(FF,GG) (%i6) FF(500) (%i7) timer_info() (%o7) matrix([function,time\/\/call,calls,runtime,gctime], [GG,.07129367864271456*sec,501,35.718133*sec,0], [FF,0.144009*sec,1,0.144009*sec,0], [total,.07143852988047808*sec,502,35.862142*sec,0]) This is an example for a function which needs much more time: (%i8) ff(x):=block([fpprec:x],gamma_incomplete(5.0b1,1.0b0),done) The first call is needed to initialize internal values: (%i9) ff(1024) (%i10) untimer(FF,GG) (%i11) timer(ff) On my (slow) computer the function needs about 2.7 seconds per call. This is displayed correctly: (%i12) ff(1024) (%i13) timer_info() (%o13) matrix([function,time\/\/call,calls,runtime,gctime], [ff,2.684167*sec,1,2.684167*sec,0], [total,2.684167*sec,1,2.684167*sec,0]) Further calls are added up correctly: (%i14) ff(1024) (%i15) timer_info() (%o15) matrix([function,time\/\/call,calls,runtime,gctime], [ff,2.708169*sec,2,5.416338*sec,0], [total,2.708169*sec,2,5.416338*sec,0]) (%i16) ff(1024) (%i17) timer_info() (%o17) matrix([function,time\/\/call,calls,runtime,gctime], [ff,2.654832333333333*sec,3,7.964497*sec,0], [total,2.654832333333333*sec,3,7.964497*sec,0]) Setting the status to "pending" and "works for me". Dieter Kaiser  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=859902&group_id=4933 
From: SourceForge.net <noreply@so...>  20100622 16:35:48

Bugs item #859902, was opened at 20031214 10: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=859902&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: Robert Dodier (robert_dodier) Assigned to: Nobody/Anonymous (nobody) Summary: TIMING_INFO gets time units mixed up Initial Comment: TIMER_INFO gets units of time mixed up  in the example below, should show 0.25 seconds instead of 25 seconds; setting TIMER_DEVALUE:TRUE before calling FF(200) makes the time come out as 0.25 seconds as expected. Note that the time reported for GG is 25 seconds while the time for FF is 0.25 seconds  the two should be identical or nearly so. See also bug report #572835 ("timer_info gives incorrect time"). Maxima 5.9.0 cvs version of 20031128, clisp 2.31, redhat linux 7.1 (kernel 2.4.2).  begin example about timing_info  (C1) GG(n):=if equal(n,0) then 0 else n+GG(n1); (D1) GG(n) := IF EQUAL(n, 0) THEN 0 ELSE n + GG(n  1) (C2) FF(n):=GG(n); (D2) FF(n) := GG(n) (C3) timer(FF,GG); (D3) [FF, GG] (C4) timer_info(); [ FUNCTION TIME//CALL CALLS RUNTIME GCTIME ] [ ] [ GG 0 0 0 0 ] (D4) [ ] [ FF 0 0 0 0 ] [ ] [ TOTAL 0 0 0 0 ] (C5) FF(200); (D5) 20100 (C6) timer_info(); [ FUNCTION TIME//CALL CALLS RUNTIME GCTIME ] [ ] [ GG .1262686567164179 SEC 201 25.38 SEC 0 ] (D6) [ ] [ FF 0.25 SEC 1 0.25 SEC 0 ] [ ] [ TOTAL .1268811881188119 SEC 202 25.63 SEC 0 ]  end example about timing_info   >Comment By: Robert Dodier (robert_dodier) Date: 20100622 10:35 Message: Reopening this report. On looking at this again, it appears that the problem is that Maxima is not correctly accounting for time spent in recursive calls in GG, and that this problem still exists.  Comment By: SourceForge Robot (sfrobot) Date: 20091117 19:20 Message: 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: Dieter Kaiser (crategus) Date: 20091103 15:09 Message: I think we have no longer a problem with the function timer_info. The time per call for the reported example is not very accurate, but the values are sumed correctly. (%i3) GG(n):=if equal(n,0) then 0 else GG(n1)+n (%i4) FF(n):=GG(n) (%i5) timer(FF,GG) (%i6) FF(500) (%i7) timer_info() (%o7) matrix([function,time\/\/call,calls,runtime,gctime], [GG,.07129367864271456*sec,501,35.718133*sec,0], [FF,0.144009*sec,1,0.144009*sec,0], [total,.07143852988047808*sec,502,35.862142*sec,0]) This is an example for a function which needs much more time: (%i8) ff(x):=block([fpprec:x],gamma_incomplete(5.0b1,1.0b0),done) The first call is needed to initialize internal values: (%i9) ff(1024) (%i10) untimer(FF,GG) (%i11) timer(ff) On my (slow) computer the function needs about 2.7 seconds per call. This is displayed correctly: (%i12) ff(1024) (%i13) timer_info() (%o13) matrix([function,time\/\/call,calls,runtime,gctime], [ff,2.684167*sec,1,2.684167*sec,0], [total,2.684167*sec,1,2.684167*sec,0]) Further calls are added up correctly: (%i14) ff(1024) (%i15) timer_info() (%o15) matrix([function,time\/\/call,calls,runtime,gctime], [ff,2.708169*sec,2,5.416338*sec,0], [total,2.708169*sec,2,5.416338*sec,0]) (%i16) ff(1024) (%i17) timer_info() (%o17) matrix([function,time\/\/call,calls,runtime,gctime], [ff,2.654832333333333*sec,3,7.964497*sec,0], [total,2.654832333333333*sec,3,7.964497*sec,0]) Setting the status to "pending" and "works for me". Dieter Kaiser  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=859902&group_id=4933 
From: SourceForge.net <noreply@so...>  20100620 05:45:58

Bugs item #3012427, was opened at 20100607 02: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=3012427&group_id=4933 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Share Libraries Group: None >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Samgar Reichert (mrstamper) Assigned to: Nobody/Anonymous (nobody) Summary: tex2ooo.lisp invalid output Initial Comment: load(tex2ooo); A:matrix( [1,2], [3,4]); tex(A); outputs: left( matrix {1 # 2 ## 3 # 4 ## } right) This code is invalid. It must be: left( matrix {1 # 2 ## 3 # 4 } right)  >Comment By: Robert Dodier (robert_dodier) Date: 20100619 23:45 Message: Omit final ## in matrix output (r1.9 share/contrib/tex2ooo.lisp). Closing this report as fixed.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3012427&group_id=4933 
From: SourceForge.net <noreply@so...>  20100620 04:50:11

Bugs item #3009011, was opened at 20100529 11:48 Message generated for change (Settings changed) made by robert_dodier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3009011&group_id=4933 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Lisp Core  Plotting Group: None >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: plot3d syntax Initial Comment: When plot3d is invoked with the reasonable but incorrect syntax plot3d([x*y,x*y^2],[x,0,1],[y,0,1]) it gives an error message. The trouble is that this message claims it is the correct syntax: ... Several functions depending on the two variables v1 and v2: plot3d ([f1, f2, ..., fn], [v1, min, max], [v2, min, max], options) ... The correct syntax can be found from describe(plot3d).  >Comment By: Robert Dodier (robert_dodier) Date: 20100619 22:50 Message: Changed comment to match actual behavior (r1.161 src/plot.lisp). Closing this report as fixed.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3009011&group_id=4933 
From: SourceForge.net <noreply@so...>  20100620 02:20:10

Bugs item #1959214, was opened at 20080507 04:36 Message generated for change (Comment added) made by sfrobot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1959214&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: Satoshi Adachi (satoshi_adachi) Assigned to: Nobody/Anonymous (nobody) Summary: integrate() and array having lisp style name Initial Comment: Dear Developer of Maxima, I found that integrate() returns a wrong result if an array that has a lisp name ``?...'' is used in the argument of integrate(). Here is a demonstration program:  /* * integrate_and_array_of_lisp_name.maxima: * * S.Adachi 2008/05/06 */ display2d:false; integrate(1,?a[1],0,?a[2]); /* Maxima result ?a[1][2] should be ?a[2]. */ /* END */  The result of execution is as follows:  Maxima 5.14.0cvs http://maxima.sourceforge.net Using Lisp GNU Common Lisp (GCL) GCL 2.6.7 (aka GCL) Distributed under the GNU Public License. See the file COPYING. Dedicated to the memory of William Schelter. The function bug_report() provides bug reporting information. (%i1) batch(integrate_and_array_of_lisp_name.maxima) batching #p/Volumes/HFS+2/home/adachi/work/294/integrate_and_array_of_lisp_name.maxima (%i2) display2d : false (%o2) false (%i3) integrate(1,?a[1],0,?a[2]) (%o3) ?a[1][2] (%o4) "integrate_and_array_of_lisp_name.maxima"  The correct value of this integration is ?a[2]. But Maxima returns ?a[1][2], which is wrong. I think that this is a bug of Maxima. In the following, I want to explain the situation in which I met the above bug of Maxima in order to motivate the kind Maxima developers to take the action to actually fix this bug. When I am writing a program in Maxima, I sometimes need an array that has some name which is unique and is dynamically determined in execution. In such a situation, I write a code like A:?gensym(), apply('array, [A,n]), ... < Work with dynamical array A > .. apply('remarray, [A]) The variable A stores a name ``?g....'' of the dynamical array that is generated. This name ``?g....'' is a lisp style name. In the present case, the work is to prepare a function of elements of the dynamical array and integrate the function. Then, when the written program is executed, it tells me that Maxima has the bug that I am now reporting. I hope that any variable in Maxima should not be discreminated by the reason that the variable simply has a lisp name. If it is so, what I am now reporting is truely a bug of Maxima, which is serious for people who write Maxima programs. Please fix this bug of Maxima. Sincerely yours, Satoshi Adachi P.S. (i) As a temporal workaround to write Maxima programs, I replace the line "A:?gensym()," in the above example by a line "A:eval_string(substring(string(?gensym()),2))," to use a Maxima style name "g...." instead of a lisp style name "?g...." (and keep being carefull not to use any name "g...." for other Maxima variables). This is an ugry workaround. (ii) If there is a better or standard way in Maxima to prepare some dynamical array that has a unique name on fly, please let me know. If someone tells me it, I will be happy.  >Comment By: SourceForge Robot (sfrobot) Date: 20100620 02:20 Message: 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: Dieter Kaiser (crategus) Date: 20100605 21:50 Message: A Maxima user function gensym has been implemented in mutils.lisp revision 1.10. The documentation is in Miscellaneous.texi revision 1.27. This function can be used for the example of this bug report. I would like to suggest to close this bug report as fixed. Dieter Kaiser  Comment By: Robert Dodier (robert_dodier) Date: 20080622 22:13 Message: Logged In: YES user_id=501686 Originator: NO Here is a slightly different workaround. :lisp (defun $gensym () (cadr (dollarify (list (gensym))))) Then you can write A:gensym() instead of A:?gensym() and the generated symbols are Maxima identifiers (because they have the leading $ in the name).  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1959214&group_id=4933 
From: SourceForge.net <noreply@so...>  20100620 01:22:32

Bugs item #3013990, was opened at 20100609 15:41 Message generated for change (Comment added) made by robert_dodier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3013990&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: Documentation Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Alexey Beshenov (beshenov) Assigned to: Nobody/Anonymous (nobody) Summary: reduce functions in nset.texi Initial Comment: Although lreduce, rreduce, tree_reduce, and xreduce come from the set package, they operate on lists. Isn't it better to move the corresponding documentation from nset.texi to Lists.texi?  >Comment By: Robert Dodier (robert_dodier) Date: 20100619 19:22 Message: OK by me to move the documentation as suggested.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3013990&group_id=4933 
From: SourceForge.net <noreply@so...>  20100620 01:19:47

Bugs item #3014545, was opened at 20100610 14:52 Message generated for change (Comment added) made by robert_dodier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3014545&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: Works For Me Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: submatrix does not work as expected Initial Comment: submatrix(10,20,zeromatrix(20,20)); does not delete any rows. It returns zeromatrix(20,20) also submatrix(3,5,F,3,5); matrix([1,1,1],[1,1,1],[1,1,1]) and submatrix(2,5,F,2,5); do the exact same thing. I'm running Maxima 5.21.1 http://maxima.sourceforge.net using Lisp GNU Common Lisp (GCL) GCL 2.6.7 (a.k.a. GCL)  >Comment By: Robert Dodier (robert_dodier) Date: 20100619 19:19 Message: Works for me, I don't see a bug here. All the same I've thrown some examples (including the ones above) into r1.8 tests/rtest2.mac to make sure it works for everybody. Closing this report as fixed.  Comment By: Aleksas Domarkas (alex108) Date: 20100612 03:50 Message: Works for me correct (%i1) submatrix(10,20,zeromatrix(20,20))$ (%i2) matrix_size(%); (%o2) [18,20] (%i3) submatrix(zeromatrix(20,20),10,11,20)$ (%i4) matrix_size(%); (%o4) [20,17] (%i5) build_info()$ Maxima version: 5.21.1 Maxima build date: 8:13 4/26/2010 Host type: i686pcmingw32 Lisp implementation type: GNU Common Lisp (GCL) Lisp implementation version: GCL 2.6.8  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3014545&group_id=4933 
From: SourceForge.net <noreply@so...>  20100619 19:17:05

Bugs item #1677217, was opened at 20070309 14:37 Message generated for change (Comment added) made by crategus You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1677217&group_id=4933 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Lisp Core Group: None >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Barton Willis (willisbl) Assigned to: Nobody/Anonymous (nobody) Summary: composistions of 'at' Initial Comment: 'at' of and 'at' expression is broken: (%i6) depends(y,[x,z]); (%o6) [y(x,z)] (%i7) diff(y,x); (%o7) 'diff(y,x,1) (%i8) at(%,x=0); (%o8) at('diff(y,x,1),x=0) (%i9) at(%,z=10); (%o9) at('diff(y,x,1),x=0) <wrong, no z=10.  >Comment By: Dieter Kaiser (crategus) Date: 20100619 21:17 Message: Fixed in comm2.lisp revision 1.38. Closing this bug report as fixed. Dieter Kaiser  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1677217&group_id=4933 
From: SourceForge.net <noreply@so...>  20100619 19:14:53

Bugs item #2556133, was opened at 20090202 02:10 Message generated for change (Comment added) made by crategus You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2556133&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: Fixed Priority: 5 Private: No Submitted By: Barton Willis (willisbl) Assigned to: Nobody/Anonymous (nobody) Summary: "at" should do parallel substitutions Initial Comment: (%i14) at(atan2(y^2+1,x),[y=%i,x=0]); atan2(0,0) has been generated. (%i18) at(atan2(y^2+1,x),[x=0,y=%i]); (%o18) %pi/2 (%i17) atvalue (diff(f(x,y),x,6,y,9), [x = 0, y = 1], a^2); (%o17) a^2 (%i18) :lisp(symbolplist '$f); (MPROPS (NIL ATVALUES (((6 9) (0 1) ((MEXPT SIMP) $A 2)) ((0 0) (0 1) ((MEXPT SIMP) $A 2)))))  >Comment By: Dieter Kaiser (crategus) Date: 20100619 21:14 Message: Fixed in comm2.lisp revision 1.38. Closing this bug report as fixed. Dieter Kaiser  Comment By: Barton Willis (willisbl) Date: 20090202 02:13 Message: The way atvalue stores values makes it clear that at should do substitutions in parallel.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2556133&group_id=4933 
From: SourceForge.net <noreply@so...>  20100619 19:13:46

Bugs item #2014941, was opened at 20080710 13:26 Message generated for change (Comment added) made by crategus You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2014941&group_id=4933 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Lisp Core Group: None >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Barton Willis (willisbl) Assigned to: Nobody/Anonymous (nobody) Summary: compositions of 'at' Initial Comment: (%i26) at(diff(f(x),x),[x=b]); (%o26) at('diff(f(x),x,1),[x=b]) (%i27) at(%,[b=a]); (%o27) at('diff(f(x),x,1),[x=b]) (%o27) should either be at('diff(f(x),x,1),[x=a]) or at(at('diff(f(x),x,1),[x=b]),[b=a]) Also, I think 'at' should be a simplifying function.  >Comment By: Dieter Kaiser (crategus) Date: 20100619 21:13 Message: Fixed in comm2.lisp revision 1.38. The composition of AT is more correct and the list of equations is sorted. There is one open problem: AT doesn't check for the "freeof" case. This topic needs more discussions and perhaps a new bug report. Closing this bug report as fixed. Dieter Kaiser  Comment By: Barton Willis (willisbl) Date: 20080710 14:12 Message: Logged In: YES user_id=895922 Originator: YES And yet another thing: Maxima should sort the second argument to 'at.' This would allow more expressions to simplify to zero; example: (%i29) diff(f(x,y),x,1,y,1); (%o29) 'diff(f(x,y),x,1,y,1) (%i30) at(%,[x=a,y=b])  at(%,[y=b,x=a]); (%o30) at('diff(f(x,y),x,1,y,1),[x=a,y=b])at('diff(f(x,y),x,1,y,1),[y=b,x=a]) Since 'at' does multiple substitutions in series, not parallel, the logic could be complicated. Should the subs be done in parallel?  Comment By: Barton Willis (willisbl) Date: 20080710 14:04 Message: Logged In: YES user_id=895922 Originator: YES Another thing: 'at' doesn't check for the "freeof" case; for example: (%i24) diff(f(z),z); (%o24) 'diff(f(z),z,1) (%i25) at(%,[x=1]); (%o25) at('diff(f(z),z,1),[x=1])  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2014941&group_id=4933 
From: SourceForge.net <noreply@so...>  20100619 12:08:55

Bugs item #2036462, was opened at 20080803 08:34 Message generated for change (Comment added) made by crategus You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2036462&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: Fixed Priority: 6 Private: No Submitted By: thbesson (thbesson) Assigned to: Nobody/Anonymous (nobody) Summary: Very long calculation time, normal ? Initial Comment: wxMaxima 0.7.5 http://wxmaxima.sourceforge.net Maxima 5.15.0 http://maxima.sourceforge.net Using Lisp GNU Common Lisp (GCL) GCL 2.6.8 (aka GCL) Distributed under the GNU Public License. See the file COPYING. Dedicated to the memory of William Schelter. The function bug_report() provides bug reporting information. (%i1) kill(all); (%o0) done (%i1) declare(a,constant); (%o1) done (%i2) declare(b,constant); (%o2) done (%i3) declare(c,constant); (%o3) done (%i4) solve(a*x^4/4!+a*x^2/2!+b*x%pi*b+a+c); running since 12 hours on a dualcore  >Comment By: Dieter Kaiser (crategus) Date: 20100619 14:08 Message: Fixed in psolve.lisp revision 1.8. simpnrt is no longer called directly to calculate the variables d and e in solvequartic. Closing this bug report as fixed. Dieter Kaiser  Comment By: Dieter Kaiser (crategus) Date: 20100613 21:26 Message: When we declare the symbols a, b, and c as a constant for the reported example, the algorithm of solvequartic in psolve.lisp hangs. In the routine solvequartic the routine simpnrt in called directly to calculate the square root of an expression. But simpnrt never returns. If we cut out the direct call of simpnrt and replace the code with calls to the main simplifier we no longer get the error: (%i1) declare([a,b,c],constant); (%o1) done (%i2) solve(a*x^4/4!+a*x^2/2!+b*x%pi*b+a+c); (%o2) [x = sqrt(48*b/(a*sqrt((a*(32*sqrt( 32*a*c^3+96*%pi*a*b*c^2 ((96*%pi^2+216)*a*b^224*a^3)*c +81*b^4 (32*%pi^3216*%pi)*a*b^3 180*a^2*b^224*%pi*a^3*b8*a^4) /a^2 .... and lot of more terms. This is the piece of code in solvequartic. The calls to simpnrt have been replaced with calls to the function power: lb1 ; (setq d (simpnrt (simplify (list '(mplus) tr1 tr2)) 2)) (setq d (power (add tr1 tr2) '((rat simp) 1 2))) ; (setq e ; (simpnrt (simplify (list '(mplus) ; (list '(mtimes) 1 tr2))) ; 2)) (setq e (power (add tr1 (mul 1 tr2)) '((rat simp) 1 2))) We have no problems with the testsuite. In the share_testsuite we have only one example which gives the same solutions, but in a different order: ********************** Problem 116 *************** Input: nicedummies(%solve(cos(x)2*cos(2*x)+cos(3*x) = 1/2,x,simpfuncs = ['expand])) Result: %union([x = 2*%pi*%z0atan(sqrt(sqrt(13)/2+1/2)/(1/2sqrt(13)/2))%pi], [x = 2*%pi*%z1+atan(sqrt(sqrt(13)/2+1/2)/(1/2sqrt(13)/2))+%pi], [x = 2*%pi*%z2%i*log(sqrt(13)/4sqrt(sqrt(13)/21/2)/2+1/4)], [x = 2*%pi*%z3%i*log(sqrt(13)/4+sqrt(sqrt(13)/21/2)/2+1/4)], [x = 2*%pi*%z4%pi/3],[x = 2*%pi*%z5+%pi/3]) This differed from the expected result: %union([x = 2*%pi*%z0%i*log(1/4sqrt(sqrt(13)1)/2^(3/2)+sqrt(13)/4)], [x = 2*%pi*%z1%i*log(1/4+sqrt(sqrt(13)1)/2^(3/2)+sqrt(13)/4)], [x = 2*%pi*%z2%pi/3],[x = %pi/3+2*%pi*%z3], [x = %piatan(sqrt(1+sqrt(13))/(1/sqrt(2)sqrt(13)/sqrt(2))) +2*%pi*%z4], [x = %pi+atan(sqrt(1+sqrt(13))/(1/sqrt(2)sqrt(13)/sqrt(2))) +2*%pi*%z5]) I think there is no reason to call simpnrt directly and we should replace these calls. Dieter Kaiser  Comment By: Jason Nevins (jnevins32) Date: 20080901 22:52 Message: Logged In: YES user_id=2201177 Originator: NO Hi, thanks, workaround helped. Also, I have realized that I had support compiled for multiple Common Lisp interpreters. Will try to reduce this to only one and see if it makes a difference.  Comment By: Jason Nevins (jnevins32) Date: 20080901 22:32 Message: Logged In: YES user_id=2201177 Originator: NO Hi I'm Having exact same problem (see: 2087495). Also when doing exactly the above the problem is reproduced. Maxima 5.16.2 http://maxima.sourceforge.net Using Lisp CLISP 2.43 (20071118) Distributed under the GNU Public License. See the file COPYING. Dedicated to the memory of William Schelter. The function bug_report() provides bug reporting information. (%i1) declare(a,constant); (%o1) done (%i2) declare(b,constant); (%o2) done (%i3) declare(c,constant); (%o3) done (%i4) solve(a*x^4/4!+a*x^2/2!+b*x%pi*b+a+c); <<<<<<<<<<<<<<<<<<<< HANGS HERE. Regards Jason Nevins  Comment By: Robert Dodier (robert_dodier) Date: 20080803 20:24 Message: Logged In: YES user_id=501686 Originator: NO Assign category.  Comment By: Robert Dodier (robert_dodier) Date: 20080803 18:58 Message: Logged In: YES user_id=501686 Originator: NO Well, this is a bug. Here is a workaround: omit the declare(..., constant) and tell solve to solve for x specifically. solve(a*x^4/4!+a*x^2/2!+b*x%pi*b+a+c, x); => (quickly returns a long expression) I can't tell what is the problem here; simpler examples seem to get solved right away. I've moved this to the bug tracker in hope of eventually resolving it.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2036462&group_id=4933 
From: SourceForge.net <noreply@so...>  20100619 02:20:27

Bugs item #2723549, was opened at 20090331 16:15 Message generated for change (Settings changed) made by sfrobot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2723549&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: Works For Me Priority: 5 Private: No Submitted By: Martin (mhs) Assigned to: Nobody/Anonymous (nobody) Summary: diff display error for nonint. order and derivabbrev: true Initial Comment: for noninteger order of the derivative, diff can't display anything when derivabbrev: true, see example below. (%i1) derivabbrev: false; (%o1) false (%i2) this:diff(f(x), x, n); (%o2) 'diff(f(x),x,n) (%i3) derivabbrev: true; (%o3) true (%i4) this; Maxima encountered a Lisp error: Error in > [or a callee]: $N is not of type (OR RATIONAL LISP:FLOAT). Automatically continuing. To reenable the Lisp debugger set *debuggerhook* to nil.  >Comment By: SourceForge Robot (sfrobot) Date: 20100619 02:20 Message: 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: Dieter Kaiser (crategus) Date: 20100604 23:16 Message: With the current CVS version of Maxima I can not reproduce the reported problem: Maxima version: 5.20post Maxima build date: 21:58 6/4/2010 Host type: i686pclinuxgnu Lisp implementation type: SBCL Lisp implementation version: 1.0.29.11.debian (%i1) derivabbrev:false$ (%i2) this:diff(f(x),x,n); (%o2) 'diff(f(x),x,n) (%i3) derivabbrev:true$ (%i4) this; (%o4) 'diff(f(x),x,n) Perhaps, it is a problem with an earlier version of Maxima. We have no build_info for this bug report. Setting the status to pending and the resolution to "works for me". Dieter Kaiser  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2723549&group_id=4933 
From: SourceForge.net <noreply@so...>  20100619 02:20:25

Bugs item #2998923, was opened at 20100509 13:18 Message generated for change (Comment added) made by sfrobot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2998923&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: Closed Resolution: Works For Me Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: partfrac doesn't work correct with keepfloat:true; Initial Comment: Kind of annoying artifact. partfrac() works perfect with CRE, but only partly with FLOAT  >Comment By: SourceForge Robot (sfrobot) Date: 20100619 02:20 Message: 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: Dieter Kaiser (crategus) Date: 20100604 23:46 Message: I think it might be a missing feature that partfrac does not work with keepfloat:true. But it is possible to get a floating point approximation with the function float: (%o1) 7/((0.65*s+1)*s*(1.6*s+1)) (%i2) float(partfrac(expr,s)); rat: replaced 0.65 by 13/20 = 0.65 rat: replaced 1.6 by 8/5 = 1.6 (%o2) 62.26315789473684/(13.0*s+20.0)94.3157894736842/(8.0*s+5.0)+7.0/s Furthermore, the documentation of partfrac seems to be placed in the wrong chapter "Number Theory". It might be better to put the documentation into the chapter "Polynomials". Setting the status to pending and the resolution to "works for me". Dieter Kaiser  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2998923&group_id=4933 
From: SourceForge.net <noreply@so...>  20100615 05:43:57

Bugs item #3015864, was opened at 20100614 15:29 Message generated for change (Settings changed) made by lerkru You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3015864&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: Closed >Resolution: Invalid Priority: 5 Private: No Submitted By: ler kru (lerkru) Assigned to: Nobody/Anonymous (nobody) Summary: Maxima can't evaluate limit Initial Comment: limit((tan(sin(x))sin(tan(x)))/(atan(asin(x))asin(atan(x))),x,0,plus); Result must be 1, but maxima can't evaluate this.  >Comment By: ler kru (lerkru) Date: 20100615 09:43 Message: Thanks a lot. It's not a bug. Just limit can't do this, but tlimit can.  Comment By: Barton Willis (willisbl) Date: 20100615 04:53 Message: Workaround: (%i35) tlimit((tan(sin(x))sin(tan(x)))/(atan(asin(x))asin(atan(x))),x,0,plus); Evaluation took 0.0200 seconds (0.0200 elapsed) (%o35) 1  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3015864&group_id=4933 
From: SourceForge.net <noreply@so...>  20100615 05:20:22

Bugs item #3014845, was opened at 20100611 08:10 Message generated for change (Comment added) made by robert_dodier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3014845&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: Pending Resolution: Wont Fix Priority: 5 Private: No Submitted By: Derek O'Connor (derekroconnor) Assigned to: Nobody/Anonymous (nobody) Summary: sin(1e22) is wrong Initial Comment: sin(1e22); (%o1) 0.41214336710708 The correct answer is 8.522008497671888 Please note that 10^22 is exactly representable as an IEEE double precision floating point number, whose binary representation is 10^22 = 1000011110000110011110000011001001101110101011001001 x 2^22 This incorrect result suggests that the rangereduction step, where the argument x is reduced to lie in a small interval around 0, such as [pi/2,+pi/2], has not been done properly. This means that the other trigonometric functions will be incorrect. This value 10^22 was carefully chosen by Ng to uncover faulty range reduction: http://www.derekroconnor.net/Software/NgArgReduction.pdf Maxima is not alone: R, Octave, Freemat, Euler, Python, and Lua have the same problem. Matlab used to have this problem but fixed it. I am neither a systems programmer nor a Maxima developer so I don't know what is going on in the background. I suspect that the mingw32 system may be at fault. If so, this prompts the question: do Maxima developers not check the components they are using? Maxima version: 5.21.1 Maxima build date: 8:13 4/26/2010 Host type: i686pcmingw32 Lisp implementation type: GNU Common Lisp (GCL) Lisp implementation version: GCL 2.6.8 Dell Precision 690, Intel 2xQuadCore E5345 @ 2.33GHz 16GB RAM, Windows7 64bit Professional. Derek O'Connor  >Comment By: Robert Dodier (robert_dodier) Date: 20100614 23:20 Message: For the record, Clozure CL (Version 1.4r13122 on Windows Vista) returns (sin 1d22) => 0.41214336710708466D0. I agree with Ray T that these are bugs in the Lisp implementation. I don't think Maxima should try to replace all of the math functions in Lisp, so we have to rely on the Lisp implementation for sin and other functions. If someone has time to report these bugs to the Lisp implementations bug trackers, that would be terrific.  Comment By: Raymond Toy (rtoy) Date: 20100614 20:05 Message: I think it would be best to ask on the mailing list to see if someone can do a windows build with gcl using ming64. Or ask on the gcl list if there's a mingw64 version. Setting this to pending/wontfix again.  Comment By: Derek O'Connor (derekroconnor) Date: 20100613 03:54 Message: The bug is not really in gcl but in ming32. R 2.11.0 under ming32 gives the wrong answer while R 2.11.0 under ming64 gives the right answer. Is it possible to get a version of Maxima (or gcl) that uses ming64?  Comment By: Raymond Toy (rtoy) Date: 20100612 20:00 Message: As I mentioned, I consider this a bug in gcl, not maxima. Although I could fix it, I'm not inclined to do so. It would be a lot of work to do and to support just for gcl when ccl, I think, produces the correct result. (It does on Mac OS X.)  Comment By: Derek O'Connor (derekroconnor) Date: 20100612 16:56 Message: I am NOT concerned about bfloat(sin(10^22)) or sin(bfloat(10^22)). I am concerned that sin(10^22) gives the wrong answer on my system, and presumably, on many similar systems.  Comment By: Aleksas Domarkas (alex108) Date: 20100612 03:30 Message: (%i1) fpprec : 32; (%o1) 32 (%i2) bfloat(sin(10^22)); (%o2) 8.5220084976718880177270589375303b1 (%i3) build_info()$ Maxima version: 5.21.1 Maxima build date: 8:13 4/26/2010 Host type: i686pcmingw32 Lisp implementation type: GNU Common Lisp (GCL) Lisp implementation version: GCL 2.6.8  Comment By: Raymond Toy (rtoy) Date: 20100611 16:40 Message: Maxima computes sin(1e22) by defering to the Lisp implementation to evaluate it. Gcl produces the incorrect answer. Maxima with cmucl produces 0.8522008497671888, as you expect. I consider this a bug in gcl, not maxima. Marking as pending/wontfix.  Comment By: Derek O'Connor (derekroconnor) Date: 20100611 12:38 Message: CORRECTION: 8.522008497671888 should be 0.8522008497671888 Derek O'Connor  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3014845&group_id=4933 
From: SourceForge.net <noreply@so...>  20100615 02:05:05

Bugs item #3014845, was opened at 20100611 10:10 Message generated for change (Settings changed) made by rtoy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3014845&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: Pending Resolution: Wont Fix Priority: 5 Private: No Submitted By: Derek O'Connor (derekroconnor) Assigned to: Nobody/Anonymous (nobody) Summary: sin(1e22) is wrong Initial Comment: sin(1e22); (%o1) 0.41214336710708 The correct answer is 8.522008497671888 Please note that 10^22 is exactly representable as an IEEE double precision floating point number, whose binary representation is 10^22 = 1000011110000110011110000011001001101110101011001001 x 2^22 This incorrect result suggests that the rangereduction step, where the argument x is reduced to lie in a small interval around 0, such as [pi/2,+pi/2], has not been done properly. This means that the other trigonometric functions will be incorrect. This value 10^22 was carefully chosen by Ng to uncover faulty range reduction: http://www.derekroconnor.net/Software/NgArgReduction.pdf Maxima is not alone: R, Octave, Freemat, Euler, Python, and Lua have the same problem. Matlab used to have this problem but fixed it. I am neither a systems programmer nor a Maxima developer so I don't know what is going on in the background. I suspect that the mingw32 system may be at fault. If so, this prompts the question: do Maxima developers not check the components they are using? Maxima version: 5.21.1 Maxima build date: 8:13 4/26/2010 Host type: i686pcmingw32 Lisp implementation type: GNU Common Lisp (GCL) Lisp implementation version: GCL 2.6.8 Dell Precision 690, Intel 2xQuadCore E5345 @ 2.33GHz 16GB RAM, Windows7 64bit Professional. Derek O'Connor  >Comment By: Raymond Toy (rtoy) Date: 20100614 22:05 Message: I think it would be best to ask on the mailing list to see if someone can do a windows build with gcl using ming64. Or ask on the gcl list if there's a mingw64 version. Setting this to pending/wontfix again.  Comment By: Derek O'Connor (derekroconnor) Date: 20100613 05:54 Message: The bug is not really in gcl but in ming32. R 2.11.0 under ming32 gives the wrong answer while R 2.11.0 under ming64 gives the right answer. Is it possible to get a version of Maxima (or gcl) that uses ming64?  Comment By: Raymond Toy (rtoy) Date: 20100612 22:00 Message: As I mentioned, I consider this a bug in gcl, not maxima. Although I could fix it, I'm not inclined to do so. It would be a lot of work to do and to support just for gcl when ccl, I think, produces the correct result. (It does on Mac OS X.)  Comment By: Derek O'Connor (derekroconnor) Date: 20100612 18:56 Message: I am NOT concerned about bfloat(sin(10^22)) or sin(bfloat(10^22)). I am concerned that sin(10^22) gives the wrong answer on my system, and presumably, on many similar systems.  Comment By: Aleksas Domarkas (alex108) Date: 20100612 05:30 Message: (%i1) fpprec : 32; (%o1) 32 (%i2) bfloat(sin(10^22)); (%o2) 8.5220084976718880177270589375303b1 (%i3) build_info()$ Maxima version: 5.21.1 Maxima build date: 8:13 4/26/2010 Host type: i686pcmingw32 Lisp implementation type: GNU Common Lisp (GCL) Lisp implementation version: GCL 2.6.8  Comment By: Raymond Toy (rtoy) Date: 20100611 18:40 Message: Maxima computes sin(1e22) by defering to the Lisp implementation to evaluate it. Gcl produces the incorrect answer. Maxima with cmucl produces 0.8522008497671888, as you expect. I consider this a bug in gcl, not maxima. Marking as pending/wontfix.  Comment By: Derek O'Connor (derekroconnor) Date: 20100611 14:38 Message: CORRECTION: 8.522008497671888 should be 0.8522008497671888 Derek O'Connor  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3014845&group_id=4933 