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}
(24) 
_{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...>  20080424 20:14:22

Bugs item #1951123, was opened at 20080424 22:14 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=1951123&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: sort doesn't sort minf and inf Initial Comment: (%i1) is(minf<inf); (%o1) true but (%i2) sort([minf,0,inf]); (%o2) [0, inf, minf]  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1951123&group_id=4933 
From: SourceForge.net <noreply@so...>  20080424 14:39:16

Bugs item #1940411, was opened at 20080411 13:03 Message generated for change (Comment added) made by robert_dodier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1940411&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: adaptive plotting fooled by periodic function Initial Comment: f(x):=sin(4*%pi*x) y:f(x) then, drawing the graph, gets a corrupted sin wave. This problem does not occur if using 2 or 3 intead of 4 in the sin argument, and also it does not occur if typing 3.14 instead of using the %pi constant. Tested using version 0.7.4 of Maxima under Win.  >Comment By: Robert Dodier (robert_dodier) Date: 20080424 08:39 Message: Logged In: YES user_id=501686 Originator: NO I've changed nticks to 29 and committed that as r1.124 src/plot.lisp. That avoids the problem mentioned by the original bug report. That the adaptive plotter tries too hard sometimes is a separate issue and we can open a bug report for that when we get motivated. Closing this report as fixed.  Comment By: Raymond Toy (rtoy) Date: 20080422 18:30 Message: Logged In: YES user_id=28849 Originator: NO I have no problem if you want to change nticks to be some other value. But maybe we should use a larger value, say 47 or 53 or some other prime. Anything other than changing nticks would probably require a huge amount of analysis by maxima to determine sensible values. Nticks is a simple and easily explained way to get more accurate plots. Also, I forgot to mention I'd be opposed to some sort of random sampling. It would be had to explain to users, and it would be annoying if you replot and the graph changes due do different samples being taken. :)  Comment By: Robert Dodier (robert_dodier) Date: 20080422 17:50 Message: Logged In: YES user_id=501686 Originator: NO > Look at what samples are used in plotting the function with the > default of nticks = 10. The samples are at k/2, so we evaluate > the function at sin(2*k*%pi). If we had perfect accuracy, > every sample would be 0. Yes, that is what I meant when I said the adaptive plotter is fooled by periodic functions. > That ntick=7 works better is because the sample values aren't > all zero, and the adaptive plotter refines the data. Is it OK with you if I change nticks from 10 to something like 7 or 13 or 17 ? It doesn't solve the problem but it might make it slightly less likely to be encountered.  Comment By: Raymond Toy (rtoy) Date: 20080421 09:27 Message: Logged In: YES user_id=28849 Originator: NO Look at what samples are used in plotting the function with the default of nticks = 10. The samples are at k/2, so we evaluate the function at sin(2*k*%pi). If we had perfect accuracy, every sample would be 0. What do you expect the adaptive plotter to do? I think the only reason the plot even begins to look right is that roundoff error confuses the adaptive plotter to use more samples. That ntick=7 works better is because the sample values aren't all zero, and the adaptive plotter refines the data. The original plotting algorithm just took nticks samples and plotted them. The default was 100, I think. So plot of sin(100*%pi*x) would fail. You fundamentally have to sample enough (Nyquist theorem tells us so for uniform sampling). The adaptive plotter just makes the plots smoother because we don't use the correct right interpolating function. For the issue where the function is undefined, this is not the fault of the adaptive plotter. Maxima currently doesn't really do anything to indicate that. No error or anything. If maxima could signal an error, the adaptive plotter could catch that and stop trying to refine that area. Might be possible to teach the plotter to be more careful in these cases, but I think it might be tricky.  Comment By: Robert Dodier (robert_dodier) Date: 20080419 10:09 Message: Logged In: YES user_id=501686 Originator: NO > You fundamentally have to sample enough. Then adaptive plotting just helps out by automatically sampling more in places the appear to need it. Ray, I'm sorry, but this just isn't so. The problem is not the lack of samples. nticks=7 (vs nticks=10, the default) yields a nicelooking graph. The problem is that the adaptive plotting algorithm samples at regular intervals. If the function is periodic, it can be fooled into thinking the function is constant. It turns out such functions are easy to construct e.g. plot2d(sin(4*%pi*x), [x, 0, 10]). A simpleminded workaround is to change nticks to some number e.g. nticks=17 which makes the problem go away for some cases but it is still possible to construct a simple function which fools it. Probably the adaptive plotting code should sample irregularly (at random or quasirandom locations) but that is more work. > I would be interested in any other idiosyncrasies you see with adaptive plotting. The major problem that comes to mind is that the adaptive plotter tries too hard where the function is undefined (i.e. returns a nonnumeric value). It appears to hang but actually it is just progressing very slowly. Maybe the plotter could attempt some analysis to determine the domain of the function. That capability (which, I know, would be a lot of work) would be useful in general.  Comment By: Raymond Toy (rtoy) Date: 20080418 10:45 Message: Logged In: YES user_id=28849 Originator: NO I believe that nticks is too small. With or without adaptive plotting, nticks indicates how many samples to take. Before adaptive plotting, I think the default nticks was 100. If the graph looked weird, everyone just bumped up nticks. Adaptive plotting makes it a little easier to get nice looking plots, but if the choice of the xrange and nticks is such that the nticks samples all look pretty much the same, adaptive plotting isn't going to help. You fundamentally have to sample enough. Then adaptive plotting just helps out by automatically sampling more in places the appear to need it. I would be interested in any other idiosyncrasies you see with adaptive plotting.  Comment By: Nobody/Anonymous (nobody) Date: 20080415 23:02 Message: Logged In: NO > look for "ticks" and increase it to say 500 or more. Well, I don't think it's correct to say the value of nticks is too small. The problem is that the adaptive plotting algorithm in plot2d is easily fooled into thinking that a function is constant. You can get better results by making nticks a prime number, say 7 or 11 (the default is 10). e.g. plot2d (sin(4*%pi*x), [x, 0, 10]); => spurious flat parts plot2d (sin(4*%pi*x), [x, 0, 10], [nticks, 11]); => looks right To resolve this we probably need to rethink the adaptive plotting stuff. If I'm not mistaken it has other idiosyncrasies. As a stopgap measure maybe we can change the default value of nticks to 11. Robert Dodier (not logged in)  Comment By: Barton Willis (willisbl) Date: 20080411 23:49 Message: Logged In: YES user_id=895922 Originator: NO I'm guessing that you used wxMaxima 0.74 and used the ploting > plot2d menu item. The default for the number of ticks was too small in that version. In the menu box, look for "ticks" and increase it to say 500 or more. I think there is a wxMaxima 0.74a that has a larger value for the default for ticks. Maybe you can look for that. wxMaxima 0.74sa might be part of Maxima 5.14.0 now  I think some Maxima versions 5.14.0 have wxMaxima 0.74 and others 0.74a.  Comment By: Raymond Toy (rtoy) Date: 20080411 13:49 Message: Logged In: YES user_id=28849 Originator: NO Show exactly what you did. In what way is the sine wave corrupted? What does build_info() say? Are you really using Maxima 0.7.4? Is that the wxmaxima version? I don't recall any 0.7.4 version of Maxima.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1940411&group_id=4933 
From: SourceForge.net <noreply@so...>  20080424 14:15:34

Bugs item #1934732, was opened at 20080404 12:59 Message generated for change (Settings changed) made by robert_dodier 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: Closed >Resolution: Invalid 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: Robert Dodier (robert_dodier) Date: 20080424 08:15 Message: Logged In: YES user_id=501686 Originator: NO Rich, this is an interesting problem but unfortunately this report just doesn't function as a bug report. It is very far from clear what the problem is, and it would take a lot of effort to narrow the problem from the information given here. I'm closing this bug report, but if you can find a small, reproducible example of the problem, you can open a new bug report. best, Robert Dodier  Comment By: The Henman (rvh2007) Date: 20080406 20: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 17: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...>  20080424 12:24:49

Bugs item #1950653, was opened at 20080424 07:24 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=1950653&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: Barton Willis (willisbl) Assigned to: Nobody/Anonymous (nobody) Summary: bessel_j not simplified Initial Comment: (%i1) besselexpand : true$ Wrong, should be 0: (%i2) bessel_j(1/2,%pi); (%o2) (sqrt(2)*sin(%pi))/%pi Look at bessel_j)1/2,x). The simp flag is missing from the sin term. I'd guess that the bessel code needs to do (take '(%sin) xxx) where it does something like (cons '(%sin) xxx) (%i3) bessel_j(1/2,x); (%o3) (sqrt(2)*sin(x))/(sqrt(%pi)*sqrt(x)) (%i4) ?print(%); ((MTIMES SIMP) ((MEXPT SIMP) 2 ((RAT SIMP) 1 2)) ((MEXPT SIMP) $%PI ((RAT SIMP) 1 2)) ((MEXPT SIMP) $X ((RAT SIMP) 1 2)) ((%SIN) $X)) (%o4) (sqrt(2)*sin(x))/(sqrt(%pi)*sqrt(x))  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1950653&group_id=4933 
From: SourceForge.net <noreply@so...>  20080424 03:41:22

Bugs item #1950294, was opened at 20080423 20:41 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=1950294&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: more on integrate(1/cosh(a*x)^2,x,inf,inf) Initial Comment: integrate(1/cosh(3*x)^2,x,inf,inf); returns Division by 0  an error. To debug this try debugmode(true); integrate(1/cosh(4*x)^2,x,inf,inf); returns << Expression too long to display! >> Eric  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1950294&group_id=4933 
From: SourceForge.net <noreply@so...>  20080423 02:51:19

Bugs item #1949337, was opened at 20080422 21:51 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=1949337&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: Barton Willis (willisbl) Assigned to: Nobody/Anonymous (nobody) Summary: complexnumberp test for floatp Initial Comment: (%i1) x : 3.1 + %i * 1.7; (%o1) 1.7*%i+3.1 This is wrong: (%i2) :lisp(complexnumberp (meval $x) 'floatp); NIL Thi is OK (%i2) :lisp(complexnumberp (meval $x) 'mnump); T I think this is due to the (N 1) check in complexnumberp. Maxima version: 5.14.99rc1 Maxima build date: 11:38 4/12/2008  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1949337&group_id=4933 
From: SourceForge.net <noreply@so...>  20080423 00:30:31

Bugs item #1940411, was opened at 20080411 15:03 Message generated for change (Comment added) made by rtoy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1940411&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: adaptive plotting fooled by periodic function Initial Comment: f(x):=sin(4*%pi*x) y:f(x) then, drawing the graph, gets a corrupted sin wave. This problem does not occur if using 2 or 3 intead of 4 in the sin argument, and also it does not occur if typing 3.14 instead of using the %pi constant. Tested using version 0.7.4 of Maxima under Win.  >Comment By: Raymond Toy (rtoy) Date: 20080422 20:30 Message: Logged In: YES user_id=28849 Originator: NO I have no problem if you want to change nticks to be some other value. But maybe we should use a larger value, say 47 or 53 or some other prime. Anything other than changing nticks would probably require a huge amount of analysis by maxima to determine sensible values. Nticks is a simple and easily explained way to get more accurate plots. Also, I forgot to mention I'd be opposed to some sort of random sampling. It would be had to explain to users, and it would be annoying if you replot and the graph changes due do different samples being taken. :)  Comment By: Robert Dodier (robert_dodier) Date: 20080422 19:50 Message: Logged In: YES user_id=501686 Originator: NO > Look at what samples are used in plotting the function with the > default of nticks = 10. The samples are at k/2, so we evaluate > the function at sin(2*k*%pi). If we had perfect accuracy, > every sample would be 0. Yes, that is what I meant when I said the adaptive plotter is fooled by periodic functions. > That ntick=7 works better is because the sample values aren't > all zero, and the adaptive plotter refines the data. Is it OK with you if I change nticks from 10 to something like 7 or 13 or 17 ? It doesn't solve the problem but it might make it slightly less likely to be encountered.  Comment By: Raymond Toy (rtoy) Date: 20080421 11:27 Message: Logged In: YES user_id=28849 Originator: NO Look at what samples are used in plotting the function with the default of nticks = 10. The samples are at k/2, so we evaluate the function at sin(2*k*%pi). If we had perfect accuracy, every sample would be 0. What do you expect the adaptive plotter to do? I think the only reason the plot even begins to look right is that roundoff error confuses the adaptive plotter to use more samples. That ntick=7 works better is because the sample values aren't all zero, and the adaptive plotter refines the data. The original plotting algorithm just took nticks samples and plotted them. The default was 100, I think. So plot of sin(100*%pi*x) would fail. You fundamentally have to sample enough (Nyquist theorem tells us so for uniform sampling). The adaptive plotter just makes the plots smoother because we don't use the correct right interpolating function. For the issue where the function is undefined, this is not the fault of the adaptive plotter. Maxima currently doesn't really do anything to indicate that. No error or anything. If maxima could signal an error, the adaptive plotter could catch that and stop trying to refine that area. Might be possible to teach the plotter to be more careful in these cases, but I think it might be tricky.  Comment By: Robert Dodier (robert_dodier) Date: 20080419 12:09 Message: Logged In: YES user_id=501686 Originator: NO > You fundamentally have to sample enough. Then adaptive plotting just helps out by automatically sampling more in places the appear to need it. Ray, I'm sorry, but this just isn't so. The problem is not the lack of samples. nticks=7 (vs nticks=10, the default) yields a nicelooking graph. The problem is that the adaptive plotting algorithm samples at regular intervals. If the function is periodic, it can be fooled into thinking the function is constant. It turns out such functions are easy to construct e.g. plot2d(sin(4*%pi*x), [x, 0, 10]). A simpleminded workaround is to change nticks to some number e.g. nticks=17 which makes the problem go away for some cases but it is still possible to construct a simple function which fools it. Probably the adaptive plotting code should sample irregularly (at random or quasirandom locations) but that is more work. > I would be interested in any other idiosyncrasies you see with adaptive plotting. The major problem that comes to mind is that the adaptive plotter tries too hard where the function is undefined (i.e. returns a nonnumeric value). It appears to hang but actually it is just progressing very slowly. Maybe the plotter could attempt some analysis to determine the domain of the function. That capability (which, I know, would be a lot of work) would be useful in general.  Comment By: Raymond Toy (rtoy) Date: 20080418 12:45 Message: Logged In: YES user_id=28849 Originator: NO I believe that nticks is too small. With or without adaptive plotting, nticks indicates how many samples to take. Before adaptive plotting, I think the default nticks was 100. If the graph looked weird, everyone just bumped up nticks. Adaptive plotting makes it a little easier to get nice looking plots, but if the choice of the xrange and nticks is such that the nticks samples all look pretty much the same, adaptive plotting isn't going to help. You fundamentally have to sample enough. Then adaptive plotting just helps out by automatically sampling more in places the appear to need it. I would be interested in any other idiosyncrasies you see with adaptive plotting.  Comment By: Nobody/Anonymous (nobody) Date: 20080416 01:02 Message: Logged In: NO > look for "ticks" and increase it to say 500 or more. Well, I don't think it's correct to say the value of nticks is too small. The problem is that the adaptive plotting algorithm in plot2d is easily fooled into thinking that a function is constant. You can get better results by making nticks a prime number, say 7 or 11 (the default is 10). e.g. plot2d (sin(4*%pi*x), [x, 0, 10]); => spurious flat parts plot2d (sin(4*%pi*x), [x, 0, 10], [nticks, 11]); => looks right To resolve this we probably need to rethink the adaptive plotting stuff. If I'm not mistaken it has other idiosyncrasies. As a stopgap measure maybe we can change the default value of nticks to 11. Robert Dodier (not logged in)  Comment By: Barton Willis (willisbl) Date: 20080412 01:49 Message: Logged In: YES user_id=895922 Originator: NO I'm guessing that you used wxMaxima 0.74 and used the ploting > plot2d menu item. The default for the number of ticks was too small in that version. In the menu box, look for "ticks" and increase it to say 500 or more. I think there is a wxMaxima 0.74a that has a larger value for the default for ticks. Maybe you can look for that. wxMaxima 0.74sa might be part of Maxima 5.14.0 now  I think some Maxima versions 5.14.0 have wxMaxima 0.74 and others 0.74a.  Comment By: Raymond Toy (rtoy) Date: 20080411 15:49 Message: Logged In: YES user_id=28849 Originator: NO Show exactly what you did. In what way is the sine wave corrupted? What does build_info() say? Are you really using Maxima 0.7.4? Is that the wxmaxima version? I don't recall any 0.7.4 version of Maxima.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1940411&group_id=4933 
From: SourceForge.net <noreply@so...>  20080422 23:50:28

Bugs item #1940411, was opened at 20080411 13:03 Message generated for change (Comment added) made by robert_dodier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1940411&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: adaptive plotting fooled by periodic function Initial Comment: f(x):=sin(4*%pi*x) y:f(x) then, drawing the graph, gets a corrupted sin wave. This problem does not occur if using 2 or 3 intead of 4 in the sin argument, and also it does not occur if typing 3.14 instead of using the %pi constant. Tested using version 0.7.4 of Maxima under Win.  >Comment By: Robert Dodier (robert_dodier) Date: 20080422 17:50 Message: Logged In: YES user_id=501686 Originator: NO > Look at what samples are used in plotting the function with the > default of nticks = 10. The samples are at k/2, so we evaluate > the function at sin(2*k*%pi). If we had perfect accuracy, > every sample would be 0. Yes, that is what I meant when I said the adaptive plotter is fooled by periodic functions. > That ntick=7 works better is because the sample values aren't > all zero, and the adaptive plotter refines the data. Is it OK with you if I change nticks from 10 to something like 7 or 13 or 17 ? It doesn't solve the problem but it might make it slightly less likely to be encountered.  Comment By: Raymond Toy (rtoy) Date: 20080421 09:27 Message: Logged In: YES user_id=28849 Originator: NO Look at what samples are used in plotting the function with the default of nticks = 10. The samples are at k/2, so we evaluate the function at sin(2*k*%pi). If we had perfect accuracy, every sample would be 0. What do you expect the adaptive plotter to do? I think the only reason the plot even begins to look right is that roundoff error confuses the adaptive plotter to use more samples. That ntick=7 works better is because the sample values aren't all zero, and the adaptive plotter refines the data. The original plotting algorithm just took nticks samples and plotted them. The default was 100, I think. So plot of sin(100*%pi*x) would fail. You fundamentally have to sample enough (Nyquist theorem tells us so for uniform sampling). The adaptive plotter just makes the plots smoother because we don't use the correct right interpolating function. For the issue where the function is undefined, this is not the fault of the adaptive plotter. Maxima currently doesn't really do anything to indicate that. No error or anything. If maxima could signal an error, the adaptive plotter could catch that and stop trying to refine that area. Might be possible to teach the plotter to be more careful in these cases, but I think it might be tricky.  Comment By: Robert Dodier (robert_dodier) Date: 20080419 10:09 Message: Logged In: YES user_id=501686 Originator: NO > You fundamentally have to sample enough. Then adaptive plotting just helps out by automatically sampling more in places the appear to need it. Ray, I'm sorry, but this just isn't so. The problem is not the lack of samples. nticks=7 (vs nticks=10, the default) yields a nicelooking graph. The problem is that the adaptive plotting algorithm samples at regular intervals. If the function is periodic, it can be fooled into thinking the function is constant. It turns out such functions are easy to construct e.g. plot2d(sin(4*%pi*x), [x, 0, 10]). A simpleminded workaround is to change nticks to some number e.g. nticks=17 which makes the problem go away for some cases but it is still possible to construct a simple function which fools it. Probably the adaptive plotting code should sample irregularly (at random or quasirandom locations) but that is more work. > I would be interested in any other idiosyncrasies you see with adaptive plotting. The major problem that comes to mind is that the adaptive plotter tries too hard where the function is undefined (i.e. returns a nonnumeric value). It appears to hang but actually it is just progressing very slowly. Maybe the plotter could attempt some analysis to determine the domain of the function. That capability (which, I know, would be a lot of work) would be useful in general.  Comment By: Raymond Toy (rtoy) Date: 20080418 10:45 Message: Logged In: YES user_id=28849 Originator: NO I believe that nticks is too small. With or without adaptive plotting, nticks indicates how many samples to take. Before adaptive plotting, I think the default nticks was 100. If the graph looked weird, everyone just bumped up nticks. Adaptive plotting makes it a little easier to get nice looking plots, but if the choice of the xrange and nticks is such that the nticks samples all look pretty much the same, adaptive plotting isn't going to help. You fundamentally have to sample enough. Then adaptive plotting just helps out by automatically sampling more in places the appear to need it. I would be interested in any other idiosyncrasies you see with adaptive plotting.  Comment By: Nobody/Anonymous (nobody) Date: 20080415 23:02 Message: Logged In: NO > look for "ticks" and increase it to say 500 or more. Well, I don't think it's correct to say the value of nticks is too small. The problem is that the adaptive plotting algorithm in plot2d is easily fooled into thinking that a function is constant. You can get better results by making nticks a prime number, say 7 or 11 (the default is 10). e.g. plot2d (sin(4*%pi*x), [x, 0, 10]); => spurious flat parts plot2d (sin(4*%pi*x), [x, 0, 10], [nticks, 11]); => looks right To resolve this we probably need to rethink the adaptive plotting stuff. If I'm not mistaken it has other idiosyncrasies. As a stopgap measure maybe we can change the default value of nticks to 11. Robert Dodier (not logged in)  Comment By: Barton Willis (willisbl) Date: 20080411 23:49 Message: Logged In: YES user_id=895922 Originator: NO I'm guessing that you used wxMaxima 0.74 and used the ploting > plot2d menu item. The default for the number of ticks was too small in that version. In the menu box, look for "ticks" and increase it to say 500 or more. I think there is a wxMaxima 0.74a that has a larger value for the default for ticks. Maybe you can look for that. wxMaxima 0.74sa might be part of Maxima 5.14.0 now  I think some Maxima versions 5.14.0 have wxMaxima 0.74 and others 0.74a.  Comment By: Raymond Toy (rtoy) Date: 20080411 13:49 Message: Logged In: YES user_id=28849 Originator: NO Show exactly what you did. In what way is the sine wave corrupted? What does build_info() say? Are you really using Maxima 0.7.4? Is that the wxmaxima version? I don't recall any 0.7.4 version of Maxima.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1940411&group_id=4933 
From: SourceForge.net <noreply@so...>  20080421 15:27:38

Bugs item #1940411, was opened at 20080411 15:03 Message generated for change (Comment added) made by rtoy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1940411&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: adaptive plotting fooled by periodic function Initial Comment: f(x):=sin(4*%pi*x) y:f(x) then, drawing the graph, gets a corrupted sin wave. This problem does not occur if using 2 or 3 intead of 4 in the sin argument, and also it does not occur if typing 3.14 instead of using the %pi constant. Tested using version 0.7.4 of Maxima under Win.  >Comment By: Raymond Toy (rtoy) Date: 20080421 11:27 Message: Logged In: YES user_id=28849 Originator: NO Look at what samples are used in plotting the function with the default of nticks = 10. The samples are at k/2, so we evaluate the function at sin(2*k*%pi). If we had perfect accuracy, every sample would be 0. What do you expect the adaptive plotter to do? I think the only reason the plot even begins to look right is that roundoff error confuses the adaptive plotter to use more samples. That ntick=7 works better is because the sample values aren't all zero, and the adaptive plotter refines the data. The original plotting algorithm just took nticks samples and plotted them. The default was 100, I think. So plot of sin(100*%pi*x) would fail. You fundamentally have to sample enough (Nyquist theorem tells us so for uniform sampling). The adaptive plotter just makes the plots smoother because we don't use the correct right interpolating function. For the issue where the function is undefined, this is not the fault of the adaptive plotter. Maxima currently doesn't really do anything to indicate that. No error or anything. If maxima could signal an error, the adaptive plotter could catch that and stop trying to refine that area. Might be possible to teach the plotter to be more careful in these cases, but I think it might be tricky.  Comment By: Robert Dodier (robert_dodier) Date: 20080419 12:09 Message: Logged In: YES user_id=501686 Originator: NO > You fundamentally have to sample enough. Then adaptive plotting just helps out by automatically sampling more in places the appear to need it. Ray, I'm sorry, but this just isn't so. The problem is not the lack of samples. nticks=7 (vs nticks=10, the default) yields a nicelooking graph. The problem is that the adaptive plotting algorithm samples at regular intervals. If the function is periodic, it can be fooled into thinking the function is constant. It turns out such functions are easy to construct e.g. plot2d(sin(4*%pi*x), [x, 0, 10]). A simpleminded workaround is to change nticks to some number e.g. nticks=17 which makes the problem go away for some cases but it is still possible to construct a simple function which fools it. Probably the adaptive plotting code should sample irregularly (at random or quasirandom locations) but that is more work. > I would be interested in any other idiosyncrasies you see with adaptive plotting. The major problem that comes to mind is that the adaptive plotter tries too hard where the function is undefined (i.e. returns a nonnumeric value). It appears to hang but actually it is just progressing very slowly. Maybe the plotter could attempt some analysis to determine the domain of the function. That capability (which, I know, would be a lot of work) would be useful in general.  Comment By: Raymond Toy (rtoy) Date: 20080418 12:45 Message: Logged In: YES user_id=28849 Originator: NO I believe that nticks is too small. With or without adaptive plotting, nticks indicates how many samples to take. Before adaptive plotting, I think the default nticks was 100. If the graph looked weird, everyone just bumped up nticks. Adaptive plotting makes it a little easier to get nice looking plots, but if the choice of the xrange and nticks is such that the nticks samples all look pretty much the same, adaptive plotting isn't going to help. You fundamentally have to sample enough. Then adaptive plotting just helps out by automatically sampling more in places the appear to need it. I would be interested in any other idiosyncrasies you see with adaptive plotting.  Comment By: Nobody/Anonymous (nobody) Date: 20080416 01:02 Message: Logged In: NO > look for "ticks" and increase it to say 500 or more. Well, I don't think it's correct to say the value of nticks is too small. The problem is that the adaptive plotting algorithm in plot2d is easily fooled into thinking that a function is constant. You can get better results by making nticks a prime number, say 7 or 11 (the default is 10). e.g. plot2d (sin(4*%pi*x), [x, 0, 10]); => spurious flat parts plot2d (sin(4*%pi*x), [x, 0, 10], [nticks, 11]); => looks right To resolve this we probably need to rethink the adaptive plotting stuff. If I'm not mistaken it has other idiosyncrasies. As a stopgap measure maybe we can change the default value of nticks to 11. Robert Dodier (not logged in)  Comment By: Barton Willis (willisbl) Date: 20080412 01:49 Message: Logged In: YES user_id=895922 Originator: NO I'm guessing that you used wxMaxima 0.74 and used the ploting > plot2d menu item. The default for the number of ticks was too small in that version. In the menu box, look for "ticks" and increase it to say 500 or more. I think there is a wxMaxima 0.74a that has a larger value for the default for ticks. Maybe you can look for that. wxMaxima 0.74sa might be part of Maxima 5.14.0 now  I think some Maxima versions 5.14.0 have wxMaxima 0.74 and others 0.74a.  Comment By: Raymond Toy (rtoy) Date: 20080411 15:49 Message: Logged In: YES user_id=28849 Originator: NO Show exactly what you did. In what way is the sine wave corrupted? What does build_info() say? Are you really using Maxima 0.7.4? Is that the wxmaxima version? I don't recall any 0.7.4 version of Maxima.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1940411&group_id=4933 
From: SourceForge.net <noreply@so...>  20080421 13:38:39

Bugs item #1943756, was opened at 20080416 05:12 Message generated for change (Settings changed) made by dgildea You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1943756&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: Satoshi Adachi (satoshi_adachi) Assigned to: Nobody/Anonymous (nobody) Summary: ezgcd() never returns. Initial Comment: Dear Developers of Maxima, I met a set of two polynomials whose gcd polynomial cannot be calculated by ezgcd(). ezgcd() seems to be put into an infinite loop. If gcd() is used instead of ezgcd(), the gcd polynomial is calculated normally. A Maxima program for the demonstration is as follows  /* * ezgcd_does_not_return.maxima: * * S.Adachi 2008/04/16 */ display2d:false; F:n^2+(2*d+c+b+2)*n+d^2+(cb2)*d+c+b+1; G:n^2+(2*dcb2)*nd^2+(c+b+2)*d+(b1)*cb1; gcd(F,G); /* OK */ ezgcd(F,G); /* Does not return! */ /* END */  The result of execution is as follows  [Macintosh:~/work/289:1] adachi% maxima b ezgcd_does_not_return.maxima 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(ezgcd_does_not_return.maxima) batching #p/Volumes/HFS+2/home/adachi/work/289/ezgcd_does_not_return.maxima (%i2) display2d : false (%o2) false (%i3) F:1+b+c+(2bc)*d+d^2+(2+b+c2*d)*n+n^2 (%o3) n^2+(2*d+c+b+2)*n+d^2+(cb2)*d+c+b+1 (%i4) G:1b+(1b)*c+(2+b+c)*dd^2+(2bc+2*d)*nn^2 (%o4) n^2+(2*dcb2)*nd^2+(c+b+2)*d+(b1)*cb1 (%i5) gcd(F,G) (%o5) 1 (%i6) ezgcd(F,G) ^CMaxima encountered a Lisp error: Console interrupt. Automatically continuing. To reenable the Lisp debugger set *debuggerhook* to nil. (%o7) "ezgcd_does_not_return.maxima"  Here, I had to stop the program by console interrupt. Please fix this bug of ezgcd(). Sincrely yours, Satoshi Adachi  >Comment By: Dan Gildea (dgildea) Date: 20080421 09:38 Message: Logged In: YES user_id=1797506 Originator: NO Fixed in ezgcd.lisp rev 1.8. In fastcont, use "intersect", not cl "intersection", in order to maintain order of genvar list.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1943756&group_id=4933 
From: SourceForge.net <noreply@so...>  20080421 13:02:22

Bugs item #1947806, was opened at 20080421 09:02 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=1947806&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: Includes proposed fix Status: Open Resolution: None Priority: 5 Private: No Submitted By: Ed Beroset (beroset) Assigned to: Nobody/Anonymous (nobody) Summary: ilt documented variable order incorrect Initial Comment: In maxima/maxima/doc/info/Integration.texi, line 186 currently reads: @deffn {Function} ilt (@var{expr}, @var{t}, @var{s}) However, as the example below correctly shows, the variables t and s should be reversed, and the line should read: @deffn {Function} ilt (@var{expr}, @var{s}, @var{t})  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1947806&group_id=4933 
From: SourceForge.net <noreply@so...>  20080419 16:33:35

Bugs item #1930350, was opened at 20080331 11:28 Message generated for change (Comment added) made by robert_dodier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1930350&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: 2^2391 does not factorize properly Initial Comment: I TYPED: :lisp (factor (factor ( (expt 2 239) 1))); RESULT: ((MTIMES SIMP FACTORED) 479 1913 5737 168048109206150821918223503032486170915673848376760773023074113) EXPECTED: ((MTIMES SIMP FACTORED)479 1913 5737 176383 134000609 7110008717824458123105014279253754096863768062879) EMAIL: irdaqramo@...  >Comment By: Robert Dodier (robert_dodier) Date: 20080419 10:33 Message: Logged In: YES user_id=501686 Originator: NO Closing this report as "works for me". As explained by andrejv, the reported behavior is to be expected.  Comment By: Andrej Vodopivec (andrejv) Date: 20080331 14:29 Message: Logged In: YES user_id=1179910 Originator: NO This working as intended. The simplification routines in maxima sometimes factor integers. For obvious reasons, factoring large integers is disabled by default. This is controlled with the option variable intfaclim. This command gives correct factorization: :lisp (let (($intfaclim nil)) (factor ( (expt 2 239) 1))) This bug should be closed as invalid. I will leave it open for some time in case someone returns to see a reply. Andrej  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1930350&group_id=4933 
From: SourceForge.net <noreply@so...>  20080419 16:32:01

Bugs item #1929287, was opened at 20080330 05:34 Message generated for change (Comment added) made by robert_dodier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1929287&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: 4 Private: No Submitted By: Barton Willis (willisbl) Assigned to: Nobody/Anonymous (nobody) Summary: 0.0 + [0] > [0] Initial Comment: OK: (%i1) 0.0 + 0; (%o1) 0.0 Not OK; (%o2) should be [0.0], not [0] (%i2) 0.0 + [0]; (%o2) [0] Also, 0.0b0 + [0] > [0]. Matrix addition has the same bug: (%i6) 0.0 + matrix([0,0]); (%o6) matrix([0,0])  >Comment By: Robert Dodier (robert_dodier) Date: 20080419 10:32 Message: Logged In: YES user_id=501686 Originator: NO I'm guessing that the behavior 0.0 + [0] => [0] comes from the same place as 0.0 + foo => foo, 0.0 + foo(x) => foo(x). Maybe we should disallow the simplification (inexact zero) + (whatever) => (whatever). Not sure what we should do at this point.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1929287&group_id=4933 
From: SourceForge.net <noreply@so...>  20080419 16:13:50

Bugs item #1935418, was opened at 20080405 09:00 Message generated for change (Comment added) made by robert_dodier 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: Lisp Core Group: None >Status: Closed >Resolution: Wont Fix 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: Robert Dodier (robert_dodier) Date: 20080419 10:13 Message: Logged In: YES user_id=501686 Originator: NO Closing this report as "won't fix". The problem originates from implementationdependent behavior. I don't think it's important enough to work around it. Someone can reopen this when they feel inspired to deal with FRESHLINE.  Comment By: Nobody/Anonymous (nobody) Date: 20080415 23:08 Message: Logged In: NO I'm pretty sure the observed behavior is due to implementationdependent interpretations of FRESHLINE. I see the observed behavior with cvs Maxima + GCL and SBCL, but not Clisp. I don't know which has the correct implementation of FRESHLINE, or if they're all equally correct. I don't know how much we can do about this, or want to do. Robert Dodier (not logged in)  Comment By: Nobody/Anonymous (nobody) Date: 20080409 15: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 14: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...>  20080419 16:09:23

Bugs item #1940411, was opened at 20080411 13:03 Message generated for change (Comment added) made by robert_dodier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1940411&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: adaptive plotting fooled by periodic function Initial Comment: f(x):=sin(4*%pi*x) y:f(x) then, drawing the graph, gets a corrupted sin wave. This problem does not occur if using 2 or 3 intead of 4 in the sin argument, and also it does not occur if typing 3.14 instead of using the %pi constant. Tested using version 0.7.4 of Maxima under Win.  >Comment By: Robert Dodier (robert_dodier) Date: 20080419 10:09 Message: Logged In: YES user_id=501686 Originator: NO > You fundamentally have to sample enough. Then adaptive plotting just helps out by automatically sampling more in places the appear to need it. Ray, I'm sorry, but this just isn't so. The problem is not the lack of samples. nticks=7 (vs nticks=10, the default) yields a nicelooking graph. The problem is that the adaptive plotting algorithm samples at regular intervals. If the function is periodic, it can be fooled into thinking the function is constant. It turns out such functions are easy to construct e.g. plot2d(sin(4*%pi*x), [x, 0, 10]). A simpleminded workaround is to change nticks to some number e.g. nticks=17 which makes the problem go away for some cases but it is still possible to construct a simple function which fools it. Probably the adaptive plotting code should sample irregularly (at random or quasirandom locations) but that is more work. > I would be interested in any other idiosyncrasies you see with adaptive plotting. The major problem that comes to mind is that the adaptive plotter tries too hard where the function is undefined (i.e. returns a nonnumeric value). It appears to hang but actually it is just progressing very slowly. Maybe the plotter could attempt some analysis to determine the domain of the function. That capability (which, I know, would be a lot of work) would be useful in general.  Comment By: Raymond Toy (rtoy) Date: 20080418 10:45 Message: Logged In: YES user_id=28849 Originator: NO I believe that nticks is too small. With or without adaptive plotting, nticks indicates how many samples to take. Before adaptive plotting, I think the default nticks was 100. If the graph looked weird, everyone just bumped up nticks. Adaptive plotting makes it a little easier to get nice looking plots, but if the choice of the xrange and nticks is such that the nticks samples all look pretty much the same, adaptive plotting isn't going to help. You fundamentally have to sample enough. Then adaptive plotting just helps out by automatically sampling more in places the appear to need it. I would be interested in any other idiosyncrasies you see with adaptive plotting.  Comment By: Nobody/Anonymous (nobody) Date: 20080415 23:02 Message: Logged In: NO > look for "ticks" and increase it to say 500 or more. Well, I don't think it's correct to say the value of nticks is too small. The problem is that the adaptive plotting algorithm in plot2d is easily fooled into thinking that a function is constant. You can get better results by making nticks a prime number, say 7 or 11 (the default is 10). e.g. plot2d (sin(4*%pi*x), [x, 0, 10]); => spurious flat parts plot2d (sin(4*%pi*x), [x, 0, 10], [nticks, 11]); => looks right To resolve this we probably need to rethink the adaptive plotting stuff. If I'm not mistaken it has other idiosyncrasies. As a stopgap measure maybe we can change the default value of nticks to 11. Robert Dodier (not logged in)  Comment By: Barton Willis (willisbl) Date: 20080411 23:49 Message: Logged In: YES user_id=895922 Originator: NO I'm guessing that you used wxMaxima 0.74 and used the ploting > plot2d menu item. The default for the number of ticks was too small in that version. In the menu box, look for "ticks" and increase it to say 500 or more. I think there is a wxMaxima 0.74a that has a larger value for the default for ticks. Maybe you can look for that. wxMaxima 0.74sa might be part of Maxima 5.14.0 now  I think some Maxima versions 5.14.0 have wxMaxima 0.74 and others 0.74a.  Comment By: Raymond Toy (rtoy) Date: 20080411 13:49 Message: Logged In: YES user_id=28849 Originator: NO Show exactly what you did. In what way is the sine wave corrupted? What does build_info() say? Are you really using Maxima 0.7.4? Is that the wxmaxima version? I don't recall any 0.7.4 version of Maxima.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1940411&group_id=4933 
From: SourceForge.net <noreply@so...>  20080418 17:03:01

Bugs item #1945954, was opened at 20080418 12:45 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=1945954&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: 5 Private: No Submitted By: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: simpsum/simplify_sum with summand=f(i)+q Initial Comment: sum(q,i,1,inf) => asks whether q is pnz and gives inf,0,minf This is correct, and works with simpsum:true, simpsum:false, and simplify_sum. Similarly, sum(f(i),i,1,inf) always returns a nounform. However, sum(f(i)+q,i,1,inf),simpsum => inf (without asking whether q is pnz) Same thing with simplify_sum. Maxima 5.14.0 on GCL 2.6.8 Windows XP  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1945954&group_id=4933 
From: SourceForge.net <noreply@so...>  20080418 16:45:28

Bugs item #1940411, was opened at 20080411 15:03 Message generated for change (Comment added) made by rtoy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1940411&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: problem with %pi in sin() Initial Comment: f(x):=sin(4*%pi*x) y:f(x) then, drawing the graph, gets a corrupted sin wave. This problem does not occur if using 2 or 3 intead of 4 in the sin argument, and also it does not occur if typing 3.14 instead of using the %pi constant. Tested using version 0.7.4 of Maxima under Win.  >Comment By: Raymond Toy (rtoy) Date: 20080418 12:45 Message: Logged In: YES user_id=28849 Originator: NO I believe that nticks is too small. With or without adaptive plotting, nticks indicates how many samples to take. Before adaptive plotting, I think the default nticks was 100. If the graph looked weird, everyone just bumped up nticks. Adaptive plotting makes it a little easier to get nice looking plots, but if the choice of the xrange and nticks is such that the nticks samples all look pretty much the same, adaptive plotting isn't going to help. You fundamentally have to sample enough. Then adaptive plotting just helps out by automatically sampling more in places the appear to need it. I would be interested in any other idiosyncrasies you see with adaptive plotting.  Comment By: Nobody/Anonymous (nobody) Date: 20080416 01:02 Message: Logged In: NO > look for "ticks" and increase it to say 500 or more. Well, I don't think it's correct to say the value of nticks is too small. The problem is that the adaptive plotting algorithm in plot2d is easily fooled into thinking that a function is constant. You can get better results by making nticks a prime number, say 7 or 11 (the default is 10). e.g. plot2d (sin(4*%pi*x), [x, 0, 10]); => spurious flat parts plot2d (sin(4*%pi*x), [x, 0, 10], [nticks, 11]); => looks right To resolve this we probably need to rethink the adaptive plotting stuff. If I'm not mistaken it has other idiosyncrasies. As a stopgap measure maybe we can change the default value of nticks to 11. Robert Dodier (not logged in)  Comment By: Barton Willis (willisbl) Date: 20080412 01:49 Message: Logged In: YES user_id=895922 Originator: NO I'm guessing that you used wxMaxima 0.74 and used the ploting > plot2d menu item. The default for the number of ticks was too small in that version. In the menu box, look for "ticks" and increase it to say 500 or more. I think there is a wxMaxima 0.74a that has a larger value for the default for ticks. Maybe you can look for that. wxMaxima 0.74sa might be part of Maxima 5.14.0 now  I think some Maxima versions 5.14.0 have wxMaxima 0.74 and others 0.74a.  Comment By: Raymond Toy (rtoy) Date: 20080411 15:49 Message: Logged In: YES user_id=28849 Originator: NO Show exactly what you did. In what way is the sine wave corrupted? What does build_info() say? Are you really using Maxima 0.7.4? Is that the wxmaxima version? I don't recall any 0.7.4 version of Maxima.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1940411&group_id=4933 
From: SourceForge.net <noreply@so...>  20080418 16:28:26

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: Closed >Resolution: Fixed 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: 20080418 12:28 Message: Logged In: YES user_id=28849 Originator: NO New tests were added, which pass on clisp, cmucl, and gcl. Closing this bug as fixed.  Comment By: Raymond Toy (rtoy) Date: 20080417 22:44 Message: Logged In: YES user_id=28849 Originator: NO Found it. In a few places, the argument was an integer which was not converted to a double for the computations. This resulted in the answers only having singlefloat accuracy. And the use of truncate should have been changed to floor because the second value of truncate of a negative number is negative. We wanted a positive value, which is what floor gives. In gcl, a singlefloat type is a double precision number. (A shortfloat in gcl is a single precision number.) The wronskian test passes now.  Comment By: Raymond Toy (rtoy) Date: 20080417 22:04 Message: Logged In: YES user_id=28849 Originator: NO Ok. Something is wrong. Here are some samples with CVS sources and cmucl on linux and sparc: besselexpand:true; bessel_i(1/2,5) > sqrt(2)*%i*cosh(5)/sqrt(5)/sqrt(%pi) > 26.47995176430595*%i bessel_i(0.5,5.0) > 26.47995216244259*%i5.787377599375532e7 But, curiously, gcl gives 26.47995174630617*%i+1.77635683940025e15. Need to investigate why the difference...  Comment By: Crategus (crategus) Date: 20080417 16:14 Message: Logged In: YES user_id=2039760 Originator: YES First my last build info: Maxima version: 5.14.0cvs Maxima build date: 5:26 4/18/2008 host type: @host@ lispimplementationtype: GNU Common Lisp (GCL) lispimplementationversion: GCL 2.6.8 I have build Maxima from the new CVS files today. I run all tests and had no problems. For the tests W_II and W_IK I had adjusted eps to 1e10. With this value for eps all tests pass in the range of 5.0 to +5.0 for the argument. On my system I get the following results for the tests with real arg (%i23) abs(w_ii(0.50,5.00)(2.0*sin(0.5*%pi)/((5.0)*%pi))),numer; (%o23) 9.4075686847027995E14 (%i24) abs(w_ik(0.50,5.00)(1/(5.0))),numer; (%o24) 4.7815106425210348E13 And the following results with complex argument: (%i28) abs(w_ii(0.50,5.00*%i)(2.0*sin(0.5*%pi)/((5.0*%i)*%pi))),numer; (%o28) 1.0825261750342018E15 (%i29) abs(w_ik(0.50,5.00*%i)(1/(5.0*%i))),numer; (%o29) 1.6378141611741369E15 So I get the values for the Wronskians with much higher accuracy. Crategus  Comment By: Raymond Toy (rtoy) Date: 20080416 09:39 Message: Logged In: YES user_id=28849 Originator: NO What changes should be made to the documentation? I've already removed the part about besselarray. Also, I've run the test_bessel_wronskian tests. These need to be modified to fit in with how regression tests are done. However, I get the following messages: W_II: MAX EPS 7.44e5 for order = 0.50 and arg = 5.00 W_IK: MAX EPS 1.17e4 for order = 0.50 and arg = 5.00 Are these expected?  Comment By: Raymond Toy (rtoy) Date: 20080415 12:43 Message: Logged In: YES user_id=28849 Originator: NO Thank you for the fixes! I'll fix the comment in German and I'll update the documentation too. I'll add your new tests as well. Once these are done, I'll close this bug report as fixed. If you find more issues, please open a new bug report. Thanks!  Comment By: Raymond Toy (rtoy) Date: 20080415 12:42 Message: Logged In: YES user_id=28849 Originator: NO Thank you for the fixes! I'll fix the comment in German and I'll update the documentation too. I'll add your new tests as well. Once these are done, I'll close this bug report as fixed. If you find more issues, please open a new bug report. Thanks!  Comment By: Raymond Toy (rtoy) Date: 20080415 12:42 Message: Logged In: YES user_id=28849 Originator: NO Thank you for the fixes! I'll fix the comment in German and I'll update the documentation too. I'll add your new tests as well. Once these are done, I'll close this bug report as fixed. If you find more issues, please open a new bug report. Thanks!  Comment By: Crategus (crategus) Date: 20080412 17:15 Message: Logged In: YES user_id=2039760 Originator: YES Thank you very much for your work and your interest in the changes of the code. I have seen that you have deleted the use of the global $besselarray too. I have done further numerical calculations to test the code. I think a good test to show that the different parts of the code work well is to calculate the Wronskians which are defined in A&S. I have attached a file which does the calculations in test mode. (Excuse my programing style, but I have no experience programing in Maxima. Excuse my Englisch too.) As a side effect of the extension of the Bessel functions it is now possible to get nice plots to show the symmetry of the Bessel functions. A hint: You can kill the comment in German I had added at line 465. The question asks for the sign. The sign is correct! A second hint: There a still some parts of the code which don't use the symmetries of the Bessel functions completly. I will work further on this subject. At last: The documentation has to be updated too. I would like to do this work, but my English is not good enough. Crategus File Added: test_bessel_wronskian.mac  Comment By: Raymond Toy (rtoy) Date: 20080411 10:17 Message: Logged In: YES user_id=28849 Originator: NO Changes checked in to bessel.lisp, rev 1.50.  Comment By: Raymond Toy (rtoy) Date: 20080410 12:57 Message: Logged In: YES user_id=28849 Originator: NO I have now integrated your changes into bessel.lisp. The testsuite passes and your bessel tests pass too. I changed test_bessel(a,b,d) to mean abs(ab)<10^(d), which I hope is close enough. (Perhaps the real and imaginary parts should be tested separately?) I'll check in these changes after some code clean up.  Comment By: Crategus (crategus) Date: 20080401 17: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 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 
From: SourceForge.net <noreply@so...>  20080418 02:44:35

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: 20080417 22:44 Message: Logged In: YES user_id=28849 Originator: NO Found it. In a few places, the argument was an integer which was not converted to a double for the computations. This resulted in the answers only having singlefloat accuracy. And the use of truncate should have been changed to floor because the second value of truncate of a negative number is negative. We wanted a positive value, which is what floor gives. In gcl, a singlefloat type is a double precision number. (A shortfloat in gcl is a single precision number.) The wronskian test passes now.  Comment By: Raymond Toy (rtoy) Date: 20080417 22:04 Message: Logged In: YES user_id=28849 Originator: NO Ok. Something is wrong. Here are some samples with CVS sources and cmucl on linux and sparc: besselexpand:true; bessel_i(1/2,5) > sqrt(2)*%i*cosh(5)/sqrt(5)/sqrt(%pi) > 26.47995176430595*%i bessel_i(0.5,5.0) > 26.47995216244259*%i5.787377599375532e7 But, curiously, gcl gives 26.47995174630617*%i+1.77635683940025e15. Need to investigate why the difference...  Comment By: Crategus (crategus) Date: 20080417 16:14 Message: Logged In: YES user_id=2039760 Originator: YES First my last build info: Maxima version: 5.14.0cvs Maxima build date: 5:26 4/18/2008 host type: @host@ lispimplementationtype: GNU Common Lisp (GCL) lispimplementationversion: GCL 2.6.8 I have build Maxima from the new CVS files today. I run all tests and had no problems. For the tests W_II and W_IK I had adjusted eps to 1e10. With this value for eps all tests pass in the range of 5.0 to +5.0 for the argument. On my system I get the following results for the tests with real arg (%i23) abs(w_ii(0.50,5.00)(2.0*sin(0.5*%pi)/((5.0)*%pi))),numer; (%o23) 9.4075686847027995E14 (%i24) abs(w_ik(0.50,5.00)(1/(5.0))),numer; (%o24) 4.7815106425210348E13 And the following results with complex argument: (%i28) abs(w_ii(0.50,5.00*%i)(2.0*sin(0.5*%pi)/((5.0*%i)*%pi))),numer; (%o28) 1.0825261750342018E15 (%i29) abs(w_ik(0.50,5.00*%i)(1/(5.0*%i))),numer; (%o29) 1.6378141611741369E15 So I get the values for the Wronskians with much higher accuracy. Crategus  Comment By: Raymond Toy (rtoy) Date: 20080416 09:39 Message: Logged In: YES user_id=28849 Originator: NO What changes should be made to the documentation? I've already removed the part about besselarray. Also, I've run the test_bessel_wronskian tests. These need to be modified to fit in with how regression tests are done. However, I get the following messages: W_II: MAX EPS 7.44e5 for order = 0.50 and arg = 5.00 W_IK: MAX EPS 1.17e4 for order = 0.50 and arg = 5.00 Are these expected?  Comment By: Raymond Toy (rtoy) Date: 20080415 12:43 Message: Logged In: YES user_id=28849 Originator: NO Thank you for the fixes! I'll fix the comment in German and I'll update the documentation too. I'll add your new tests as well. Once these are done, I'll close this bug report as fixed. If you find more issues, please open a new bug report. Thanks!  Comment By: Raymond Toy (rtoy) Date: 20080415 12:42 Message: Logged In: YES user_id=28849 Originator: NO Thank you for the fixes! I'll fix the comment in German and I'll update the documentation too. I'll add your new tests as well. Once these are done, I'll close this bug report as fixed. If you find more issues, please open a new bug report. Thanks!  Comment By: Raymond Toy (rtoy) Date: 20080415 12:42 Message: Logged In: YES user_id=28849 Originator: NO Thank you for the fixes! I'll fix the comment in German and I'll update the documentation too. I'll add your new tests as well. Once these are done, I'll close this bug report as fixed. If you find more issues, please open a new bug report. Thanks!  Comment By: Crategus (crategus) Date: 20080412 17:15 Message: Logged In: YES user_id=2039760 Originator: YES Thank you very much for your work and your interest in the changes of the code. I have seen that you have deleted the use of the global $besselarray too. I have done further numerical calculations to test the code. I think a good test to show that the different parts of the code work well is to calculate the Wronskians which are defined in A&S. I have attached a file which does the calculations in test mode. (Excuse my programing style, but I have no experience programing in Maxima. Excuse my Englisch too.) As a side effect of the extension of the Bessel functions it is now possible to get nice plots to show the symmetry of the Bessel functions. A hint: You can kill the comment in German I had added at line 465. The question asks for the sign. The sign is correct! A second hint: There a still some parts of the code which don't use the symmetries of the Bessel functions completly. I will work further on this subject. At last: The documentation has to be updated too. I would like to do this work, but my English is not good enough. Crategus File Added: test_bessel_wronskian.mac  Comment By: Raymond Toy (rtoy) Date: 20080411 10:17 Message: Logged In: YES user_id=28849 Originator: NO Changes checked in to bessel.lisp, rev 1.50.  Comment By: Raymond Toy (rtoy) Date: 20080410 12:57 Message: Logged In: YES user_id=28849 Originator: NO I have now integrated your changes into bessel.lisp. The testsuite passes and your bessel tests pass too. I changed test_bessel(a,b,d) to mean abs(ab)<10^(d), which I hope is close enough. (Perhaps the real and imaginary parts should be tested separately?) I'll check in these changes after some code clean up.  Comment By: Crategus (crategus) Date: 20080401 17: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 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 
From: SourceForge.net <noreply@so...>  20080418 02:04:08

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: 20080417 22:04 Message: Logged In: YES user_id=28849 Originator: NO Ok. Something is wrong. Here are some samples with CVS sources and cmucl on linux and sparc: besselexpand:true; bessel_i(1/2,5) > sqrt(2)*%i*cosh(5)/sqrt(5)/sqrt(%pi) > 26.47995176430595*%i bessel_i(0.5,5.0) > 26.47995216244259*%i5.787377599375532e7 But, curiously, gcl gives 26.47995174630617*%i+1.77635683940025e15. Need to investigate why the difference...  Comment By: Crategus (crategus) Date: 20080417 16:14 Message: Logged In: YES user_id=2039760 Originator: YES First my last build info: Maxima version: 5.14.0cvs Maxima build date: 5:26 4/18/2008 host type: @host@ lispimplementationtype: GNU Common Lisp (GCL) lispimplementationversion: GCL 2.6.8 I have build Maxima from the new CVS files today. I run all tests and had no problems. For the tests W_II and W_IK I had adjusted eps to 1e10. With this value for eps all tests pass in the range of 5.0 to +5.0 for the argument. On my system I get the following results for the tests with real arg (%i23) abs(w_ii(0.50,5.00)(2.0*sin(0.5*%pi)/((5.0)*%pi))),numer; (%o23) 9.4075686847027995E14 (%i24) abs(w_ik(0.50,5.00)(1/(5.0))),numer; (%o24) 4.7815106425210348E13 And the following results with complex argument: (%i28) abs(w_ii(0.50,5.00*%i)(2.0*sin(0.5*%pi)/((5.0*%i)*%pi))),numer; (%o28) 1.0825261750342018E15 (%i29) abs(w_ik(0.50,5.00*%i)(1/(5.0*%i))),numer; (%o29) 1.6378141611741369E15 So I get the values for the Wronskians with much higher accuracy. Crategus  Comment By: Raymond Toy (rtoy) Date: 20080416 09:39 Message: Logged In: YES user_id=28849 Originator: NO What changes should be made to the documentation? I've already removed the part about besselarray. Also, I've run the test_bessel_wronskian tests. These need to be modified to fit in with how regression tests are done. However, I get the following messages: W_II: MAX EPS 7.44e5 for order = 0.50 and arg = 5.00 W_IK: MAX EPS 1.17e4 for order = 0.50 and arg = 5.00 Are these expected?  Comment By: Raymond Toy (rtoy) Date: 20080415 12:43 Message: Logged In: YES user_id=28849 Originator: NO Thank you for the fixes! I'll fix the comment in German and I'll update the documentation too. I'll add your new tests as well. Once these are done, I'll close this bug report as fixed. If you find more issues, please open a new bug report. Thanks!  Comment By: Raymond Toy (rtoy) Date: 20080415 12:42 Message: Logged In: YES user_id=28849 Originator: NO Thank you for the fixes! I'll fix the comment in German and I'll update the documentation too. I'll add your new tests as well. Once these are done, I'll close this bug report as fixed. If you find more issues, please open a new bug report. Thanks!  Comment By: Raymond Toy (rtoy) Date: 20080415 12:42 Message: Logged In: YES user_id=28849 Originator: NO Thank you for the fixes! I'll fix the comment in German and I'll update the documentation too. I'll add your new tests as well. Once these are done, I'll close this bug report as fixed. If you find more issues, please open a new bug report. Thanks!  Comment By: Crategus (crategus) Date: 20080412 17:15 Message: Logged In: YES user_id=2039760 Originator: YES Thank you very much for your work and your interest in the changes of the code. I have seen that you have deleted the use of the global $besselarray too. I have done further numerical calculations to test the code. I think a good test to show that the different parts of the code work well is to calculate the Wronskians which are defined in A&S. I have attached a file which does the calculations in test mode. (Excuse my programing style, but I have no experience programing in Maxima. Excuse my Englisch too.) As a side effect of the extension of the Bessel functions it is now possible to get nice plots to show the symmetry of the Bessel functions. A hint: You can kill the comment in German I had added at line 465. The question asks for the sign. The sign is correct! A second hint: There a still some parts of the code which don't use the symmetries of the Bessel functions completly. I will work further on this subject. At last: The documentation has to be updated too. I would like to do this work, but my English is not good enough. Crategus File Added: test_bessel_wronskian.mac  Comment By: Raymond Toy (rtoy) Date: 20080411 10:17 Message: Logged In: YES user_id=28849 Originator: NO Changes checked in to bessel.lisp, rev 1.50.  Comment By: Raymond Toy (rtoy) Date: 20080410 12:57 Message: Logged In: YES user_id=28849 Originator: NO I have now integrated your changes into bessel.lisp. The testsuite passes and your bessel tests pass too. I changed test_bessel(a,b,d) to mean abs(ab)<10^(d), which I hope is close enough. (Perhaps the real and imaginary parts should be tested separately?) I'll check in these changes after some code clean up.  Comment By: Crategus (crategus) Date: 20080401 17: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 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 
From: SourceForge.net <noreply@so...>  20080417 20:14:16

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: 20080417 22:14 Message: Logged In: YES user_id=2039760 Originator: YES First my last build info: Maxima version: 5.14.0cvs Maxima build date: 5:26 4/18/2008 host type: @host@ lispimplementationtype: GNU Common Lisp (GCL) lispimplementationversion: GCL 2.6.8 I have build Maxima from the new CVS files today. I run all tests and had no problems. For the tests W_II and W_IK I had adjusted eps to 1e10. With this value for eps all tests pass in the range of 5.0 to +5.0 for the argument. On my system I get the following results for the tests with real arg (%i23) abs(w_ii(0.50,5.00)(2.0*sin(0.5*%pi)/((5.0)*%pi))),numer; (%o23) 9.4075686847027995E14 (%i24) abs(w_ik(0.50,5.00)(1/(5.0))),numer; (%o24) 4.7815106425210348E13 And the following results with complex argument: (%i28) abs(w_ii(0.50,5.00*%i)(2.0*sin(0.5*%pi)/((5.0*%i)*%pi))),numer; (%o28) 1.0825261750342018E15 (%i29) abs(w_ik(0.50,5.00*%i)(1/(5.0*%i))),numer; (%o29) 1.6378141611741369E15 So I get the values for the Wronskians with much higher accuracy. Crategus  Comment By: Raymond Toy (rtoy) Date: 20080416 15:39 Message: Logged In: YES user_id=28849 Originator: NO What changes should be made to the documentation? I've already removed the part about besselarray. Also, I've run the test_bessel_wronskian tests. These need to be modified to fit in with how regression tests are done. However, I get the following messages: W_II: MAX EPS 7.44e5 for order = 0.50 and arg = 5.00 W_IK: MAX EPS 1.17e4 for order = 0.50 and arg = 5.00 Are these expected?  Comment By: Raymond Toy (rtoy) Date: 20080415 18:43 Message: Logged In: YES user_id=28849 Originator: NO Thank you for the fixes! I'll fix the comment in German and I'll update the documentation too. I'll add your new tests as well. Once these are done, I'll close this bug report as fixed. If you find more issues, please open a new bug report. Thanks!  Comment By: Raymond Toy (rtoy) Date: 20080415 18:42 Message: Logged In: YES user_id=28849 Originator: NO Thank you for the fixes! I'll fix the comment in German and I'll update the documentation too. I'll add your new tests as well. Once these are done, I'll close this bug report as fixed. If you find more issues, please open a new bug report. Thanks!  Comment By: Raymond Toy (rtoy) Date: 20080415 18:42 Message: Logged In: YES user_id=28849 Originator: NO Thank you for the fixes! I'll fix the comment in German and I'll update the documentation too. I'll add your new tests as well. Once these are done, I'll close this bug report as fixed. If you find more issues, please open a new bug report. Thanks!  Comment By: Crategus (crategus) Date: 20080412 23:15 Message: Logged In: YES user_id=2039760 Originator: YES Thank you very much for your work and your interest in the changes of the code. I have seen that you have deleted the use of the global $besselarray too. I have done further numerical calculations to test the code. I think a good test to show that the different parts of the code work well is to calculate the Wronskians which are defined in A&S. I have attached a file which does the calculations in test mode. (Excuse my programing style, but I have no experience programing in Maxima. Excuse my Englisch too.) As a side effect of the extension of the Bessel functions it is now possible to get nice plots to show the symmetry of the Bessel functions. A hint: You can kill the comment in German I had added at line 465. The question asks for the sign. The sign is correct! A second hint: There a still some parts of the code which don't use the symmetries of the Bessel functions completly. I will work further on this subject. At last: The documentation has to be updated too. I would like to do this work, but my English is not good enough. Crategus File Added: test_bessel_wronskian.mac  Comment By: Raymond Toy (rtoy) Date: 20080411 16:17 Message: Logged In: YES user_id=28849 Originator: NO Changes checked in to bessel.lisp, rev 1.50.  Comment By: Raymond Toy (rtoy) Date: 20080410 18:57 Message: Logged In: YES user_id=28849 Originator: NO I have now integrated your changes into bessel.lisp. The testsuite passes and your bessel tests pass too. I changed test_bessel(a,b,d) to mean abs(ab)<10^(d), which I hope is close enough. (Perhaps the real and imaginary parts should be tested separately?) I'll check in these changes after some code clean up.  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...>  20080416 14:07:51

Bugs item #1944012, was opened at 20080416 07:07 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=1944012&group_id=4933 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Lisp Core  Solving equations Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: solve() fails depending on equation order Initial Comment: Maxima version: 5.14.0 OS: Windows XP SP2 Name: Bob Walton (note: setting up a SourceForge account apparently isn't working, so I couldn't log in) Email: http://bwalton.com/cgibin/emailbob.pl Problem: q1:2*x3; q2:96*z^2+48*z+32*y^2+9; q3:48*z^216*z17; solve([q1,q2,q3],[x,y,z]); generates: [] which is incorrect. Whereas: solve([q1,q3,q2],[x,y,z]); generates the correct answer: [[ x = 3/2, y = sqrt(674*sqrt(55))/(4*sqrt(6)), z = (sqrt(55)+2)/12 ], [ x = 3/2, y = sqrt(674*sqrt(55))/(4*sqrt(6)), z = (sqrt(55)+2)/12 ], [ x = 3/2, y = sqrt(4*sqrt(55)+67)/(4*sqrt(6)), z = (sqrt(55)2)/12 ],[ x = 3/2, y = sqrt(4*sqrt(55)+67)/(4*sqrt(6)), z = (sqrt(55)2)/12 ]] This problem arose when using solve() on the results of poly_grobner  generally solve() works directly on the output of poly_grobner, but not in this particular case.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1944012&group_id=4933 
From: SourceForge.net <noreply@so...>  20080416 13:39:54

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: 20080416 09:39 Message: Logged In: YES user_id=28849 Originator: NO What changes should be made to the documentation? I've already removed the part about besselarray. Also, I've run the test_bessel_wronskian tests. These need to be modified to fit in with how regression tests are done. However, I get the following messages: W_II: MAX EPS 7.44e5 for order = 0.50 and arg = 5.00 W_IK: MAX EPS 1.17e4 for order = 0.50 and arg = 5.00 Are these expected?  Comment By: Raymond Toy (rtoy) Date: 20080415 12:43 Message: Logged In: YES user_id=28849 Originator: NO Thank you for the fixes! I'll fix the comment in German and I'll update the documentation too. I'll add your new tests as well. Once these are done, I'll close this bug report as fixed. If you find more issues, please open a new bug report. Thanks!  Comment By: Raymond Toy (rtoy) Date: 20080415 12:42 Message: Logged In: YES user_id=28849 Originator: NO Thank you for the fixes! I'll fix the comment in German and I'll update the documentation too. I'll add your new tests as well. Once these are done, I'll close this bug report as fixed. If you find more issues, please open a new bug report. Thanks!  Comment By: Raymond Toy (rtoy) Date: 20080415 12:42 Message: Logged In: YES user_id=28849 Originator: NO Thank you for the fixes! I'll fix the comment in German and I'll update the documentation too. I'll add your new tests as well. Once these are done, I'll close this bug report as fixed. If you find more issues, please open a new bug report. Thanks!  Comment By: Crategus (crategus) Date: 20080412 17:15 Message: Logged In: YES user_id=2039760 Originator: YES Thank you very much for your work and your interest in the changes of the code. I have seen that you have deleted the use of the global $besselarray too. I have done further numerical calculations to test the code. I think a good test to show that the different parts of the code work well is to calculate the Wronskians which are defined in A&S. I have attached a file which does the calculations in test mode. (Excuse my programing style, but I have no experience programing in Maxima. Excuse my Englisch too.) As a side effect of the extension of the Bessel functions it is now possible to get nice plots to show the symmetry of the Bessel functions. A hint: You can kill the comment in German I had added at line 465. The question asks for the sign. The sign is correct! A second hint: There a still some parts of the code which don't use the symmetries of the Bessel functions completly. I will work further on this subject. At last: The documentation has to be updated too. I would like to do this work, but my English is not good enough. Crategus File Added: test_bessel_wronskian.mac  Comment By: Raymond Toy (rtoy) Date: 20080411 10:17 Message: Logged In: YES user_id=28849 Originator: NO Changes checked in to bessel.lisp, rev 1.50.  Comment By: Raymond Toy (rtoy) Date: 20080410 12:57 Message: Logged In: YES user_id=28849 Originator: NO I have now integrated your changes into bessel.lisp. The testsuite passes and your bessel tests pass too. I changed test_bessel(a,b,d) to mean abs(ab)<10^(d), which I hope is close enough. (Perhaps the real and imaginary parts should be tested separately?) I'll check in these changes after some code clean up.  Comment By: Crategus (crategus) Date: 20080401 17: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 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 
From: SourceForge.net <noreply@so...>  20080416 09:12:48

Bugs item #1943756, was opened at 20080416 18:12 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=1943756&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: Satoshi Adachi (satoshi_adachi) Assigned to: Nobody/Anonymous (nobody) Summary: ezgcd() never returns. Initial Comment: Dear Developers of Maxima, I met a set of two polynomials whose gcd polynomial cannot be calculated by ezgcd(). ezgcd() seems to be put into an infinite loop. If gcd() is used instead of ezgcd(), the gcd polynomial is calculated normally. A Maxima program for the demonstration is as follows  /* * ezgcd_does_not_return.maxima: * * S.Adachi 2008/04/16 */ display2d:false; F:n^2+(2*d+c+b+2)*n+d^2+(cb2)*d+c+b+1; G:n^2+(2*dcb2)*nd^2+(c+b+2)*d+(b1)*cb1; gcd(F,G); /* OK */ ezgcd(F,G); /* Does not return! */ /* END */  The result of execution is as follows  [Macintosh:~/work/289:1] adachi% maxima b ezgcd_does_not_return.maxima 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(ezgcd_does_not_return.maxima) batching #p/Volumes/HFS+2/home/adachi/work/289/ezgcd_does_not_return.maxima (%i2) display2d : false (%o2) false (%i3) F:1+b+c+(2bc)*d+d^2+(2+b+c2*d)*n+n^2 (%o3) n^2+(2*d+c+b+2)*n+d^2+(cb2)*d+c+b+1 (%i4) G:1b+(1b)*c+(2+b+c)*dd^2+(2bc+2*d)*nn^2 (%o4) n^2+(2*dcb2)*nd^2+(c+b+2)*d+(b1)*cb1 (%i5) gcd(F,G) (%o5) 1 (%i6) ezgcd(F,G) ^CMaxima encountered a Lisp error: Console interrupt. Automatically continuing. To reenable the Lisp debugger set *debuggerhook* to nil. (%o7) "ezgcd_does_not_return.maxima"  Here, I had to stop the program by console interrupt. Please fix this bug of ezgcd(). Sincrely yours, Satoshi Adachi  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1943756&group_id=4933 
From: SourceForge.net <noreply@so...>  20080416 05:08:20

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: 20080415 22:08 Message: Logged In: NO I'm pretty sure the observed behavior is due to implementationdependent interpretations of FRESHLINE. I see the observed behavior with cvs Maxima + GCL and SBCL, but not Clisp. I don't know which has the correct implementation of FRESHLINE, or if they're all equally correct. I don't know how much we can do about this, or want to do. Robert Dodier (not logged in)  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 