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}
(18) 
_{Oct}

_{Nov}

_{Dec}

S  M  T  W  T  F  S 




1

2

3
(3) 
4
(1) 
5

6

7
(1) 
8

9
(2) 
10
(1) 
11

12

13
(2) 
14

15
(1) 
16
(1) 
17
(2) 
18

19

20

21

22

23

24

25

26

27

28
(1) 
29

30

31
(1) 

From: SourceForge.net <noreply@so...>  20101231 00:49:48

Bugs item #3146928, was opened at 20101228 03:26 Message generated for change (Comment added) made by willisbl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3146928&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: Christian Croonenbroek (ccroonen) Assigned to: Nobody/Anonymous (nobody) Summary: exponential equations Initial Comment: It is not possible to use the "solvecommand" or "algsyscommand" to solve exponential equatons. Only the "to_poly_solve command" seems to function but only with complex solutions. That is unfortunatly not workable for using Maxima in school in order to substitute the CASSystems of Texas Intruments, Casio or maple. Is it possible to develop only one solve command for all types of equation? Is anybody able to do this? It would help to use Maxima in school. Thank you Chritian  >Comment By: Barton Willis (willisbl) Date: 20101230 18:49 Message: The answer to both questions is `yes.' You would need to ask on the list about if anybody has something close to what you want. Or maybe you could write some code that works for you. It might be possible to modify to_poly_solve to work the way you would like a solve function to work. Actually this a feature request, not a bug report, I think.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3146928&group_id=4933 
From: SourceForge.net <noreply@so...>  20101228 09:26:26

Bugs item #3146928, was opened at 20101228 10:26 Message generated for change (Tracker Item Submitted) made by ccroonen You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3146928&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: Christian Croonenbroek (ccroonen) Assigned to: Nobody/Anonymous (nobody) Summary: exponential equations Initial Comment: It is not possible to use the "solvecommand" or "algsyscommand" to solve exponential equatons. Only the "to_poly_solve command" seems to function but only with complex solutions. That is unfortunatly not workable for using Maxima in school in order to substitute the CASSystems of Texas Intruments, Casio or maple. Is it possible to develop only one solve command for all types of equation? Is anybody able to do this? It would help to use Maxima in school. Thank you Chritian  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3146928&group_id=4933 
From: SourceForge.net <noreply@so...>  20101217 22:20:09

Bugs item #3113715, was opened at 20101120 18:05 Message generated for change (Settings changed) made by sfrobot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3113715&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: Invalid Priority: 5 Private: No Submitted By: JeanBaptiste Heyberger (jbhoen) Assigned to: Nobody/Anonymous (nobody) Summary: linsolve solution pb Initial Comment: I use maxima 5.22.1 My commands are successively: Eq5 : c3*x006+c5*(x001)**2c4*x001/3+c2*x001/3+x001 = 0; linsolve([Eq5], [x001]); The unexpected result is : [x001=(3*c3*x006)/(c4c23)]  >Comment By: SourceForge Robot (sfrobot) Date: 20101217 22: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: 20101203 21:49 Message: The function linsolve is documented to solve a set of linear equations. I think, the function solve gives the expected solutions as reported in the last posting: (%i5) Eq5 : c3*x006+c5*(x001)**2c4*x001/3+c2*x001/3+x001 = 0$ (%i6) solve([Eq5],[x001]); (%o6) [x001 = (sqrt(36*c3*c5*x006+c4^2+(2*c26)*c4+c2^2+6*c2+9)c4+c2+3) /(6*c5), x001 = (sqrt(36*c3*c5*x006+c4^2+(2*c26)*c4+c2^2+6*c2+9)+c4c23) /(6*c5)] Setting the status to pending and the resolution to invalid. Dieter Kaiser  Comment By: Barton Willis (willisbl) Date: 20101121 11:45 Message: The function linsolve does not check that the equation is linear. Try using solve instead of linsolve.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3113715&group_id=4933 
From: SourceForge.net <noreply@so...>  20101217 20:20:05

Bugs item #3123933, was opened at 20101130 22:29 Message generated for change (Settings changed) made by sfrobot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3123933&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: Works For Me Priority: 5 Private: No Submitted By: quwerty (doe140) Assigned to: Nobody/Anonymous (nobody) Summary: Incorrect solution to equation Initial Comment: I have the foolowing code: c:3e+8$ mu_r1:1$ mu_r2:1$ sigma_1:0$ sigma_2:0$ eps_r1:3.3$ eps_r2:1.6$ h:1e6$ f:180e+12$ P2:0.01e3$ eps_0:8.85e12$ mu_0:4*%pi*1e7$ eps_a1:eps_r1*eps_0$ eps_a2:eps_r2*eps_0$ mu_a1:mu_0*mu_r1$ mu_a2:mu_0*mu_r2$ omega:2*%pi*f$ /* [wxMaxima: input end ] */ /* [wxMaxima: input start ] */ kill(x, y)$ x:find_root(sqrt(omega^2*h^2*(eps_a1*mu_a1eps_a2*mu_a2)x^2)+eps_a2/eps_a1*x*tan(x)=0, x, 0, 5); y:float(sqrt(omega^2*h^2*(eps_a1*mu_a1eps_a2*mu_a2)%^2)); y1:float(eps_a2/eps_a1*x*tan(x))$ With these limits y!=y1. If I run x:find_root(..., x, 1.7, 2); I get correct answer. This seems a little strange. May this be of tan(x)'s behaviour at x=%pi/2?  >Comment By: SourceForge Robot (sfrobot) Date: 20101217 20: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: 20101203 20:03 Message: At first, it is very helpful to have a small example. I think the function of interest for this example is eqn: 0.4848484848484849*x*tan(x)+sqrt(0.7799327999999998*%pi^3x^2) One important and documented restriction of the algorithm of find_root is, that the function has to be continuous over the interval, which is given as an argument to find_root. If I do a plot of the function for the interval [0,5] with the command plot2d(eqn,[x,0,5],[y,100,100]) I can see that the function is not continuous at two points and that the function has one root. Furthermore, the root is near the value 1.75. If I take the function of this example and the interval [1.6,2.0] I get the desired root: (%i1) eqn:.4848484848484849*x*tan(x)+sqrt(.7799327999999998*%pi^3x^2); (%o1) .4848484848484849*x*tan(x)+sqrt(.7799327999999998*%pi^3x^2) This is the root of the equation: (%i2) result:find_root(eqn,x,1.6,2); (%o2) 1.753812411159384 Backsubstitution shows that the result is a root within an expected accuracy (%i3) float(subst(result,x,eqn)); (%o3) 1.77635683940025e15 The algorithm of find_root fails in the interval [0,5] because the function is not continuous over the interval. I think we do not have a bug. The numerical routine find_root has documented limitations. 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=3123933&group_id=4933 
From: SourceForge.net <noreply@so...>  20101216 00:18:57

Bugs item #3138054, was opened at 20101215 11:31 Message generated for change (Comment added) made by willisbl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3138054&group_id=4933 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Lisp Core  Floating point Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: bh () Assigned to: Nobody/Anonymous (nobody) >Summary: bfloat problem / FIX Initial Comment: exp(gamma(1/3)),float; exp(gamma(1/3)),numer; exp(gamma(1/3)),bfloat; 14.56961993923131 14.56961993923131 5.691257639728396b2 Maxima version: 5.22post Maxima build date: 22:21 12/10/2010 Host type: x86_64appledarwin10.5.0 Lisp implementation type: SBCL Lisp implementation version: 1.0.45  >Comment By: Barton Willis (willisbl) Date: 20101215 18:18 Message: Proposed fix: (defmfun $bfloat (x) (let (y) (cond ((bigfloatp x)) ((or (numberp x) (member x '($%e $%pi $%gamma) :test #'eq)) (bcons (intofp x))) ((or (atom x) (member 'array (cdar x) :test #'eq)) (if (eq x '$%phi) ($bfloat '((mtimes simp) ((rat simp) 1 2) ((mplus simp) 1 ((mexpt simp) 5 ((rat simp) 1 2))))) x)) ((eq (caar x) 'mexpt) (if (equal (cadr x) '$%e) (*fpexp ($bfloat (caddr x))) ;; <missing bfloat (exptbigfloat ($bfloat (cadr x)) (caddr x))))  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3138054&group_id=4933 
From: SourceForge.net <noreply@so...>  20101215 17:31:54

Bugs item #3138054, was opened at 20101215 17:31 Message generated for change (Tracker Item Submitted) made by You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3138054&group_id=4933 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Lisp Core  Floating point Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: bh () Assigned to: Nobody/Anonymous (nobody) Summary: bfloat problem Initial Comment: exp(gamma(1/3)),float; exp(gamma(1/3)),numer; exp(gamma(1/3)),bfloat; 14.56961993923131 14.56961993923131 5.691257639728396b2 Maxima version: 5.22post Maxima build date: 22:21 12/10/2010 Host type: x86_64appledarwin10.5.0 Lisp implementation type: SBCL Lisp implementation version: 1.0.45  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3138054&group_id=4933 
From: SourceForge.net <noreply@so...>  20101213 17:08:41

Bugs item #3136608, was opened at 20101213 17:19 Message generated for change (Comment added) made by riotorto You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3136608&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: Don Bindner (donbindner) Assigned to: Nobody/Anonymous (nobody) Summary: head_length not respected in draw3d Initial Comment: The head_length parameter seems to to be honored in the draw3d function. If you use draw3d after previously calling draw2d, head_length changes from the earlier call bleed through somehow to the later drawing. My lisp is not very strong, but I believe the attached patch corrects it. I basically looked at the lisp for draw2d and made the draw3d lisp parallel to it.  >Comment By: Mario Rodriguez Riotorto (riotorto) Date: 20101213 18:08 Message: Thanks for the patch. Not sure if this change will take effect in Maxima 5.23  Mario  Comment By: Mario Rodriguez Riotorto (riotorto) Date: 20101213 18:08 Message: The reported bug is not present in the current cvs version of Maxima. Thank you for your report. If you see this bug in a later version of Maxima, please submit a new bug report.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3136608&group_id=4933 
From: SourceForge.net <noreply@so...>  20101213 16:19:59

Bugs item #3136608, was opened at 20101213 10:19 Message generated for change (Tracker Item Submitted) made by donbindner You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3136608&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: Don Bindner (donbindner) Assigned to: Nobody/Anonymous (nobody) Summary: head_length not respected in draw3d Initial Comment: The head_length parameter seems to to be honored in the draw3d function. If you use draw3d after previously calling draw2d, head_length changes from the earlier call bleed through somehow to the later drawing. My lisp is not very strong, but I believe the attached patch corrects it. I basically looked at the lisp for draw2d and made the draw3d lisp parallel to it.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3136608&group_id=4933 
From: SourceForge.net <noreply@so...>  20101210 00:10:11

Bugs item #3133916, was opened at 20101209 19:10 Message generated for change (Tracker Item Submitted) made by macrakis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3133916&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: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: scanmap(minfactorial,a!) infinite loop Initial Comment: scanmap(minfactorial,a!) gets into an infinite loop (recursion) and crashes Maxima. This appears to be because minfactorial returns an unsimplified result (observed with ?trace(minfactorial)), and scanmap doesn't simplify it before recursing. scanmap(lambda([x],minfactorial(x)),a!) does not have this problem, because meval simplifies the result.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3133916&group_id=4933 
From: SourceForge.net <noreply@so...>  20101209 14:48:47

Bugs item #3133029, was opened at 20101209 15:48 Message generated for change (Tracker Item Submitted) made by You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3133029&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  Complex Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: https://www.google.com/accounts () Assigned to: Nobody/Anonymous (nobody) Summary: Incorrect result of residue Initial Comment: >From https://bugs.launchpad.net/ubuntu/+source/maxima/+bug/323221: kubuntu intrepid, maxima 5.13.0 Binary package hint: maxima (%i1) residue(%e**(1/z),z,0); (%o1) 0 but according to the laurent series: %e**(1/z) = 1 + 1/z + 1/2z^2 + ... the correct result is 1.  I can confirm this bug in Maxima 5.22.1. Laurent serie with `powerseries' is correct: (%i2) powerseries(%e^(1/z), z, 0); inf ==== \ 1 (%o2) >  / i2 ==== i2! z i2 = 0 but with `taylor': (%i3) taylor(%e^(1/z), z, 0, 8); 1 (%o3)/T/  + . . .  1/z %e  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3133029&group_id=4933 
From: SourceForge.net <noreply@so...>  20101209 14:22:03

Bugs item #3133016, was opened at 20101209 08:22 Message generated for change (Tracker Item Submitted) made by willisbl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3133016&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: 3 Private: No Submitted By: Barton Willis (willisbl) Assigned to: Nobody/Anonymous (nobody) Summary: lambda form for taylor_simplifier Initial Comment: When taylor_simplifier is a Maxima lambda form, taylor gives an error: (%i14) taylor(sin(x),x,0,4), taylor_simplifier : lambda([s],s); Maxima encountered a Lisp error: OK for a CL function: (%i9) taylor(sin(x),x,0,4), taylor_simplifier : radcan; (%o9)/T/ xx^3/6+... Also OK (%i15) f : lambda([s],s)$ (%i16) taylor(sin(x),x,0,4), taylor_simplifier : 'f; (%o16)/T/ xx^3/6+... And not OK: (%i17) taylor(sin(x),x,0,4), taylor_simplifier : f; Maxima encountered a Lisp error:  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3133016&group_id=4933 
From: SourceForge.net <noreply@so...>  20101207 11:13:26

Bugs item #3131324, was opened at 20101207 05:13 Message generated for change (Tracker Item Submitted) made by willisbl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3131324&group_id=4933 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Lisp Core  Simplification Group: None Status: Open Resolution: None Priority: 6 Private: No Submitted By: Barton Willis (willisbl) Assigned to: Nobody/Anonymous (nobody) Summary: simplification of sqrt Initial Comment: Using default environment sqrt(x^3)/sqrt(x^3) does not simplify to 1: (%i1) sqrt(x^3)/sqrt(x^3); (%o1) sqrt(x^3)/x^(3/2) With either radexpand : all or domain : complex, it does simplify to 1 (%i2) sqrt(x^3)/sqrt(x^3),radexpand : all; (%o2) 1 (%i3) sqrt(x^3)/sqrt(x^3),domain : complex; (%o3) 1  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3131324&group_id=4933 
From: SourceForge.net <noreply@so...>  20101204 14:14:51

Bugs item #3067098, was opened at 20100915 22:11 Message generated for change (Comment added) made by crategus You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3067098&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: Dieter Kaiser (crategus) Assigned to: Nobody/Anonymous (nobody) Summary: The command timer for a Lisp function Initial Comment: If we would like to collect timing statistics for a Lisp function and then call kill(all) the Lisp function is gone away: First we do it for a Maxima user function: (%i2) timer(?$rectform); (%o2) [rectform] (%i3) kill(all)$ (%i1) rectform(x); (%o1) x Now for a Lisp function: (%i2) timer(?trisplit); (%o2) [?trisplit] (%i3) kill(all)$ (%i1) rectform(x); Maxima encountered a Lisp error: The function TRISPLIT is undefined. Automatically continuing. To enable the Lisp debugger set *debuggerhook* to nil. I think this is a very old bug, I can reproduce it since Maxima 5.9. timer might be not suitable for a Lisp function, but then the function should not accept a Lisp function as an argument. Dieter Kaiser  >Comment By: Dieter Kaiser (crategus) Date: 20101204 15:14 Message: Fixed in rpart.lisp revision 1.40. The bug is very mysterious. It helps to change the definition of the function from a defmfunfunction to a defunfunction. But we do not get the bug for other defmfunfunctions and I do not see any difference between a function like risplit and trisplit. I have searched a global symbol which might interfere the behavior for the function trisplit, but I have not found such a symbol. Nevertheless, the change of the definition helps for this case. Closing this bug report as fixed. Dieter Kaiser  Comment By: Raymond Toy (rtoy) Date: 20101007 14:23 Message: FWIW, I tried a few more lisp functions like %coercefloatfun, dsrl, risplit. These are all restored correctly. Don't understand why this doesn't work for trisplit. These were all defined via defun.  Comment By: Raymond Toy (rtoy) Date: 20101006 13:23 Message: I took a look at this. The routine that is supposed to remove the timer info is traceunfshadow in mtrace.lisp. I don't understand why this is causing problems. The key part is: (let ((oldf (traceoldfun fun))) (if (not (null oldf)) (setf (symbolfunction fun) oldf) (fmakunbound fun)))) So, the timer version of trisplit is supposed to be replaced with the original trisplit function. But it's not. It's as if fmakunbound were called instead of the setf. But oldf is the original function.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3067098&group_id=4933 
From: SourceForge.net <noreply@so...>  20101203 21:49:21

Bugs item #3113715, was opened at 20101120 19:05 Message generated for change (Comment added) made by crategus You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3113715&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: Pending >Resolution: Invalid Priority: 5 Private: No Submitted By: JeanBaptiste Heyberger (jbhoen) Assigned to: Nobody/Anonymous (nobody) Summary: linsolve solution pb Initial Comment: I use maxima 5.22.1 My commands are successively: Eq5 : c3*x006+c5*(x001)**2c4*x001/3+c2*x001/3+x001 = 0; linsolve([Eq5], [x001]); The unexpected result is : [x001=(3*c3*x006)/(c4c23)]  >Comment By: Dieter Kaiser (crategus) Date: 20101203 22:49 Message: The function linsolve is documented to solve a set of linear equations. I think, the function solve gives the expected solutions as reported in the last posting: (%i5) Eq5 : c3*x006+c5*(x001)**2c4*x001/3+c2*x001/3+x001 = 0$ (%i6) solve([Eq5],[x001]); (%o6) [x001 = (sqrt(36*c3*c5*x006+c4^2+(2*c26)*c4+c2^2+6*c2+9)c4+c2+3) /(6*c5), x001 = (sqrt(36*c3*c5*x006+c4^2+(2*c26)*c4+c2^2+6*c2+9)+c4c23) /(6*c5)] Setting the status to pending and the resolution to invalid. Dieter Kaiser  Comment By: Barton Willis (willisbl) Date: 20101121 12:45 Message: The function linsolve does not check that the equation is linear. Try using solve instead of linsolve.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3113715&group_id=4933 
From: SourceForge.net <noreply@so...>  20101203 21:33:50

Bugs item #3118770, was opened at 20101125 21:26 Message generated for change (Settings changed) made by crategus You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3118770&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: Emilio Suarez (folok) Assigned to: Nobody/Anonymous (nobody) Summary: %edispflag:true causes a bug Initial Comment: %i1 %edispflag:true; %o1 true %i2 integrate(x/(%e)^(2*x), x, 0, 1); %o2 \int_{0}^{1}\frac{x}{{e}^{2\,x}}dx (it doesn't do the integral) %i3 %edispflag:false; %o3 false %i4 integrate(x/(%e)^(2*x), x, 0, 1); %o4 \frac{1}{4}\frac{3\,{e}^{2}}{4} (this time it does)  >Comment By: Dieter Kaiser (crategus) Date: 20101203 22:33 Message: Fixed in defint.lisp revision 1.85. Now we get as expected: (%i2) %edispflag:false$ (%i3) integrate(x/(%e)^(2*x), x, 0, 1); (%o3) 1/43*%e^2/4 (%i4) %edispflag:true$ (%i5) integrate(x/(%e)^(2*x), x, 0, 1); (%o5) 1/43/(4*%e^2) Closing this bug report as fixed. Dieter Kaiser  Comment By: Robert Dodier (robert_dodier) Date: 20101128 23:31 Message: I can replicate the problem. integrate calls FORMMEXPT (via NFORMAT) which returns an MQUOTIENT expression which %edispflag is in effect. I guess integrate should bind %edispflag to NIL before calling NFORMAT.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3118770&group_id=4933 
From: SourceForge.net <noreply@so...>  20101203 20:03:32

Bugs item #3123933, was opened at 20101130 23:29 Message generated for change (Comment added) made by crategus You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3123933&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: Pending >Resolution: Works For Me Priority: 5 Private: No Submitted By: quwerty (doe140) Assigned to: Nobody/Anonymous (nobody) Summary: Incorrect solution to equation Initial Comment: I have the foolowing code: c:3e+8$ mu_r1:1$ mu_r2:1$ sigma_1:0$ sigma_2:0$ eps_r1:3.3$ eps_r2:1.6$ h:1e6$ f:180e+12$ P2:0.01e3$ eps_0:8.85e12$ mu_0:4*%pi*1e7$ eps_a1:eps_r1*eps_0$ eps_a2:eps_r2*eps_0$ mu_a1:mu_0*mu_r1$ mu_a2:mu_0*mu_r2$ omega:2*%pi*f$ /* [wxMaxima: input end ] */ /* [wxMaxima: input start ] */ kill(x, y)$ x:find_root(sqrt(omega^2*h^2*(eps_a1*mu_a1eps_a2*mu_a2)x^2)+eps_a2/eps_a1*x*tan(x)=0, x, 0, 5); y:float(sqrt(omega^2*h^2*(eps_a1*mu_a1eps_a2*mu_a2)%^2)); y1:float(eps_a2/eps_a1*x*tan(x))$ With these limits y!=y1. If I run x:find_root(..., x, 1.7, 2); I get correct answer. This seems a little strange. May this be of tan(x)'s behaviour at x=%pi/2?  >Comment By: Dieter Kaiser (crategus) Date: 20101203 21:03 Message: At first, it is very helpful to have a small example. I think the function of interest for this example is eqn: 0.4848484848484849*x*tan(x)+sqrt(0.7799327999999998*%pi^3x^2) One important and documented restriction of the algorithm of find_root is, that the function has to be continuous over the interval, which is given as an argument to find_root. If I do a plot of the function for the interval [0,5] with the command plot2d(eqn,[x,0,5],[y,100,100]) I can see that the function is not continuous at two points and that the function has one root. Furthermore, the root is near the value 1.75. If I take the function of this example and the interval [1.6,2.0] I get the desired root: (%i1) eqn:.4848484848484849*x*tan(x)+sqrt(.7799327999999998*%pi^3x^2); (%o1) .4848484848484849*x*tan(x)+sqrt(.7799327999999998*%pi^3x^2) This is the root of the equation: (%i2) result:find_root(eqn,x,1.6,2); (%o2) 1.753812411159384 Backsubstitution shows that the result is a root within an expected accuracy (%i3) float(subst(result,x,eqn)); (%o3) 1.77635683940025e15 The algorithm of find_root fails in the interval [0,5] because the function is not continuous over the interval. I think we do not have a bug. The numerical routine find_root has documented limitations. 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=3123933&group_id=4933 