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}
(49) 
_{May}

_{Jun}

_{Jul}

_{Aug}

_{Sep}

_{Oct}

_{Nov}

_{Dec}

S  M  T  W  T  F  S 







1

2
(4) 
3

4
(1) 
5
(1) 
6
(2) 
7
(4) 
8
(9) 
9
(4) 
10
(1) 
11
(1) 
12
(6) 
13
(5) 
14
(1) 
15

16

17
(8) 
18

19
(1) 
20
(1) 
21

22
(2) 
23
(1) 
24
(1) 
25
(3) 
26
(1) 
27
(4) 
28
(4) 
29
(6) 
30
(3) 
31
(2) 





From: SourceForge.net <noreply@so...>  20080328 17:37:11

Bugs item #1928142, was opened at 20080328 18:37 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1928142&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: Harald Geyer (hgeyer) Assigned to: Nobody/Anonymous (nobody) Summary: keepfloat breaks ratsubst() in some cases Initial Comment: ratsubst returns incorrect results when keepfloat==true and the substitution causes the expression to contain both floats and rationals at the same time. See the following example session for things that don't work as well as for some things that do work. I can reproduce the problem from at least 5.11.0 up to current cvs with clisp and gcl. Maxima 5.14.0cvs http://maxima.sourceforge.net Using Lisp CLISP 2.41 (20061013) 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(ratsubstbug.mac) batching /home/rld/ratsubstbug.mac (%i2) keepfloat : true (%i3) display2d : false (%i4) cos(%pi/3) (%o4) 1/2 (%i5) subst(%pi/3,th,1.2*cos(th)) (%o5) 0.6 (%i6) ratsubst(%pi/3,th,1.2*cos(th)) (%o6) 1.2 (%i7) cos(%pi) (%o7) 1 (%i8) subst(%pi,th,1.2*cos(th)) (%o8) 1.2 (%i9) ratsubst(%pi,th,1.2*cos(th)) (%o9) 1.2 (%i10) sqrt(1/4) (%o10) 1/2 (%i11) subst(4,th,1.2*sqrt(1/th)) (%o11) 0.6 (%i12) ratsubst(4,th,1.2*sqrt(1/th)) Maxima encountered a Lisp error: COMMONLISP:GCD: 1.2 is not an integer Automatically continuing. To reenable the Lisp debugger set *debuggerhook* to nil. (%i13) subst(9,th,1.2*sqrt(1/th)) (%o13) 0.4 (%i14) ratsubst(9,th,1.2*sqrt(1/th)) Maxima encountered a Lisp error: COMMONLISP:GCD: 1.2 is not an integer Automatically continuing. To reenable the Lisp debugger set *debuggerhook* to nil. (%i15) ratsubst(9,th,1.2*sqrt(th)) (%o15) 3.6 (%i16) ratsubst(4,th,1.2/sqrt(th)) Maxima encountered a Lisp error: COMMONLISP:GCD: 1.2 is not an integer Automatically continuing. To reenable the Lisp debugger set *debuggerhook* to nil. (%i17) log(%e^(1/2)) (%o17) 1/2 (%i18) subst(%e^(1/2),th,1.2*log(th)) (%o18) 0.6 (%i19) ratsubst(%e^(1/2),th,1.2*log(th)) (%o19) 1.2 (%i20) ratsubst(%e^(1/3), th, 1.2*log(th)); (%o20) 1.2 (%i21) subst(%e^2,th,1.2*log(th)) (%o21) 2.4 (%i22) ratsubst(%e^2,th,1.2*log(th)) (%o22) 2.4  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1928142&group_id=4933 
From: SourceForge.net <noreply@so...>  20080328 16:43:07

Bugs item #721575, was opened at 20030414 23:45 Message generated for change (Comment added) made by rtoy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=721575&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: 8 Private: No Submitted By: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: 2/sqrt(2) doesn\'t simplify Initial Comment: 2/sqrt(2) doesn't simplify. Similarly for 2/2^(2/3). On the other hand, x/sqrt(x) => sqrt(x). And of course sqrt(2) simplifies to itself  it doesn't become 2/sqrt(2)!! I believe the original examples should simplify to sqrt(2) and 2^(1/3). Note that 2^(4/3) => 2*2^(1/3) (the current behavior) is probably CORRECT, in order to make things like 10^(10/3) intelligible. Or is there something I'm missing? Maxima 5.9.0 gcl 2.5.0 mingw32 Windows 2000 Athlon  >Comment By: Raymond Toy (rtoy) Date: 20080328 12:42 Message: Logged In: YES user_id=28849 Originator: NO The issue appears to be in timesin. The basic issue is that timesin isn't commutative, as dgildea shows. I have a partial fix for this which fixes this particular issue, but it causes many failures in the testsuite, mostly due to a different ordering of the answer. But some tests now cause errors to be signaled, and some are no longer simplified as before or not simplified at all. Bummer.  Comment By: Dan Gildea (dgildea) Date: 20080111 07:55 Message: Logged In: YES user_id=1797506 Originator: NO (%i6) (1/2)*sqrt(2); (%o6) sqrt(2)/2 (%i7) sqrt(2)*(1/2); (%o7) 1/sqrt(2)  Comment By: Stavros Macrakis (macrakis) Date: 20071219 09:59 Message: Logged In: YES user_id=588346 Originator: YES I have raised the priority of this bug, because it is very close to the surface (i.e. easy for just about any user to run into). See also 1853191, where algebraic gives strange results...  Comment By: Stavros Macrakis (macrakis) Date: 20031008 23:21 Message: Logged In: YES user_id=588346 More examples. Righthand side is after ratsimp/algebraic. I believe the general simplifier should be giving those forms. 1/(2*2^(2/3)) 2^(1/3)/4 1/2^(2/3) 2^(1/3)/2 1/(2*SQRT(2)) SQRT(2)/4 1/SQRT(2) SQRT(2)/2 1/(2*2^(1/3)) 2^(2/3)/4 1/2^(1/3) 2^(2/3)/2 Things get worse with nonnumeric contents. In the following, each group of expressions denotes the same thing, but none simplifies to the others. I have put *** next to those forms which are the results of ratsimp/algebraic. Note that in several cases, there is more than one equivalent ratsimp'ed form.... 1/(a*b)^(5/2) 1/(a^2*b^2*SQRT(a*b)) *** SQRT(a*b)/(a^3*b^3) *** 1/(a*b)^(3/2) 1/(a*b*SQRT(a*b)) *** SQRT(a*b)/(a^2*b^2) *** 1/(a*b)^(7/6) 1/(a^(2/3)*b^(2/3)*SQRT(a*b)) *** SQRT(a*b)/(a^(5/3)*b^(5/3)) *** (a*b)^(5/6)/(a^2*b^2) *** 1/(a*b)^(5/6) *** 1/(a^(1/3)*b^(1/3)*SQRT(a*b)) *** (a*b)^(1/6)/(a*b) *** SQRT(a*b)/(a^(4/3)*b^(4/3)) *** 1/SQRT(a*b) *** SQRT(a*b)/(a*b) *** a^(1/3)*b^(1/3)/SQRT(a*b) *** 1/(a*b)^(1/6) *** SQRT(a*b)/(a^(2/3)*b^(2/3)) *** (a*b)^(5/6)/(a*b) *** Now it is true that these expressions are in fact not all equivalent as to principal value, but I will leave that exercise for later. Many of them are, and they are not being canonicalized.  Comment By: Stavros Macrakis (macrakis) Date: 20030417 14:53 Message: Logged In: YES user_id=588346 Yes, of course there are ways within Maxima to perform this simplification. But it should be the default in the general simplifer. The logic already appears to be in the general simplifier, but there is a bug in this particular case. If the general simplifier's philosophy were to leave such things untouched, why does it simplify x/sqrt(x) and the like?  Comment By: Barton Willis (willisb) Date: 20030417 14:44 Message: Logged In: YES user_id=570592 Try ratsimp with algebraic : true (C1) z : 2/sqrt(2); (D1) 2/SQRT(2) (C2) ratsimp(z); (D2) 2/SQRT(2) (C3) ratsimp(z),algebraic; (D3) SQRT(2) (C4) z : 2/2^(2/3); (D4) 2/2^(2/3) (C5) ratsimp(z); (D5) 2/2^(2/3) (C6) ratsimp(z),algebraic; (D6) 2^(1/3) (C7)  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=721575&group_id=4933 
From: SourceForge.net <noreply@so...>  20080328 16:37:43

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: 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...>  20080328 01:51:39

Bugs item #1927346, was opened at 20080327 13:31 Message generated for change (Settings changed) made by willisbl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1927346&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: Duplicate Priority: 3 Private: No Submitted By: Barton Willis (willisbl) Assigned to: Nobody/Anonymous (nobody) Summary: sqrt(2) ./ 2 vs 1/sqrt(2) Initial Comment: It's not wrong, but it's not right either: (%i3) integrate(sin(t),t,%pi/4,3*%pi/4); (%o3) sqrt(2)/2+1/sqrt(2)  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1927346&group_id=4933 