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}
(32) 
_{Dec}

S  M  T  W  T  F  S 







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

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

17
(3) 
18
(1) 
19
(3) 
20
(2) 
21
(4) 
22
(3) 
23
(8) 
24
(4) 
25
(6) 
26
(4) 
27
(14) 
28
(10) 
29
(3) 
30
(4) 
31
(4) 





From: SourceForge.net <noreply@so...>  20100511 23:14:38

Bugs item #1723548, was opened at 20070522 17:13 Message generated for change (Settings changed) made by crategus You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1723548&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: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: gradef for variables: not used in diff Initial Comment: Consider the following: (%i13) gradef(Vb, R, Sb) $ (%i14) diff(Vb); (%o14) Sb del(R) (%i15) diff(3*Vb); (%o15) 3 del(Vb) Instead of %o15 I would have expected 3*Sb*del(R). In functional notation showing the dependency on R, things seem to work: (%i21) gradef(Va(R), Sa) $ (%i22) diff(Va(R)); (%o22) Sa del(R) (%i23) diff(3*Va(R)); (%o23) 3 Sa del(R) This behavior may be related to the fact that %i13 does not update gradefs. On the mailing list, Robert Dodier mentioned the following: This behavior seems to be intentional, but certainly is confusing. The available documentation for gradef (probably derived from the union of old documentation and what could be puzzled out by reading the code) seems to distinguish gradef(F(x), ...) from gradef(F, x, ...) although the intended effect of this distinction is obscure. Certainly the two cases are treated differently by the code. gradef (Va(R), Sa); => Va(R) :lisp (symbolplist '$Va) => (GRAD ((r) $Sa)) gradef (Vb, R, Sa); => Vb :lisp (symbolplist '$Vb) => (MPROPS (NIL DEPENDS ($r) $ATOMGRAD (($r . $Sa)))) gradefs; => [Va(R)] An easy fix would be to cause the two forms of gradef to assign the same properties. But I don't know what else that would break.  >Comment By: Dieter Kaiser (crategus) Date: 20100512 01:14 Message: This bug has been fixed in the routine extracvars in the file comm2.lisp revision 1.34. Closing this bug report as fixed. Dieter Kaiser  Comment By: Dieter Kaiser (crategus) Date: 20100511 23:57 Message: Again the problem which is a bit reformulated: (%i1) depends(f,[x,y])$ This is the correct total differential: (%i2) diff(f); (%o2) 'diff(f,y,1)*del(y)+'diff(f,x,1)*del(x) But it does not work when we have an expression with the symbol f: (%i3) diff(3*f); (%o3) 3*del(f) (%i4) diff(a*f); (%o4) a*del(f)+f*del(a) The problem is in the routine extractvars, which is called from the routine stotaldiff. This routine only collects the variables of the expression we have passed to the routine stotaldiff, but does not take into account the dependencies. This can be corrected and we get the expected results: (%i6) diff(3*f); (%o6) 3*'diff(f,y,1)*del(y)+3*'diff(f,x,1)*del(x) (%i7) diff(a*f); (%o7) a*'diff(f,y,1)*del(y)+a*'diff(f,x,1)*del(x)+f*del(a) Dieter Kaiser  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1723548&group_id=4933 
From: SourceForge.net <noreply@so...>  20100511 21:57:51

Bugs item #1723548, was opened at 20070522 17:13 Message generated for change (Comment added) made by crategus You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1723548&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: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: gradef for variables: not used in diff Initial Comment: Consider the following: (%i13) gradef(Vb, R, Sb) $ (%i14) diff(Vb); (%o14) Sb del(R) (%i15) diff(3*Vb); (%o15) 3 del(Vb) Instead of %o15 I would have expected 3*Sb*del(R). In functional notation showing the dependency on R, things seem to work: (%i21) gradef(Va(R), Sa) $ (%i22) diff(Va(R)); (%o22) Sa del(R) (%i23) diff(3*Va(R)); (%o23) 3 Sa del(R) This behavior may be related to the fact that %i13 does not update gradefs. On the mailing list, Robert Dodier mentioned the following: This behavior seems to be intentional, but certainly is confusing. The available documentation for gradef (probably derived from the union of old documentation and what could be puzzled out by reading the code) seems to distinguish gradef(F(x), ...) from gradef(F, x, ...) although the intended effect of this distinction is obscure. Certainly the two cases are treated differently by the code. gradef (Va(R), Sa); => Va(R) :lisp (symbolplist '$Va) => (GRAD ((r) $Sa)) gradef (Vb, R, Sa); => Vb :lisp (symbolplist '$Vb) => (MPROPS (NIL DEPENDS ($r) $ATOMGRAD (($r . $Sa)))) gradefs; => [Va(R)] An easy fix would be to cause the two forms of gradef to assign the same properties. But I don't know what else that would break.  >Comment By: Dieter Kaiser (crategus) Date: 20100511 23:57 Message: Again the problem which is a bit reformulated: (%i1) depends(f,[x,y])$ This is the correct total differential: (%i2) diff(f); (%o2) 'diff(f,y,1)*del(y)+'diff(f,x,1)*del(x) But it does not work when we have an expression with the symbol f: (%i3) diff(3*f); (%o3) 3*del(f) (%i4) diff(a*f); (%o4) a*del(f)+f*del(a) The problem is in the routine extractvars, which is called from the routine stotaldiff. This routine only collects the variables of the expression we have passed to the routine stotaldiff, but does not take into account the dependencies. This can be corrected and we get the expected results: (%i6) diff(3*f); (%o6) 3*'diff(f,y,1)*del(y)+3*'diff(f,x,1)*del(x) (%i7) diff(a*f); (%o7) a*'diff(f,y,1)*del(y)+a*'diff(f,x,1)*del(x)+f*del(a) Dieter Kaiser  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1723548&group_id=4933 
From: SourceForge.net <noreply@so...>  20100511 20:34:08

Bugs item #873301, was opened at 20040108 21:39 Message generated for change (Comment added) made by crategus 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: Open Resolution: None 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: Dieter Kaiser (crategus) Date: 20100511 22: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 17: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 
From: SourceForge.net <noreply@so...>  20100511 18:26:28

Bugs item #3000108, was opened at 20100511 20:26 Message generated for change (Tracker Item Submitted) made by uhlst You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3000108&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: uhlst (uhlst) Assigned to: Nobody/Anonymous (nobody) Summary: Inconsistency of 1x1matrices Initial Comment: I'm not quite sure whether this is a bug or not, but defining two 1x1 matrices and multiplying them with "." returns a scalar and not a matrix. Multiplying them both by "*" gives a matrix. It should in this case either give also a scalar or an error. So the question is, whether Maxima should automatically switch from 1x1 matrices to scalars and back. I think returning a scalar for the "." is ok if the same happens for "*". (%i7) kill(all); (%o0) done (%i1) a: matrix([1]);b: matrix([2]); (%o1) [ 1 ] (%o2) [ 2 ] (%i3) a.b; (%o3) 2 (%i4) a*b; (%o4) [ 2 ] (%i5) c: 2; (%o5) 2 (%i6) c.a; (%o6) [ 2 ] (%i7) c*a; (%o7) [ 2 ]  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3000108&group_id=4933 
From: SourceForge.net <noreply@so...>  20100511 00:09:55

Bugs item #2999635, was opened at 20100510 23:52 Message generated for change (Comment added) made by crategus You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2999635&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  Trigonometry Group: None >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Dieter Kaiser (crategus) Assigned to: Nobody/Anonymous (nobody) Summary: trigrat(sin(1)) makes mess Initial Comment: trigrat(sin(1)) should return sin(1). But we get the following: (%i6) trigrat(sin(1)); (%o6) (%i*(sin(1)*sin(2)+cos(1)*cos(2)cos(1)) cos(1)*sin(2)+sin(1)*cos(2)sin(1)) /(2*sin(1)^2+2*cos(1)^2) This bug is related to the bug report ID: 742909  trigrat(sin(x/2)) makes a mess. Both bugs can be fixed in the function $listofei in the file trigrat.lisp. Dieter Kaiser  >Comment By: Dieter Kaiser (crategus) Date: 20100511 02:09 Message: Fixed in trigrat.lisp revision 1.9. Closing this bug report as fixed. Dieter Kaiser  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2999635&group_id=4933 
From: SourceForge.net <noreply@so...>  20100511 00:08:52

Bugs item #742909, was opened at 20030525 00:27 Message generated for change (Comment added) made by crategus You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=742909&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  Trigonometry Group: None >Status: Closed >Resolution: Fixed Priority: 4 Private: No Submitted By: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: trigrat(sin(x/2)) makes a mess Initial Comment: trigrat(sin(x/2)) => (%I*(SIN(x/2)*SIN(x)+COS(x/2)*COS(x)COS(x/2)) COS(x/2)*SIN(x)+SIN(x/2)*COS(x)SIN(x/2))/(2*SIN(x/2) ^2+2*COS(x/2)^2) Although this is correct, I doubt that this is what trigrat is supposed to do. After all, it has not eliminated sin (x/2); the result contains sin(x/2), but also contains sin^2+cos^2, so it doesn't seem "more linear" in any sense. Also, it is not a canonical form: trigrat(ev(sin (x/2),halfangles)) gives something else (even messier). Note also that sin(2*x) does not expand in trigrat.  >Comment By: Dieter Kaiser (crategus) Date: 20100511 02:08 Message: Fixed in trigrat.lisp revision 1.9. Closing this bug report as fixed. Dieter Kaiser  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=742909&group_id=4933 