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

_{Jun}

_{Jul}

_{Aug}

_{Sep}

_{Oct}

_{Nov}

_{Dec}

S  M  T  W  T  F  S 


1
(1) 
2
(4) 
3
(2) 
4
(1) 
5

6

7
(5) 
8
(9) 
9

10
(2) 
11
(6) 
12
(12) 
13
(5) 
14
(7) 
15
(4) 
16
(4) 
17

18

19
(2) 
20
(7) 
21
(9) 
22
(7) 
23
(6) 
24
(5) 
25
(12) 
26
(12) 
27
(10) 
28
(4) 
29
(4) 
30
(5) 
31




From: SourceForge.net <noreply@so...>  20100315 18:44:57

Bugs item #2970792, was opened at 20100315 18:44 Message generated for change (Tracker Item Submitted) made by nobody You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2970792&group_id=4933 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Share Libraries Group: To be reviewed Status: Open Resolution: None Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: gradef(s) together with vect package Initial Comment: I was surprised with the following behavior: Maxima 5.20.1 http://maxima.sourceforge.net using Lisp SBCL 1.0.30 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) gradef(S(x,n,i), C(x,n,i), 0, 0); (%o1) S(x, n, i) (%i2) gradefs; (%o2) [S(x, n, i)] (%i3) load(vect); (%o3) /usr/share/maxima/5.20.1/share/vector/vect.mac (%i4) gradefs; (%o4) grad efs (%i5) diff(S(x,n,i), x); (%o5) C(x, n, i) (%i6) gradef(C(x,n,i), s(x,n,i), 0, 0); (%o6) grad ef(C(x, n, i), s(x, n, i), 0, 0) (%i7) diff(S(x,n,i), x); (%o7) C(x, n, i) (%i8) diff(C(x,n,i), x); d (%o8)  (C(x, n, i)) dx (%i9) In other words, after loading 'vect.mac', where the GRAD operator is defined, Maxima starts to intepret GRADEF as GRAD(EF) [and GRADEFS similarly]. I had to edit 'vect.mac' and change all apearances of GRAD to GRAD2 (e.g.) to preserve the original behavior of GRADEF. Is this intended behavior?  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2970792&group_id=4933 
From: SourceForge.net <noreply@so...>  20100315 13:44:27

Bugs item #2944431, was opened at 20100202 02:26 Message generated for change (Comment added) made by rtoy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2944431&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: To be reviewed Status: Open Resolution: None Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: 0.0007s^1.874 Initial Comment: Hi, I have the following Problem (from a German math book for K12): Given the following function f(x):=0.0007*s^1.874. 1. It is not possible to solve(f(x)=500,x) Given t(x):=(f(x)f(500))/(x500) 2. It is not possible to calculate limit(t(x),x,500) or to approximate by t(499.99999999999999999). From a certain number of 9s, the result is wrong. Given 1.5^x=34 3. It is not possible to solve the equation.  >Comment By: Raymond Toy (rtoy) Date: 20100315 09:44 Message: Oops. Maxima should be able to solve 1.5^x=34 (or equivalently (3/2)^x=34).  Comment By: Raymond Toy (rtoy) Date: 20100315 09:41 Message: 1. find_root(f(x)=500,x,0,10000) > 1329.63 2. limit(t(x),x,500) > infinity. This is a bug. But t(499.99999999999999) is not a bug. 499.999999999999999 rounds to 500.0 so we get a division by zero error. 3. find_root(1.5^x=34,x,1,10) > 8.697... You wanted numerical results, so solve is not really what you want to use. find_root is better suited. The limit is problem. But note that if you replace the floating point numbers with rationals, maxima can evaluate the limit: f1(x) := 7*10^(4)*x^(1874/1000)$ t1(x):=(f1(x)f1(500))/(x500)$ limit(t1(x),x,500) > 6559/(5*2^(1063/250)*125^(563/500)) I don't think there's anything wrong with maxima in any of these items.  Comment By: Nobody/Anonymous (nobody) Date: 20100202 16:37 Message: Thanks rtoy, but the bugs are causing problems. I, as a teacher, started to replace the TI Voyage 200, by maxima. The TI Voyage is very simply. You type solve and (almost) every equation will be solve. So maxima is one step back for my students. Ok, they are forced to think before they decide to solve an equation because they have to choose a function which is able to solve the equation, but, in my opinion, K12stuff should be solved in a very simply way. Maybe this post helps to fix the bugs. To the programmers: Thanks for maxima  Comment By: Raymond Toy (rtoy) Date: 20100202 09:27 Message: 1. Maxima converts the float number to rationals and is trying to solve 7/10000*s^(937/500). It seems that maxima did find the roots, but is taking a very long time to sort all 937 roots. This is a bug. If you want numerical results, then perhaps find_root is what you're looking for. 2. That is due to the finite precision available with floating point. If you want to be able to do this with arbitrary precision use bfloats with enough digits. This is not a bug. 3. Yes, maxima cannot solve this equation. That is a bug. But for numerical answers, maybe find_root is what you're looking for.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2944431&group_id=4933 
From: SourceForge.net <noreply@so...>  20100315 13:41:38

Bugs item #2944431, was opened at 20100202 02:26 Message generated for change (Comment added) made by rtoy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2944431&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: To be reviewed Status: Open Resolution: None Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: 0.0007s^1.874 Initial Comment: Hi, I have the following Problem (from a German math book for K12): Given the following function f(x):=0.0007*s^1.874. 1. It is not possible to solve(f(x)=500,x) Given t(x):=(f(x)f(500))/(x500) 2. It is not possible to calculate limit(t(x),x,500) or to approximate by t(499.99999999999999999). From a certain number of 9s, the result is wrong. Given 1.5^x=34 3. It is not possible to solve the equation.  >Comment By: Raymond Toy (rtoy) Date: 20100315 09:41 Message: 1. find_root(f(x)=500,x,0,10000) > 1329.63 2. limit(t(x),x,500) > infinity. This is a bug. But t(499.99999999999999) is not a bug. 499.999999999999999 rounds to 500.0 so we get a division by zero error. 3. find_root(1.5^x=34,x,1,10) > 8.697... You wanted numerical results, so solve is not really what you want to use. find_root is better suited. The limit is problem. But note that if you replace the floating point numbers with rationals, maxima can evaluate the limit: f1(x) := 7*10^(4)*x^(1874/1000)$ t1(x):=(f1(x)f1(500))/(x500)$ limit(t1(x),x,500) > 6559/(5*2^(1063/250)*125^(563/500)) I don't think there's anything wrong with maxima in any of these items.  Comment By: Nobody/Anonymous (nobody) Date: 20100202 16:37 Message: Thanks rtoy, but the bugs are causing problems. I, as a teacher, started to replace the TI Voyage 200, by maxima. The TI Voyage is very simply. You type solve and (almost) every equation will be solve. So maxima is one step back for my students. Ok, they are forced to think before they decide to solve an equation because they have to choose a function which is able to solve the equation, but, in my opinion, K12stuff should be solved in a very simply way. Maybe this post helps to fix the bugs. To the programmers: Thanks for maxima  Comment By: Raymond Toy (rtoy) Date: 20100202 09:27 Message: 1. Maxima converts the float number to rationals and is trying to solve 7/10000*s^(937/500). It seems that maxima did find the roots, but is taking a very long time to sort all 937 roots. This is a bug. If you want numerical results, then perhaps find_root is what you're looking for. 2. That is due to the finite precision available with floating point. If you want to be able to do this with arbitrary precision use bfloats with enough digits. This is not a bug. 3. Yes, maxima cannot solve this equation. That is a bug. But for numerical answers, maybe find_root is what you're looking for.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2944431&group_id=4933 
From: SourceForge.net <noreply@so...>  20100315 13:19:02

Bugs item #1995531, was opened at 20080616 17:49 Message generated for change (Settings changed) made by rtoy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1995531&group_id=4933 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Lisp Core Group: None >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: zeta errors near 0.0 / 0.0b0 Initial Comment: zeta(0.0) => division by zero zeta(1.0e20) => division by zero zeta(0.0b0) => division by zero And the values aren't accurate near 0.0b0: fpprec:20% zeta(1.0b7) => 1.05b3 (WAY WAY OFF!!) zeta(1.0b20) => 4.919b1 (WAY OFF!) zeta(10.0b13) < 1/2 (WAY OFF!)  >Comment By: Raymond Toy (rtoy) Date: 20100315 09:19 Message: Suggested solution implemented in combin.lisp, rev 1.43. Closing report.  Comment By: Raymond Toy (rtoy) Date: 20100314 15:06 Message: I agree with your assessment and your solution. If you don't check it in soon, I'll do it.  Comment By: Dieter Kaiser (crategus) Date: 20100313 14:34 Message: We have a new implementation of the numerical algorithm for the zeta function. But still we have problems near the value zero. We get a Lisp error for a small floating point argument: (%i1) zeta(1.0e20); Maxima encountered a Lisp error: arithmetic error DIVISIONBYZERO signalled Automatically continuing. To enable the Lisp debugger set *debuggerhook* to nil. The accurarcy is bad for bigfloat values near zero: (%i2) fpprec:20$ (%i4) zeta(1.0b20); (%o4) 5.1145234580810622639b1 (%i5) zeta(10.0b13); (%o5) 5.0000000078891903798b1 I think the best is to implement the following approximation near a zero argument: zeta(s) = 1/2  1/2*log(2*%pi)*s + O(s^2) This is the code which does it: (defun floatzeta (s) (let ((s (bigfloat:to s))) (cond ((bigfloat:< (bigfloat:* s s) (bigfloat:epsilon s)) ;; s^2 < epsilon, use the expansion zeta(s) = 1/21/2*log(2*%pi)*s (bigfloat:+ (bigfloat:/ 1 2) (bigfloat:* (bigfloat:/ 1 2) (bigfloat:log (bigfloat:* 2 (bigfloat:%pi s))) s))) ... With this approximation we get correct results for a small argument near the value zero: (%i7) zeta(1.0e20); (%o7) 0.5 (%i8) zeta(1.0b20); (%o8) 4.9999999999999999999b1 (%i9) zeta(10.0b13); (%o9) 4.9999999999908106147b1 Dieter Kaiser  Comment By: Barton Willis (willisbl) Date: 20080622 06:42 Message: Logged In: YES user_id=895922 Originator: NO Also try makelist(bfloat(bfzeta(1.0b7,20 + 10 * k)),k,1,40). The bug doesn't seem to be just a case of subtractive cancellation.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1995531&group_id=4933 