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}
(19) 
_{Aug}

_{Sep}

_{Oct}

_{Nov}

_{Dec}

S  M  T  W  T  F  S 



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

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

17

18

19
(6) 
20
(5) 
21

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

26

27
(1) 
28

29
(2) 
30
(1) 



From: SourceForge.net <noreply@so...>  20100611 22:40:55

Bugs item #3014845, was opened at 20100611 10:10 Message generated for change (Comment added) made by rtoy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3014845&group_id=4933 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Lisp Core  Floating point Group: None >Status: Pending >Resolution: Wont Fix Priority: 5 Private: No Submitted By: Derek O'Connor (derekroconnor) Assigned to: Nobody/Anonymous (nobody) Summary: sin(1e22) is wrong Initial Comment: sin(1e22); (%o1) 0.41214336710708 The correct answer is 8.522008497671888 Please note that 10^22 is exactly representable as an IEEE double precision floating point number, whose binary representation is 10^22 = 1000011110000110011110000011001001101110101011001001 x 2^22 This incorrect result suggests that the rangereduction step, where the argument x is reduced to lie in a small interval around 0, such as [pi/2,+pi/2], has not been done properly. This means that the other trigonometric functions will be incorrect. This value 10^22 was carefully chosen by Ng to uncover faulty range reduction: http://www.derekroconnor.net/Software/NgArgReduction.pdf Maxima is not alone: R, Octave, Freemat, Euler, Python, and Lua have the same problem. Matlab used to have this problem but fixed it. I am neither a systems programmer nor a Maxima developer so I don't know what is going on in the background. I suspect that the mingw32 system may be at fault. If so, this prompts the question: do Maxima developers not check the components they are using? Maxima version: 5.21.1 Maxima build date: 8:13 4/26/2010 Host type: i686pcmingw32 Lisp implementation type: GNU Common Lisp (GCL) Lisp implementation version: GCL 2.6.8 Dell Precision 690, Intel 2xQuadCore E5345 @ 2.33GHz 16GB RAM, Windows7 64bit Professional. Derek O'Connor  >Comment By: Raymond Toy (rtoy) Date: 20100611 18:40 Message: Maxima computes sin(1e22) by defering to the Lisp implementation to evaluate it. Gcl produces the incorrect answer. Maxima with cmucl produces 0.8522008497671888, as you expect. I consider this a bug in gcl, not maxima. Marking as pending/wontfix.  Comment By: Derek O'Connor (derekroconnor) Date: 20100611 14:38 Message: CORRECTION: 8.522008497671888 should be 0.8522008497671888 Derek O'Connor  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3014845&group_id=4933 
From: SourceForge.net <noreply@so...>  20100611 18:38:47

Bugs item #3014845, was opened at 20100611 15:10 Message generated for change (Comment added) made by derekroconnor You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3014845&group_id=4933 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Lisp Core  Floating point Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Derek O'Connor (derekroconnor) Assigned to: Nobody/Anonymous (nobody) Summary: sin(1e22) is wrong Initial Comment: sin(1e22); (%o1) 0.41214336710708 The correct answer is 8.522008497671888 Please note that 10^22 is exactly representable as an IEEE double precision floating point number, whose binary representation is 10^22 = 1000011110000110011110000011001001101110101011001001 x 2^22 This incorrect result suggests that the rangereduction step, where the argument x is reduced to lie in a small interval around 0, such as [pi/2,+pi/2], has not been done properly. This means that the other trigonometric functions will be incorrect. This value 10^22 was carefully chosen by Ng to uncover faulty range reduction: http://www.derekroconnor.net/Software/NgArgReduction.pdf Maxima is not alone: R, Octave, Freemat, Euler, Python, and Lua have the same problem. Matlab used to have this problem but fixed it. I am neither a systems programmer nor a Maxima developer so I don't know what is going on in the background. I suspect that the mingw32 system may be at fault. If so, this prompts the question: do Maxima developers not check the components they are using? Maxima version: 5.21.1 Maxima build date: 8:13 4/26/2010 Host type: i686pcmingw32 Lisp implementation type: GNU Common Lisp (GCL) Lisp implementation version: GCL 2.6.8 Dell Precision 690, Intel 2xQuadCore E5345 @ 2.33GHz 16GB RAM, Windows7 64bit Professional. Derek O'Connor  >Comment By: Derek O'Connor (derekroconnor) Date: 20100611 19:38 Message: CORRECTION: 8.522008497671888 should be 0.8522008497671888 Derek O'Connor  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3014845&group_id=4933 
From: SourceForge.net <noreply@so...>  20100611 14:10:53

Bugs item #3014845, was opened at 20100611 15:10 Message generated for change (Tracker Item Submitted) made by derekroconnor You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3014845&group_id=4933 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Lisp Core  Floating point Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Derek O'Connor (derekroconnor) Assigned to: Nobody/Anonymous (nobody) Summary: sin(1e22) is wrong Initial Comment: sin(1e22); (%o1) 0.41214336710708 The correct answer is 8.522008497671888 Please note that 10^22 is exactly representable as an IEEE double precision floating point number, whose binary representation is 10^22 = 1000011110000110011110000011001001101110101011001001 x 2^22 This incorrect result suggests that the rangereduction step, where the argument x is reduced to lie in a small interval around 0, such as [pi/2,+pi/2], has not been done properly. This means that the other trigonometric functions will be incorrect. This value 10^22 was carefully chosen by Ng to uncover faulty range reduction: http://www.derekroconnor.net/Software/NgArgReduction.pdf Maxima is not alone: R, Octave, Freemat, Euler, Python, and Lua have the same problem. Matlab used to have this problem but fixed it. I am neither a systems programmer nor a Maxima developer so I don't know what is going on in the background. I suspect that the mingw32 system may be at fault. If so, this prompts the question: do Maxima developers not check the components they are using? Maxima version: 5.21.1 Maxima build date: 8:13 4/26/2010 Host type: i686pcmingw32 Lisp implementation type: GNU Common Lisp (GCL) Lisp implementation version: GCL 2.6.8 Dell Precision 690, Intel 2xQuadCore E5345 @ 2.33GHz 16GB RAM, Windows7 64bit Professional. Derek O'Connor  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3014845&group_id=4933 
From: SourceForge.net <noreply@so...>  20100611 02:20:11

Bugs item #873301, was opened at 20040108 20:39 Message generated for change (Comment added) made by sfrobot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=873301&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: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: Gradef doesn't understand diff (workaround) Initial Comment: Suppose that f(x)=exp(g(x)). Then f'(x)=f(x)*g'(x). So how do we define this using gradef? Let's try the obvious solution: gradef( f(x), f(x) * diff(g(x),x) ) Now diff(f(x^2),x) => f(x1)*'DIFF(g(x1),x1,1) Oops! That isn't right! It is substituting x1 for x in the *second* argument of diff as well as the first! So we have to work around this doing something like gradef( f(x), f(x) * g1(x) ) gradef( g(x), g1(x) )  >Comment By: SourceForge Robot (sfrobot) Date: 20100611 02:20 Message: This Tracker item was closed automatically by the system. It was previously set to a Pending status, and the original submitter did not respond within 14 days (the time period specified by the administrator of this Tracker).  Comment By: Dieter Kaiser (crategus) Date: 20100527 20:55 Message: As explained in the last posting I would like to suggest to close this bug report as "works for me". Setting the status to pending. Dieter Kaiser  Comment By: Dieter Kaiser (crategus) Date: 20100511 20:34 Message: First, again the example of this bug report: (%i6) gradef(f(x), f(x)*diff(g(x),x)); We get a wrong result with the above definition: (%i7) diff(f(2*sin(x)),x); (%o7) 2*cos(x)*f(2*sin(x))*'diff(g(2*sin(x)),2*sin(x),1) But Maxima can do it correctly. We have to define the problem the following way: (%i8) gradef(f(x), f(x)*at(diff(g(u),u),u=x))$ (%i9) diff(f(2*sin(x)),x); (%o9) 2*('at('diff(g(u),u,1),u = 2*sin(x)))*cos(x)*f(2*sin(x)) The example of the bug report now gives a correct result too: (%i10) diff(f(x^2),x); (%o10) 2*('at('diff(g(u),u,1),u = x^2))*x*f(x^2) >From this we might conclude, that we have not a bug, but we have to formulate the problem more precisely. By the way: The derivatives of the nine inverse Jacobi functions wrt the parameter m are defined as a noun form. Furthermore, the derivatives of the Bessel Y and K functions wrt the order have a noun form of a derivative on the property list. All this derivatives do not work too, but have the same error as reported in this bug report, e.g. (%i11) diff(inverse_jacobi_ns(x,2*m),m); (%o11) 2*'diff(inverse_jacobi_ns(x,2*m),2*m,1) The error for the inverse Jacobi functions is easy to correct. We simply put NIL for the derivative wrt the parameter m on the property list. We had some time ago an extension to sdiff to return a noun form for this case. With this change we get a correct noun form: (%i13) diff(inverse_jacobi_ns(x,2*m),m); (%o13) 'diff(inverse_jacobi_ns(x,2*m),m,1) This is an example of a wrong derivative of a Bessel K function: (%i15) diff(bessel_k(sin(n),x),n); (%o15) cos(n)*(%pi*csc(%pi*sin(n)) *('diff(bessel_i(sin(n),x),sin(n),1) 'diff(bessel_i(sin(n),x),sin(n),1)) /2 %pi*bessel_k(sin(n),x)*cot(%pi*sin(n))) To get this derivative in general correct we can put an expression with AT on the property list. Dieter Kaiser  Comment By: Robert Dodier (robert_dodier) Date: 20060722 15:48 Message: Logged In: YES user_id=501686 In 5.9.3cvs, I'm seeing a different wrong answer. gradef( f(x), f(x) * diff(g(x),x) ); diff(f(x^2),x) ; => 2*x*f(x^2)*'?%diff(g(x^2),x^2,1) Should be 2*x*f(x^2)*at('?%diff(g(u),u,1),[u=x^2]) or something like that (i.e., distinguish point of evaluation x^2 from variable of differentiation). <rant> Maxima adopts numerous mathematical conventions, mostly successfully, but this customary sloppiness with differentials is something I wish we could clean up. </rant> Not sure how the proposed workaround is supposed to work. It turns out g1(x) = bessel_i(1,x)*%e^x  surprise!  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=873301&group_id=4933 