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}
(25) 
_{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...>  20100328 17:55:57

Bugs item #2944431, was opened at 20100202 09:26 Message generated for change (Comment added) made by alex108 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: Aleksas Domarkas (alex108) Date: 20100328 20:55 Message: 1. (%i1) solve(7/10000*x^(1+874/1000)=500,x),simp=false; (%o1) [x=(5000000/7)^(937/500)^(1)] (%i2) ratsimp(%); (%o2) [x=5000000^(500/937)/7^(500/937)] (%i3) float(%), numer; (%o3) [x=1329.63071069307] 2. (%i4) f(x):=7/10000*x^(1+874/1000); (%o4) f(x):=7/10000*x^(1+874/1000) (%i5) t(x):=(f(x)f(500))/(x500); (%o5) t(x):=(f(x)f(500))/(x500) (%i6) limit(t(x),x,500); (%o6) 6559/(5*2^(1063/250)*125^(563/500)) (%i7) float(%), numer; (%o7) 0.29975567251994 3. (%i8) eq:1.5^x=34; (%o8) 1.5^x=34 (%i9) ratsimp(%); rat: replaced 1.5 by 3/2 = 1.5 (%o9) 3^x/2^x=34 (%i10) solve(eq,x),simp=false; rat: replaced 1.5 by 3/2 = 1.5 (%o10) [x=log(34)/log(3/2)] (%i11) float(%),numer; (%o11) [x=8.697075171448409]  Comment By: Raymond Toy (rtoy) Date: 20100315 15: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 15: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 23: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 16: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...>  20100328 15:03:22

Bugs item #2907727, was opened at 20091202 15:19 Message generated for change (Settings changed) made by rtoy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2907727&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: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Incorrect Integral with option integrate_use_rootsof :true Initial Comment: This integral previously crashed maxima, see bug 2906049. Now it gives the wrong answer. integrate_use_rootsof : true; integrate((d*QA^2+2*c*QA+3*b)/(g*QA^3*R+d*QA^2+c*QA+b),QA); yields: lsum(((%r1^2*d+2*%r1*c+3*b)*g*log(QA%r1)*R)/(3*%r1^2*g*R+2*%r1*d+c),%r1,rootsof(g*QA^3*R+d*QA^2+c*QA+b)) but the correct answer is lsum(((%r1^2*d+2*%r1*c+3*b)*log(QA%r1))/(3*%r1^2*g*R+2*%r1*d+c),%r1,rootsof(g*QA^3*R+d*QA^2+c*QA+b)) I'm using Maxima version: 5.20post Maxima build date: 9:7 12/2/2009 Host type: i686pclinuxgnu Lisp implementation type: CLISP Lisp implementation version: 2.44.1 (20080223) (built 3427367244) (memory 3468751644)  >Comment By: Raymond Toy (rtoy) Date: 20100328 11:03 Message: Fixed in sinint.lisp, rev 1.10  Comment By: Raymond Toy (rtoy) Date: 20100326 09:04 Message: I think multiplying by the leading factor is wrong. I think the algorithm is basically a partial fraction expansion of N(x)/D(x) = sum(A(n)/(xr(n)), n=1,N) where r(n) is a root of D(x). The constant A(n) can be determined by computing limit(N(x)*D(x)/(xr), x, r), but that's basically N(r)*at(diff(D(x),x), [x=r]). The code basically does this, but multiplies by the leading factor.  Comment By: Dieter Kaiser (crategus) Date: 20091202 17:52 Message: I had a look at wolfram alpha and I have got as a reference the following result: integral (d x^2+2 c x+3 b)/(g r x^3+d x^2+c x+b) dx = RootSum[#1^3 g r+#1^2 d+#1 c+b&, (#1^2 d log(x#1)+3 b log(x#1)+2 #1 c log(x#1))/(3 #1^2 g r+2 #1 d+c)&]+constant This corresponds to your solution. Maxima has an extra factor g*r. So, the algorithm now is working, but it seems to be wrong. The extra factor is the leading coefficient of the denominator. This factor is extracted and multiplied into the result by the algorithm. Dieter Kaiser  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2907727&group_id=4933 
From: SourceForge.net <noreply@so...>  20100328 14:23:22

Bugs item #2924831, was opened at 20100102 03:56 Message generated for change (Settings changed) made by rtoy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2924831&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: Andrej Vodopivec (andrejv) Assigned to: Nobody/Anonymous (nobody) Summary: file_type is wrong for ccl on mac os x Initial Comment: clozure cl compiled files have the extension .dx64fls on mac os x. file_type thinks this are demo files since it only checks the first character of the extension. load therefore fails to load compiled files.  Comment By: Raymond Toy (rtoy) Date: 20100325 15:07 Message: This is fine with me. I'll check it in shortly.  Comment By: Andrej Vodopivec (andrejv) Date: 20100311 03:48 Message: I think we can replace file_type in mload.lisp with (defun $file_type (fil &aux typ) (setq typ ($pathname_type fil)) (cond ((member typ (list "l" "lsp" "lisp") :test #'string=) '$lisp) ((member typ (list "mac" "mc" "demo" "dem" "dm1" "dm2" "dm3" "dmt") :test #'string=) '$maxima) (t '$object)))  Comment By: Raymond Toy (rtoy) Date: 20100204 08:05 Message: Perhaps file_type should be more explicit. So "max", "mac", "dem", and "demo" are maxima files; "l", "lsp", and "lisp" are lisp files, and everything else are object files. Maybe we can also let the user specify the association between the file extension and the file type?  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2924831&group_id=4933 
From: SourceForge.net <noreply@so...>  20100328 01:06:11

Bugs item #2977830, was opened at 20100328 01:06 Message generated for change (Tracker Item Submitted) made by nobody You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2977830&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: Implement a feature that shows work (=feature request) Initial Comment: It would be nice to have a feature that shows work like Wolfram Alpha does for students.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2977830&group_id=4933 