Screenshot instructions:
Windows
Mac
Red Hat Linux
Ubuntu
Click URL instructions:
Rightclick on ad, choose "Copy Link", then paste here →
(This may not be possible with some types of ads)
You can subscribe to this list here.
2002 
_{Jan}

_{Feb}

_{Mar}

_{Apr}

_{May}

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

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

_{Mar}

_{Apr}

_{May}

_{Jun}

_{Jul}

_{Aug}

_{Sep}

_{Oct}

_{Nov}

_{Dec}

S  M  T  W  T  F  S 



1
(2) 
2

3

4
(4) 
5
(9) 
6

7
(1) 
8

9
(4) 
10
(1) 
11
(4) 
12
(3) 
13
(6) 
14
(6) 
15
(3) 
16
(6) 
17
(1) 
18
(5) 
19
(4) 
20

21
(3) 
22
(1) 
23
(2) 
24
(7) 
25
(5) 
26

27
(3) 
28
(7) 
29
(1) 
30
(7) 



From: SourceForge.net <noreply@so...>  20080409 21:45:17

Bugs item #1935418, was opened at 20080405 08:00 Message generated for change (Comment added) made by nobody You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1935418&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: display2d and newline Initial Comment: $ maxima (%i1) display2d:false; (%o1) false (%i2) expand((a+b)*(a+b)); (%o2) b^2+2*a*b+a^2 (%i3) I think there are too much newlines. Especially when I say display2d:false; the line above the output is not longer needed for the exponents and should be removed.  Comment By: Nobody/Anonymous (nobody) Date: 20080409 14:45 Message: Logged In: NO Ok, the spaces occur with Maxima 5.12.0. I will make my next bug report on base of an actual cvs version.  Comment By: Raymond Toy (rtoy) Date: 20080405 13:30 Message: Logged In: YES user_id=28849 Originator: NO I don't see this: (%i7) display2d:false; (%o7) false (%i8) expand((a+b)^2); (%o8) b^2+2*a*b+a^2 This is with a pretty recent CVS version. What version are you using?  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1935418&group_id=4933 
From: SourceForge.net <noreply@so...>  20080409 13:32:15

Bugs item #1938570, was opened at 20080409 08:53 Message generated for change (Comment added) made by rtoy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1938570&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: bug in range of plot3d Initial Comment: otsocoltempo@... Maxima version: 5.12.0 Maxima build date: 10:6 6/7/2007 host type: i686pcmingw32 lispimplementationtype: GNU Common Lisp (GCL) lispimplementationversion: GCL 2.6.8 I have had the following bug when trying to do the plot plot3d(sin(sqrt(x^2+y^2))/sqrt(x^2+y^2), [x,15,15], [y,15,15])$ Maxima encountered a Lisp error: Error in PROGN [or a callee]: Expected a LONGFLOAT Automatically continuing.To reenable the Lisp debugger set *debuggerhook* to nil. However, it works when I change the range o y variable. For example, plot3d(sin(sqrt(x^2+y^2))/sqrt(x^2+y^2), [x,15,15], [y,15,16])$  >Comment By: Raymond Toy (rtoy) Date: 20080409 09:32 Message: Logged In: YES user_id=28849 Originator: NO The error happens because plot3d eventually evaluates your function at x,y = (0,0). This is indeterminate, and T is returned instead of a float. Changing the range changes where the sample points are taken. I do not know how to fix this, other than changing the function to be plotted or changing the range.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1938570&group_id=4933 
From: SourceForge.net <noreply@so...>  20080409 12:54:04

Bugs item #1938570, was opened at 20080409 05:53 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1938570&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: bug in range of plot3d Initial Comment: otsocoltempo@... Maxima version: 5.12.0 Maxima build date: 10:6 6/7/2007 host type: i686pcmingw32 lispimplementationtype: GNU Common Lisp (GCL) lispimplementationversion: GCL 2.6.8 I have had the following bug when trying to do the plot plot3d(sin(sqrt(x^2+y^2))/sqrt(x^2+y^2), [x,15,15], [y,15,15])$ Maxima encountered a Lisp error: Error in PROGN [or a callee]: Expected a LONGFLOAT Automatically continuing.To reenable the Lisp debugger set *debuggerhook* to nil. However, it works when I change the range o y variable. For example, plot3d(sin(sqrt(x^2+y^2))/sqrt(x^2+y^2), [x,15,15], [y,15,16])$  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1938570&group_id=4933 
From: SourceForge.net <noreply@so...>  20080409 06:37:31

Bugs item #1938349, was opened at 20080409 08:37 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1938349&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: Volker van Nek (van_nek) Assigned to: Nobody/Anonymous (nobody) Summary: sprint cannot print true or false Initial Comment: sprint(true) > error sprint(false) > error these two arguments are not handled properly. by the way, the comments about sprint in src/plot.lisp aren't up to date.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1938349&group_id=4933 
From: SourceForge.net <noreply@so...>  20080407 02:08:51

Bugs item #1934732, was opened at 20080404 14:59 Message generated for change (Comment added) made by rvh2007 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1934732&group_id=4933 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Lisp Core  Plotting Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Plotting Complicated Functions Generates Error Initial Comment: I have been working on plotting an infinite series solution generated by the Frobonius method using Maxima (for both the plots and getting the recursive relation too). The series is, for those interested, a solution to the Shrodinger eq for an electron in a anharmonic occilator with potential k^2*x^4 in one dimension. I arrive at a function f(x, Energy) which turns out to be a rather complicated infinite series and I tried plotting it using plot3d to see the allowed energies for 90 terms. (Yes this actually works). Then for more precision I increased the number of terms to 210 and then it stops working. Don't know why. Any ideas, the only thing I changed is the number of terms? I get an error saying something about "expecting a long float". I have attched the plot for 90 and a wxm for 210 terms file. I don't know what I am doing wrong. Rich Hennessy rvh2007@... Maxima version: 5.14.0Maxima build date: 21:46 12/27/2007host type: i686pcmingw32lispimplementationtype: GNU Common Lisp (GCL)lispimplementationversion: GCL 2.6.8  Comment By: The Henman (rvh2007) Date: 20080406 22:08 Message: Logged In: YES user_id=2055069 Originator: NO This bug only occurs if the grid is very large (approx [grid,860,580]) at lower resolutions it can finish sometimes. I was thinking it might be a memory issue but I don't know. I am still looking for workarounds. Rich  Comment By: The Henman (rvh2007) Date: 20080404 19:02 Message: Logged In: YES user_id=2055069 Originator: NO There should be a single quote before the function plot3d('f(x,...) That does not fix the problem for large terms but it allows you to go higher. I am mentioning that so nobody goes and tries it. I already did. I didn't notice it wa missing in the wxm file I submitted. Rich original submitter.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1934732&group_id=4933 
From: SourceForge.net <noreply@so...>  20080405 22:37:27

Bugs item #820188, was opened at 20031008 13:46 Message generated for change (Comment added) made by robert_dodier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=820188&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: 7 Private: No Submitted By: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: Simplifying inf and minf Initial Comment: The general simplifier currently treats the various non standard objects (inf, minf, und, ind, infinity) as though they were ordinary variables. This leads to incorrect results (infinf => 0, inf*0 => 0), incomplete simplification (inf^3 doesn't simplify, though inf is always correct), and noncanonical representations (minf doesn't simplify to inf). It also seems to me that minf should be represented uniformly as inf, not as a special case. Specialcasing these objects in the general simplifier will add a very small overhead to all simplifications. The case that reminded me of this problem is abs(minf) =>minf.  >Comment By: Robert Dodier (robert_dodier) Date: 20080405 16:37 Message: Logged In: YES user_id=501686 Originator: NO Increasing the priority of this item. See also [ 1562671 ] Handling of infinities.  Comment By: Stavros Macrakis (macrakis) Date: 20040321 14:10 Message: Logged In: YES user_id=588346 More problematic cases with inverse functions: asin(sin(inf)) => inf This should either not simplify, or give IND (if it is clever) or UND (if it is less clever). but exp(log(inf)) => inf tan(atan(inf)) => inf and the like are OK (by accident, but, hey!)  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=820188&group_id=4933 
From: SourceForge.net <noreply@so...>  20080405 22:33:07

Bugs item #1934063, was opened at 20080403 22:27 Message generated for change (Comment added) made by robert_dodier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1934063&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: To be reviewed >Status: Closed >Resolution: Duplicate Priority: 5 Private: No Submitted By: gartuz (gartuz) Assigned to: Nobody/Anonymous (nobody) Summary: integrate(x, x, minf, inf); Initial Comment: integrate(x, x, minf, inf); Maxima version: 5.10.0Maxima build date: 14:57 10/18/2006host type: i686pclinuxgnulispimplementationtype: GNU Common Lisp (GCL)lispimplementationversion: GCL 2.6.7 (%i13) integrate(x, x, minf, inf); Principal Value (%o13) 0 But: It should be: inf  inf But this is not equal to zero but should be considered indefinite.  >Comment By: Robert Dodier (robert_dodier) Date: 20080405 16:33 Message: Logged In: YES user_id=501686 Originator: NO Thanks for this bug report. The underlying problem is that Maxima says inf  inf => 0, so it is a duplicate of [ 1562671 ] Handling of infinities. I've raised the priority of 1562671. Closing this report.  Comment By: Raymond Toy (rtoy) Date: 20080405 14:28 Message: Logged In: YES user_id=28849 Originator: NO Maxima printed out "Principal value". 0 is the principal value for that integral, right?  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1934063&group_id=4933 
From: SourceForge.net <noreply@so...>  20080405 22:31:33

Bugs item #1562671, was opened at 20060921 01:07 Message generated for change (Settings changed) made by robert_dodier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1562671&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: 7 Private: No Submitted By: Elmar Zander (zandere) Assigned to: Nobody/Anonymous (nobody) Summary: Handling of infinities Initial Comment: The handling of inf seems to be like that of a really huge (bigger than everything else) but otherwise specific number. Some examples: infinf => 0 inf/inf => 1 inf*0 => 0 Those should all return "undefined". In the following cases the return value should be directly simplified to inf again inf*inf => inf^2 inf+inf => 2*inf 4*inf => 4*inf Also comparisons like the following should be undefined: is( inf>=inf ) => true if( inf>=2*inf ) => false Furthermore there is no relation between inf and minf: inf => inf minf => minf inf+minf => inf+minf Those should return minf, inf, and und respectively. It would be nice if infinities would be handled like in the IEEE floating point standard which, I think, makes more sense in those cases.  >Comment By: Robert Dodier (robert_dodier) Date: 20080405 16:31 Message: Logged In: YES user_id=501686 Originator: NO Increasing the priority of this item.  Comment By: Stavros Macrakis (macrakis) Date: 20061204 16:50 Message: Logged In: YES user_id=588346 Originator: NO Yes, these limitations are known. Basically, the only parts of Maxima that know about inf/minf/und/ind/infinity are the limit and definite integral packages. As far as the rest of Maxima is concerned, INF is just a variable like X. This is silly, of course. The problem is that correcting this in the obvious way means special cases throughout the simplification code, which assumes that if two identifiers are the same identifier, they are equal.... There are other possible solutions (e.g. making each infinity produced unique in some way), but they have their complications, too....  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1562671&group_id=4933 
From: SourceForge.net <noreply@so...>  20080405 20:30:58

Bugs item #1935418, was opened at 20080405 11:00 Message generated for change (Comment added) made by rtoy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1935418&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: display2d and newline Initial Comment: $ maxima (%i1) display2d:false; (%o1) false (%i2) expand((a+b)*(a+b)); (%o2) b^2+2*a*b+a^2 (%i3) I think there are too much newlines. Especially when I say display2d:false; the line above the output is not longer needed for the exponents and should be removed.  >Comment By: Raymond Toy (rtoy) Date: 20080405 16:30 Message: Logged In: YES user_id=28849 Originator: NO I don't see this: (%i7) display2d:false; (%o7) false (%i8) expand((a+b)^2); (%o8) b^2+2*a*b+a^2 This is with a pretty recent CVS version. What version are you using?  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1935418&group_id=4933 
From: SourceForge.net <noreply@so...>  20080405 20:28:55

Bugs item #1934063, was opened at 20080404 00:27 Message generated for change (Comment added) made by rtoy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1934063&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: To be reviewed Status: Open Resolution: None Priority: 5 Private: No Submitted By: gartuz (gartuz) Assigned to: Nobody/Anonymous (nobody) Summary: integrate(x, x, minf, inf); Initial Comment: integrate(x, x, minf, inf); Maxima version: 5.10.0Maxima build date: 14:57 10/18/2006host type: i686pclinuxgnulispimplementationtype: GNU Common Lisp (GCL)lispimplementationversion: GCL 2.6.7 (%i13) integrate(x, x, minf, inf); Principal Value (%o13) 0 But: It should be: inf  inf But this is not equal to zero but should be considered indefinite.  >Comment By: Raymond Toy (rtoy) Date: 20080405 16:28 Message: Logged In: YES user_id=28849 Originator: NO Maxima printed out "Principal value". 0 is the principal value for that integral, right?  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1934063&group_id=4933 
From: SourceForge.net <noreply@so...>  20080405 20:24:07

Bugs item #1913047, was opened at 20080312 14:44 Message generated for change (Comment added) made by robert_dodier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1913047&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: Matthew Gwynne (proteumus) Assigned to: Nobody/Anonymous (nobody) Summary: gf_set in gf package doesn't terminate on some inputs. Initial Comment: Summary : Calling gf_set(2,1,[x]); results in nontermination. It seems natural to want to generate GF(2), and even if the format of the modulus used isn't correct, it doesn't seem to matter as the problem lies in the combination of b and e, rather than p (as described in Other Information). Version of Maxima : 5.14 Test Case : $ maxima Maxima 5.14.0 http://maxima.sourceforge.net Using Lisp SBCL 1.0.9gentoo 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) load("gf"); (%o1) /usr/share/maxima/5.14.0/share/contrib/gf/gf.mac (%i2) gf_set(2,1,[x]); doesn't terminate. Expected result : $ maxima Maxima 5.14.0 http://maxima.sourceforge.net Using Lisp SBCL 1.0.9gentoo 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) load("gf"); (%o1) /usr/share/maxima/5.14.0/share/contrib/gf/gf.mac (%i2) gf_set(2,1,[x]); (%o2) true Other Information : It seems the problem occurs when gf_findprim() (line 365) is called within gf_set. fastf and slowf both evaluate to the empty list given the arguments (ifactors(1) = [] in both cases) and this leads to f being [], and therefore lf being 0. This then leads to nontermination of the while statement, beginning on line 414, due to the fact that "i" is set to 1 but the inner while statement, beginning on line 430, only executes if i <= lf and of course 1 <= 0 is false. This inner while statement is the only place "found" is set to true and this must occur for the outer while statement to terminate. Reproducible : Always  >Comment By: Robert Dodier (robert_dodier) Date: 20080405 14:24 Message: Logged In: YES user_id=501686 Originator: NO A new version of the GF package has been submitted and committed to CVS. With this new version gf_set(2, 1, [x]) returns true immediately. Please try again with the new version, which will be in Maxima 5.15.0 and its release candidates very soon. Closing this report as fixed.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1913047&group_id=4933 
From: SourceForge.net <noreply@so...>  20080405 19:14:17

Bugs item #1934058, was opened at 20080403 22:20 Message generated for change (Comment added) made by robert_dodier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1934058&group_id=4933 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Lisp Core  Integration Group: None >Status: Closed >Resolution: Duplicate Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: integrate(x, x, minf, inf); Initial Comment: Maxima version: 5.10.0Maxima build date: 14:57 10/18/2006host type: i686pclinuxgnulispimplementationtype: GNU Common Lisp (GCL)lispimplementationversion: GCL 2.6.7 (%i13) integrate(x, x, minf, inf); Principal Value (%o13) 0 But: It should be: inf  inf But this is not equal to zero but should be considered indefinite.  >Comment By: Robert Dodier (robert_dodier) Date: 20080405 13:14 Message: Logged In: YES user_id=501686 Originator: NO Duplicate of: [ 1934063 ] integrate(x, x, minf, inf); Closing this report.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1934058&group_id=4933 
From: SourceForge.net <noreply@so...>  20080405 15:00:14

Bugs item #1935418, was opened at 20080405 08:00 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1935418&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: display2d and newline Initial Comment: $ maxima (%i1) display2d:false; (%o1) false (%i2) expand((a+b)*(a+b)); (%o2) b^2+2*a*b+a^2 (%i3) I think there are too much newlines. Especially when I say display2d:false; the line above the output is not longer needed for the exponents and should be removed.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1935418&group_id=4933 
From: SourceForge.net <noreply@so...>  20080405 14:54:58

Bugs item #1935416, was opened at 20080405 07:54 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1935416&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: ordering Initial Comment: (%i1) expand((a+b)*(a+b)); 2 2 (%o1) b + 2 a b + a This is annoying. I think everybody would expect "a" at the first place and not at the last. And this is not a solution: (%i2) declare(a,mainvar); (%o2) done (%i3) expand((a+b)*(a+b)); 2 2 (%o3) a + 2 b a + b (%i4) because now the middle term is in a unnatural order.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1935416&group_id=4933 
From: SourceForge.net <noreply@so...>  20080404 23:02:49

Bugs item #1934732, was opened at 20080404 14:59 Message generated for change (Comment added) made by rvh2007 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1934732&group_id=4933 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Lisp Core  Plotting Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Plotting Complicated Functions Generates Error Initial Comment: I have been working on plotting an infinite series solution generated by the Frobonius method using Maxima (for both the plots and getting the recursive relation too). The series is, for those interested, a solution to the Shrodinger eq for an electron in a anharmonic occilator with potential k^2*x^4 in one dimension. I arrive at a function f(x, Energy) which turns out to be a rather complicated infinite series and I tried plotting it using plot3d to see the allowed energies for 90 terms. (Yes this actually works). Then for more precision I increased the number of terms to 210 and then it stops working. Don't know why. Any ideas, the only thing I changed is the number of terms? I get an error saying something about "expecting a long float". I have attched the plot for 90 and a wxm for 210 terms file. I don't know what I am doing wrong. Rich Hennessy rvh2007@... Maxima version: 5.14.0Maxima build date: 21:46 12/27/2007host type: i686pcmingw32lispimplementationtype: GNU Common Lisp (GCL)lispimplementationversion: GCL 2.6.8  Comment By: The Henman (rvh2007) Date: 20080404 19:02 Message: Logged In: YES user_id=2055069 Originator: NO There should be a single quote before the function plot3d('f(x,...) That does not fix the problem for large terms but it allows you to go higher. I am mentioning that so nobody goes and tries it. I already did. I didn't notice it wa missing in the wxm file I submitted. Rich original submitter.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1934732&group_id=4933 
From: SourceForge.net <noreply@so...>  20080404 18:59:57

Bugs item #1934732, was opened at 20080404 11:59 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1934732&group_id=4933 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Lisp Core  Plotting Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Plotting Complicated Functions Generates Error Initial Comment: I have been working on plotting an infinite series solution generated by the Frobonius method using Maxima (for both the plots and getting the recursive relation too). The series is, for those interested, a solution to the Shrodinger eq for an electron in a anharmonic occilator with potential k^2*x^4 in one dimension. I arrive at a function f(x, Energy) which turns out to be a rather complicated infinite series and I tried plotting it using plot3d to see the allowed energies for 90 terms. (Yes this actually works). Then for more precision I increased the number of terms to 210 and then it stops working. Don't know why. Any ideas, the only thing I changed is the number of terms? I get an error saying something about "expecting a long float". I have attched the plot for 90 and a wxm for 210 terms file. I don't know what I am doing wrong. Rich Hennessy rvh2007@... Maxima version: 5.14.0Maxima build date: 21:46 12/27/2007host type: i686pcmingw32lispimplementationtype: GNU Common Lisp (GCL)lispimplementationversion: GCL 2.6.8  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1934732&group_id=4933 
From: SourceForge.net <noreply@so...>  20080404 04:27:15

Bugs item #1934063, was opened at 20080403 22:27 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1934063&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: To be reviewed Status: Open Resolution: None Priority: 5 Private: No Submitted By: gartuz (gartuz) Assigned to: Nobody/Anonymous (nobody) Summary: integrate(x, x, minf, inf); Initial Comment: integrate(x, x, minf, inf); Maxima version: 5.10.0Maxima build date: 14:57 10/18/2006host type: i686pclinuxgnulispimplementationtype: GNU Common Lisp (GCL)lispimplementationversion: GCL 2.6.7 (%i13) integrate(x, x, minf, inf); Principal Value (%o13) 0 But: It should be: inf  inf But this is not equal to zero but should be considered indefinite.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1934063&group_id=4933 
From: SourceForge.net <noreply@so...>  20080404 04:20:41

Bugs item #1934058, was opened at 20080403 21:20 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1934058&group_id=4933 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Lisp Core  Integration Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: integrate(x, x, minf, inf); Initial Comment: Maxima version: 5.10.0Maxima build date: 14:57 10/18/2006host type: i686pclinuxgnulispimplementationtype: GNU Common Lisp (GCL)lispimplementationversion: GCL 2.6.7 (%i13) integrate(x, x, minf, inf); Principal Value (%o13) 0 But: It should be: inf  inf But this is not equal to zero but should be considered indefinite.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1934058&group_id=4933 
From: SourceForge.net <noreply@so...>  20080401 21:02:41

Bugs item #1920177, was opened at 20080319 22:07 Message generated for change (Comment added) made by crategus You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1920177&group_id=4933 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Lisp Core Group: Includes proposed fix Status: Open Resolution: None Priority: 5 Private: No Submitted By: Crategus (crategus) Assigned to: Nobody/Anonymous (nobody) Summary: Problems with the bessel functions Initial Comment: There are several problems with the bessel functions. The problems I have found can be divided in the following categories: 1. Inconsistent use of the internal arrays $besselarray, $yarray and $iarray. Example: Restart Maxima and Enter bessel_y(2,1.0). You get an Lisp error. Try first bessel_y(2,1.0) and then repeat bessel_y(2,1.0). Now you get the correct result 1.65...  %i * 3,30... Try bessel_j(2,1.0), you get 0.1149...  %i*2.8142... Next enter bessel_y(2,1.0), you get a Lisp error. The reason for the problems is that the routine bessely uses the global array $YARRAY to store values, but uses also the array $BESSELARRAY to calculate the answer. This is an error. I think the best is to eliminate the use of the global arrays completly. 2. Problematic roundoff errors: Try bessel_j(2,1.0). The result is 0,114903...  %i* 2.8142... e17. The correct result is pure real. The problem is the use of the transformation j[n]=exp(n*%pi*%i)*j[n](x) in the code which produce a small imaginary part. This is a roundoff error for an integer order. In the case of non integer values the imaginary part is correct. So you can not cut off the imaginary part in general. Here is a piece of code which will return an answer which is pure real when the order is an integer (I started to rewrite the code, introduced a function besselj and eliminated the use of the global arrays): (if (integerp order) (if (evenp order) (aref jvals n) ( (aref jvals n)) ) (let ((v (* (cis (* order pi)) (aref jvals n)))) (simplifya `((mplus) ,(realpart v) ((mtimes) $%i ,(imagpart v))) nil ) ) ) 3. Wrong mathematic: Try bessel_j(2.5,1,0). You get 0.04949... Correct is the result 2.8763... * %i Or bessel_j(3,2.0). You get 0,128943... Correct is the result 0.128943... The calculation of the bessel function j[n](x) for real argument x and negativ order n as (realpart (hankel1 order arg)) is not correct. The correct result can be obtained with the formula j[n](x) = 1/2 * (H1[n](x) + H2[n](x)). I tried the following code: (let ((result (* 0.5d0 (+ (hankel1 order arg) (hankel2 order arg))))) (complexify result) ; Problem: you get a small imaginary part ;in the case of a real result (like Problem 2) ; An alternative with a function fpround which round the result ; so that a small imaginary part will vanish ; ; (simplifya ; `((mplus) ; ,(fpround (realpart result) 14) ; ((mtimes) ; ,(fpround (imagpart result) 14) ; $%i ; ) ; ) ; nil ; ) ) This is the definition of the function fpround: (defun fpround (x &optional (digits 1)) (let ((fac (expt 10 digits))) (/ (round x (/ 1 fac)) (float fac)) ) ) I have redesigned a lot of the code for the bessel functions but the work is not finished. Is the work interesting for the project? I use GCL 2.6.6 on Windows XP for programing. Crategus  >Comment By: Crategus (crategus) Date: 20080401 23:02 Message: Logged In: YES user_id=2039760 Originator: YES Again, thank you very much for your interest. I have not changed any of the derivatives. I have only changed the routines which I have listed in this thread. But I have not used the last CVS file. I have used the file which was send with the Maxima 5.14.0 release. There was one change for the derviative for bessel_k since the last release. On Sunday I have installed a tool to download the CVS files. Now I can get the really actual files. The next time I would like to optimize the routines further. Additionally, I am preparing extensive numerical tests for the functions. At the moment I have no idea how to extent the calculation to complex order. In my textbooks and in the book of Abramowitz and Stegun I can't find a relationship which help to calculate the Bessel functions for complex order. Crategus  Comment By: Raymond Toy (rtoy) Date: 20080401 18:41 Message: Logged In: YES user_id=28849 Originator: NO Thank you very much for the updated files. (The diff should have used diff u or diff c, but no matter. The besselchanged.lisp file is perfect.) Given the imminent release of Maxima, I will wait on these changes until after the release. Then I'll try to incorporate your changes. I noticed that you changed the derivatives of some of the Bessel functions. Was that intentional? Were they wrong? (Some of the derivatives need to be in a certain form for some simplifications to be done.)  Comment By: Crategus (crategus) Date: 20080329 22:05 Message: Logged In: YES user_id=2039760 Originator: YES Next I have added a diff between the orginal and the changed file. Question: Is it possible to attach at once more than one file to a message? Crategus File Added: diff.txt  Comment By: Crategus (crategus) Date: 20080329 22:00 Message: Logged In: YES user_id=2039760 Originator: YES I have put all changes of the code for the Bessel functions in the orginal file bessel.lisp which is distributed with Maxima 5.14.0 and attached this file to this message. I have tested the code with the testsuite and the values of the mytest_bessel.mac. Crategus File Added: besselchanged.lisp  Comment By: Crategus (crategus) Date: 20080329 01:35 Message: Logged In: YES user_id=2039760 Originator: YES Thank you very much for your answer. I have redesigned the following routines: simpbesselj (old name besseljsimp) besselj (old name $bessel) simpbessely (old name besselysimp) bessely simpbesseli (old name besselisimp) besseli simpbesselk (old name besselksimp) besselk The new routines are: $hankel_1 simphankel1 $hankel_2 simphankel2 If have further introduced the nouns %hankel_1 und %hankel_2. I would prefer to call the functions $hankel_1 and $hankel_2 and not bessel_hankel. The reason is that these functions are well known as Hankel functions. Because I have collected the routines in a new file it would be a good idea to do the changes in the orginal file bessel.lisp. Than it easier to produce a diff for you. I do this the next time. But first, I would like to have a second look at the global arrays $besselarray, $yarray and $iarray. I think it is not so easy to manage these global arrays in a consistent and predictable way for the user. One reason is, that the code for the numerical calculations use the other functions too (i.e. to calculate bessely we need besselj or for the calculation of besseli we need besselj and besselk). So $besselarray can be destroyed when calculating besseli. It might be possible to prevent this effect by introducing a global flag which signals the internal call of one of the routines. A second point is, that we often dont't use the numerical slatec routines directly. In this case it is necessary to do a lot of extra calculations to obtain the values for the arrays. Perhaps it is useful to decide to fill the global arrays only for the case when we can use the values of the slatec routines directly. This is possible for positive order and argument or positiv order and complex argument of the Bessel functions. Further, an additional flag could be introduced to switch the filling of the arrays on and off. It is also to decide what we do when the user calculate a new value for a Bessel function and the calculation don't fill the global array. In this case, the user may be confused by the fact that the global arrays still hold old values. But for which order and argument? For this case it may be helpful to invalidate the array every time we calculate a new value or to store additionally the order and argument for which the values in the global array are calculated. All these problems with the global arrays arise because of the extension of the routines to negative arguments and orders. In my opinion it would be the best to use the concept of the global arrays no longer. The code becomes much more complicated and the benefit for the user might be small. Crategus  Comment By: Raymond Toy (rtoy) Date: 20080328 17:37 Message: Logged In: YES user_id=28849 Originator: NO First, thank you very much for the fixes to the Bessel routines. I'm sure we all want the routines to be correct! Second, about $besselarray. I see the documentation for that is gone, but I think the intent for besselarray was to let the user have access to all the computed values, since some algorithms end up computing all the intermediate orders to get to the desired order. We need to think if this should go away or not. Third, it would certainly help me a lot if you actually produced a diff between your new code and the existing code. Right now, I have to go look at every single function in different places to figure out what's changed. Trying to minimize the changes would help. I know this is a lot of work for you too. Just identifying which function you actually changed would help a lot too. About the specific changes you mention in the comments. No problem with changing besselxsimp to simpbesselx. (I think most of the code uses simpbesselx, but that's too messy for my tastes.) Extending the range is very, very good. Not sure about the special tests for pure real or imaginary answers. Need to look at that some more. Definitions for Hankel functions are good. May want to name them bessel_hankel_1 to be consistent with other Bessel functions. Certainly want to add some properties like derivatives, but that can wait. All in all, I would very much like to take in your very nice changes.  Comment By: Crategus (crategus) Date: 20080327 17:50 Message: Logged In: YES user_id=2039760 Originator: YES I have tested the Bessel functions with the numerical data attached to this message. For the tests I used a function TEST_BESSEL(value, result, digits) which allow to compare the value with the result within the specified digits. Crategus File Added: mytest_bessel.mac  Comment By: Crategus (crategus) Date: 20080327 17:21 Message: Logged In: YES user_id=2039760 Originator: YES I have finished a first redesign of the code for the numerical calculation of the Bessel functions. I have extended the calculation to or changed parts of the calculation to negative orders and arguments. Perhaps the ideas and the code are interesting for the project. I have added the code to this message. A short description of the changes can be find in the header of the file. Crategus File Added: besselnew.lisp  Comment By: Crategus (crategus) Date: 20080323 18:16 Message: Logged In: YES user_id=2039760 Originator: YES I have added to this posting the code for a routine besselj which handles the above problems. The global array $BESSELARRAY is not used. Futher, I added numerical test values for the the special cases in the code. I used Maxima 5.14.0 and GCL 2.6.6 ANSI to compile the code. The testsuite runs with no unexpected errors found. 22 of the 29 numerical tests I have added give the result within a presision of 16 digits. 7 results have a precision of about 14 to 15 digits. Perhaps, the code is interesting enough for further investigation of the numerical evaluation of the Bessel functions. Crategus File Added: besselj.lisp  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1920177&group_id=4933 
From: SourceForge.net <noreply@so...>  20080401 16:41:37

Bugs item #1920177, was opened at 20080319 17:07 Message generated for change (Comment added) made by rtoy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1920177&group_id=4933 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Lisp Core Group: Includes proposed fix Status: Open Resolution: None Priority: 5 Private: No Submitted By: Crategus (crategus) Assigned to: Nobody/Anonymous (nobody) Summary: Problems with the bessel functions Initial Comment: There are several problems with the bessel functions. The problems I have found can be divided in the following categories: 1. Inconsistent use of the internal arrays $besselarray, $yarray and $iarray. Example: Restart Maxima and Enter bessel_y(2,1.0). You get an Lisp error. Try first bessel_y(2,1.0) and then repeat bessel_y(2,1.0). Now you get the correct result 1.65...  %i * 3,30... Try bessel_j(2,1.0), you get 0.1149...  %i*2.8142... Next enter bessel_y(2,1.0), you get a Lisp error. The reason for the problems is that the routine bessely uses the global array $YARRAY to store values, but uses also the array $BESSELARRAY to calculate the answer. This is an error. I think the best is to eliminate the use of the global arrays completly. 2. Problematic roundoff errors: Try bessel_j(2,1.0). The result is 0,114903...  %i* 2.8142... e17. The correct result is pure real. The problem is the use of the transformation j[n]=exp(n*%pi*%i)*j[n](x) in the code which produce a small imaginary part. This is a roundoff error for an integer order. In the case of non integer values the imaginary part is correct. So you can not cut off the imaginary part in general. Here is a piece of code which will return an answer which is pure real when the order is an integer (I started to rewrite the code, introduced a function besselj and eliminated the use of the global arrays): (if (integerp order) (if (evenp order) (aref jvals n) ( (aref jvals n)) ) (let ((v (* (cis (* order pi)) (aref jvals n)))) (simplifya `((mplus) ,(realpart v) ((mtimes) $%i ,(imagpart v))) nil ) ) ) 3. Wrong mathematic: Try bessel_j(2.5,1,0). You get 0.04949... Correct is the result 2.8763... * %i Or bessel_j(3,2.0). You get 0,128943... Correct is the result 0.128943... The calculation of the bessel function j[n](x) for real argument x and negativ order n as (realpart (hankel1 order arg)) is not correct. The correct result can be obtained with the formula j[n](x) = 1/2 * (H1[n](x) + H2[n](x)). I tried the following code: (let ((result (* 0.5d0 (+ (hankel1 order arg) (hankel2 order arg))))) (complexify result) ; Problem: you get a small imaginary part ;in the case of a real result (like Problem 2) ; An alternative with a function fpround which round the result ; so that a small imaginary part will vanish ; ; (simplifya ; `((mplus) ; ,(fpround (realpart result) 14) ; ((mtimes) ; ,(fpround (imagpart result) 14) ; $%i ; ) ; ) ; nil ; ) ) This is the definition of the function fpround: (defun fpround (x &optional (digits 1)) (let ((fac (expt 10 digits))) (/ (round x (/ 1 fac)) (float fac)) ) ) I have redesigned a lot of the code for the bessel functions but the work is not finished. Is the work interesting for the project? I use GCL 2.6.6 on Windows XP for programing. Crategus  >Comment By: Raymond Toy (rtoy) Date: 20080401 12:41 Message: Logged In: YES user_id=28849 Originator: NO Thank you very much for the updated files. (The diff should have used diff u or diff c, but no matter. The besselchanged.lisp file is perfect.) Given the imminent release of Maxima, I will wait on these changes until after the release. Then I'll try to incorporate your changes. I noticed that you changed the derivatives of some of the Bessel functions. Was that intentional? Were they wrong? (Some of the derivatives need to be in a certain form for some simplifications to be done.)  Comment By: Crategus (crategus) Date: 20080329 17:05 Message: Logged In: YES user_id=2039760 Originator: YES Next I have added a diff between the orginal and the changed file. Question: Is it possible to attach at once more than one file to a message? Crategus File Added: diff.txt  Comment By: Crategus (crategus) Date: 20080329 17:00 Message: Logged In: YES user_id=2039760 Originator: YES I have put all changes of the code for the Bessel functions in the orginal file bessel.lisp which is distributed with Maxima 5.14.0 and attached this file to this message. I have tested the code with the testsuite and the values of the mytest_bessel.mac. Crategus File Added: besselchanged.lisp  Comment By: Crategus (crategus) Date: 20080328 20:35 Message: Logged In: YES user_id=2039760 Originator: YES Thank you very much for your answer. I have redesigned the following routines: simpbesselj (old name besseljsimp) besselj (old name $bessel) simpbessely (old name besselysimp) bessely simpbesseli (old name besselisimp) besseli simpbesselk (old name besselksimp) besselk The new routines are: $hankel_1 simphankel1 $hankel_2 simphankel2 If have further introduced the nouns %hankel_1 und %hankel_2. I would prefer to call the functions $hankel_1 and $hankel_2 and not bessel_hankel. The reason is that these functions are well known as Hankel functions. Because I have collected the routines in a new file it would be a good idea to do the changes in the orginal file bessel.lisp. Than it easier to produce a diff for you. I do this the next time. But first, I would like to have a second look at the global arrays $besselarray, $yarray and $iarray. I think it is not so easy to manage these global arrays in a consistent and predictable way for the user. One reason is, that the code for the numerical calculations use the other functions too (i.e. to calculate bessely we need besselj or for the calculation of besseli we need besselj and besselk). So $besselarray can be destroyed when calculating besseli. It might be possible to prevent this effect by introducing a global flag which signals the internal call of one of the routines. A second point is, that we often dont't use the numerical slatec routines directly. In this case it is necessary to do a lot of extra calculations to obtain the values for the arrays. Perhaps it is useful to decide to fill the global arrays only for the case when we can use the values of the slatec routines directly. This is possible for positive order and argument or positiv order and complex argument of the Bessel functions. Further, an additional flag could be introduced to switch the filling of the arrays on and off. It is also to decide what we do when the user calculate a new value for a Bessel function and the calculation don't fill the global array. In this case, the user may be confused by the fact that the global arrays still hold old values. But for which order and argument? For this case it may be helpful to invalidate the array every time we calculate a new value or to store additionally the order and argument for which the values in the global array are calculated. All these problems with the global arrays arise because of the extension of the routines to negative arguments and orders. In my opinion it would be the best to use the concept of the global arrays no longer. The code becomes much more complicated and the benefit for the user might be small. Crategus  Comment By: Raymond Toy (rtoy) Date: 20080328 12:37 Message: Logged In: YES user_id=28849 Originator: NO First, thank you very much for the fixes to the Bessel routines. I'm sure we all want the routines to be correct! Second, about $besselarray. I see the documentation for that is gone, but I think the intent for besselarray was to let the user have access to all the computed values, since some algorithms end up computing all the intermediate orders to get to the desired order. We need to think if this should go away or not. Third, it would certainly help me a lot if you actually produced a diff between your new code and the existing code. Right now, I have to go look at every single function in different places to figure out what's changed. Trying to minimize the changes would help. I know this is a lot of work for you too. Just identifying which function you actually changed would help a lot too. About the specific changes you mention in the comments. No problem with changing besselxsimp to simpbesselx. (I think most of the code uses simpbesselx, but that's too messy for my tastes.) Extending the range is very, very good. Not sure about the special tests for pure real or imaginary answers. Need to look at that some more. Definitions for Hankel functions are good. May want to name them bessel_hankel_1 to be consistent with other Bessel functions. Certainly want to add some properties like derivatives, but that can wait. All in all, I would very much like to take in your very nice changes.  Comment By: Crategus (crategus) Date: 20080327 12:50 Message: Logged In: YES user_id=2039760 Originator: YES I have tested the Bessel functions with the numerical data attached to this message. For the tests I used a function TEST_BESSEL(value, result, digits) which allow to compare the value with the result within the specified digits. Crategus File Added: mytest_bessel.mac  Comment By: Crategus (crategus) Date: 20080327 12:21 Message: Logged In: YES user_id=2039760 Originator: YES I have finished a first redesign of the code for the numerical calculation of the Bessel functions. I have extended the calculation to or changed parts of the calculation to negative orders and arguments. Perhaps the ideas and the code are interesting for the project. I have added the code to this message. A short description of the changes can be find in the header of the file. Crategus File Added: besselnew.lisp  Comment By: Crategus (crategus) Date: 20080323 13:16 Message: Logged In: YES user_id=2039760 Originator: YES I have added to this posting the code for a routine besselj which handles the above problems. The global array $BESSELARRAY is not used. Futher, I added numerical test values for the the special cases in the code. I used Maxima 5.14.0 and GCL 2.6.6 ANSI to compile the code. The testsuite runs with no unexpected errors found. 22 of the 29 numerical tests I have added give the result within a presision of 16 digits. 7 results have a precision of about 14 to 15 digits. Perhaps, the code is interesting enough for further investigation of the numerical evaluation of the Bessel functions. Crategus File Added: besselj.lisp  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1920177&group_id=4933 