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}
(54) 
_{Nov}

_{Dec}

S  M  T  W  T  F  S 






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

10
(3) 
11
(1) 
12
(2) 
13
(11) 
14
(1) 
15
(5) 
16

17

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

31
(3) 






From: SourceForge.net <noreply@so...>  20090528 23:40:23

Bugs item #792114, was opened at 20030820 21:12 Message generated for change (Comment added) made by crategus You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=792114&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: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Stavros Macrakis (macrakis) Assigned to: Robert Dodier (robert_dodier) Summary: \"/\" should be the quotient operator /FIX Initial Comment: The name of the quotient operator is currently "//" rather than "/". There is no good reason for this. Currently: part(a/b,0) => "//" (internally &//) "//"(a,b) => a/b Strangely, it also works to say: "/"(a,b) => a/b apply("//",[a,b]) => a/b but apply("/",[a,b]) gives /(a,b), which has nothing to do with division. This is inconsistent, confusing, and unnecessary. I suspect it is accidental, because in some Lisps you needed to write // instead of / (/ was an escape character). Fix: in comm.lisp, change (MNCTIMES &.) (RAT &//) (MQUOTIENT &//) (MNCEXPT &^^) to (MNCTIMES &.) (RAT &/) (MQUOTIENT &/) (MNCEXPT &^^) I suppose you could go through the whole source and change // to /, but since all the other uses are internal, it doesn't matter.  >Comment By: Dieter Kaiser (crategus) Date: 20090529 01:40 Message: With revision 1.27 of comm.lisp the name of the operator / has changed to "/". The examples work as expected. See also bug report ID: 712462 "Operator "/" treated inconsistently". Closing this bug report as fixed. Dieter Kaiser  Comment By: Robert Dodier (robert_dodier) Date: 20060710 05:10 Message: Logged In: YES user_id=501686 Closely related to bug report # 712462. After applying the patch given here, verify whether the problems reported in are resolved.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=792114&group_id=4933 
From: SourceForge.net <noreply@so...>  20090528 23:37:19

Bugs item #712462, was opened at 20030331 06:33 Message generated for change (Comment added) made by crategus You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=712462&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: Robert Dodier (robert_dodier) Summary: Operator "/" treated inconsistently Initial Comment: "/"(a,b) correctly gives a/b However, in most other contexts, Maxima expects "//": part(a/b,0) => // WHY? subst("/",f,f(a,b)) => /(a,b) NO! substpart("/",f(a,b),0) => /(a,b) NO! apply("/",[a,b]) => /(a,b) NO! This is presumably a relic of the Maclisp quoting convention that used slash to quote the next character (similar to backslash in Common Lisp). Presumably in the Maclisp version, it cancelled out and the user saw "/", not "//". This needs to be fixed for Common Lisp. Maxima 5.9.0 GCL 2.5.0 Windows 2000  >Comment By: Dieter Kaiser (crategus) Date: 20090529 01:36 Message: With revision 1.27 of comm.lisp the name of the operator / has changed to "/". The examples of this bug report give as expected: (%i8) part(a/b); (%o8) a/b (%i9) part(a/b,0); (%o9) "/" (%i10) subst("/",f,f(a,b)); (%o10) a/b (%i11) substpart("/",f(a,b),0); (%o11) a/b (%i12) apply("/",[a,b]); (%o12) a/b Closing this bug report as fixed. Dieter Kaiser  Comment By: Robert Dodier (robert_dodier) Date: 20060710 05:10 Message: Logged In: YES user_id=501686 Closely related to bug report # 792114. Maybe applying fix given in that report will fix the problems shown here.  Comment By: Robert Dodier (robert_dodier) Date: 20050411 05:51 Message: Logged In: YES user_id=501686 This seems to be a problem with differing internal and external representations for the same operator. I don't think the / vs // has much to do with it, although it would be nice if one or the other were used consistently. An input a/b is parsed as ((MQUOTIENT) $A $B)  as far as I can tell, it is not simplified to that from ((&/) $A $B), instead it seems the simplifier never sees the operator (&/) and so it doesn't have any rules for simplifying that into (MQUOTIENT). It seems the fundamental problem would be resolved by moving the substitution / > MQUOTIENT out of the parser and into the simplifier; if there are other such replacements, maybe they should be moved too. tellsimpafter seems happy enough to clean up for us: (%i9) apply("/", [a,b]); (%o9) /(a, b) /* OOPS */ [... snip ...] (%i11) matchdeclare ([a,b],true); (%o11) done (%i12) tellsimpafter (''%o9, a/b); (%o12) [/RULE1, false] [... snip ...] (%i19) apply ("/", [a+b, cd]); b + a (%o19)  /* OK */ c  d (%i20) subst ("/", f, f(x,y)); x (%o20)  /* OK */ y (%i21) substpart ("/", f(x,y), 0); x (%o21)  /* OK */ y  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=712462&group_id=4933 
From: SourceForge.net <noreply@so...>  20090528 23:13:45

Bugs item #826623, was opened at 20031020 06:25 Message generated for change (Comment added) made by crategus You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=826623&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: Includes proposed fix >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: simplifer returns %i*%i Initial Comment: ((%i)^(1/2)*%i)*((%i)^(1/2)) => %i*%i Resimplifying  expand(%,0,0)  correctly returns 1. Maxima 5.9.0 gcl 2.5.0 mingw32 W2k Athlon  >Comment By: Dieter Kaiser (crategus) Date: 20090529 01:13 Message: Suggested test for a base which is a mtimes expressions in expressions like (a*b)^q*(a*b)^q, where q+r=1 has been checked out. The example of this bug report now simplifies: (%i6) sqrt(%i)*sqrt(%i)*%i; (%o6) 1 Other examples are: (%i7) sqrt(a*b)*sqrt(a*b)*a*b; (%o7) a^2*b^2 (%i8) (a*b*x)^(1/5)*(a*b*x)^(4/5)*x; (%o8) a*b*x^2 The initial example simplifies correctly. Closing this bug report as fixed. Dieter Kaiser  Comment By: Dieter Kaiser (crategus) Date: 20090525 18:54 Message: I had a look at this bug. Here are some more general examples related to this report: (%i3) a*sqrt(a*b)*sqrt(a*b); (%o3) a*(a*b) (%i4) a*b*sqrt(a*b)*sqrt(a*b); (%o4) a*b*(a*b) Now with another exponent: (%i5) a*b*(a*b)^(1/4)*(a*b)^(3/4); (%o5) a*b*(a*b) Here is the example from this bug report: (%i6) %i*sqrt(%i)*sqrt(%i); (%o6) %i*%i This simplification error can be located to occur in the routine timesin in simp.lisp. This is the small piece of code which is responsible: ((onep1 w) (return (rplaca (cdr fm) (car x)))) When two factors are equal and the exonentents of the factors sum to 1, e. g. for sqrt(a*b)*sqrt(a*b) the factor is replaced by the base, that is for this example (a*b). Unfortunately, this is a mtimes expression. The simplifier generates a result with an unsimplified and nested mtimes expression in it. I have tried to find a better implementation and I have found the following code which works: ((onep1 w) (cond ((mtimesp (car x)) ;; A base which is a mtimes expression. ;; Remove the factor from the lists of products. (rplacd fm (cddr fm)) ;; We multiply the complete base with the list ;; of all remaining factors. (setq rulesw t) (return (muln (nconc y (cdar x)) t))) ;; The old code for the other cases. (t (return (rplaca (cdr fm) (car x)))))) Again the above examples with the modified code: (%i3) a*b*sqrt(a*b)*sqrt(a*b); (%o3) a^2*b^2 (%i4) a*sqrt(a*b)*sqrt(a*b); (%o4) a^2*b (%i5) a*b*sqrt(a*b)*sqrt(a*b); (%o5) a^2*b^2 (%i6) a*b*(a*b)^(1/4)*(a*b)^(3/4); (%o6) a^2*b^2 That is the example of this bug report: (%i7) %i*sqrt(%i)*sqrt(%i); (%o7) 1 The testsuite has no problems with the new code. Because this is a fundamental simplification error I supposed to get more problems with the testsuite. Perhaps a lot of examples do some extra expansions to get the desired simple result. The other inconsistencies reported in the bug report are not caused by this problem. I am not sure if the code above is the best way to remove this problem, but it works. Any comments? Dieter Kaiser  Comment By: Robert Dodier (robert_dodier) Date: 20060711 06:40 Message: Logged In: YES user_id=501686 Observed in 5.9.3cvs.  Comment By: Stavros Macrakis (macrakis) Date: 20031020 07:55 Message: Logged In: YES user_id=588346 This may be related to the inconsistent simplification of simple expressions involving %i: Mathematically, %i^(1/4) = (%i)^(1/4), but the first simplifies to (1)^(1/8) and the second to (%i)^(1/4) . Mathematically, (1)^(1/4) = %i^(1/2) = (%i)^(1/2), but the first two simplify to 1/(1)^(1/4), while the third simplifies to sqrt(%i). There are other similar cases. This is also reminiscent of the the nonnormalization of 1/sqrt(2)  bug # 721575.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=826623&group_id=4933 
From: SourceForge.net <noreply@so...>  20090528 21:43:46

Bugs item #2797885, was opened at 20090528 14:39 Message generated for change (Comment added) made by crategus You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2797885&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: Includes proposed fix >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: problem with integration Initial Comment: (%i3) integrate((%e**(%i*x))*sin(x),x); Division by 0  an error. To debug this try debugmode(true); (%i4) integrate((cos(x) + %i*sin(x))*sin(x),x); sin(2 x) %i (x  ) 2 2 cos (x) (%o4)    2 2 Maxima version: 5.18.1 Maxima build date: 11:35 5/25/2009 host type: i686pclinuxgnuoldld lispimplementationtype: CLISP lispimplementationversion: 2.44.1 (20080223) (built 3437275172) (memory 3452232938) Maybe I don't know something... maybe some mathematic details? Or maybe maxima is using two different methods in each case?  >Comment By: Dieter Kaiser (crategus) Date: 20090528 23:43 Message: The suggested change has been checked out. Maxima now gets the result: (%i14) expand(integrate(exp(%i*x)*sin(x),x)); (%o14) %i*x/2%e^(2*%i*x)/4 These are the results for related integrands: (%i15) expand(integrate(exp(x)*sin(%i*x),x)); (%o15) %i*%e^(2*x)/4%i*x/2 (%i16) expand(integrate(exp(%i*x)*cos(x),x)); (%o16) x/2%i*%e^(2*%i*x)/4 (%i17) expand(integrate(exp(x)*cos(%i*x),x)); (%o17) %e^(2*x)/4+x/2 Closing this bug report as fixed. Dieter Kaiser  Comment By: Dieter Kaiser (crategus) Date: 20090528 19:21 Message: The problem is the routine sceint, which uses the following formula: (%i7) integrate(exp(a*x)*sin(b*x),x); (%o7) %e^(a*x)*(a*sin(b*x)b*cos(b*x))/(b^2+a^2) But for a=%i and b=1 this does not work. b^2+a^2 is zero and we get the error division by zero. A correct solution after a fix is: (%i8) integrate(exp(%i*x)*sin(x),x); (%o8) %i*x/2%e^(2*%i*x)/4 This is a possible fix: (defun sceint (exp sc var) (let* ((ecoef (car (islinear (caddr exp) var))) (sccoef (car (islinear (cadr sc) var))) (scarg (cadr sc)) (absval (add (power ecoef 2) (power sccoef 2)))) (if (zerop1 absval) ;; The numerator is zero. Exponentialize the expression ;; and try again. ($expand (integrator ($exponentialize (mul exp sc)) var)) (mul (div exp (add (power ecoef 2) (power sccoef 2))) (add (mul ecoef sc) (if (eq (caar sc) '%sin) (mul* (neg sccoef) `((%cos) ,scarg)) (mul* sccoef `((%sin) ,scarg)))))))) Dieter Kaiser  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2797885&group_id=4933 
From: SourceForge.net <noreply@so...>  20090528 20:46:03

Bugs item #2798102, was opened at 20090528 20:45 Message generated for change (Tracker Item Submitted) made by prozacr You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2798102&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: ProzacR (prozacr) Assigned to: Nobody/Anonymous (nobody) Summary: Bashlike arrow keys behavior in Linux terminal Initial Comment: Feature request. Bashlike arrow keys behavior in Linux terminal. Now pressing arrows just screw things up.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2798102&group_id=4933 
From: SourceForge.net <noreply@so...>  20090528 17:21:18

Bugs item #2797885, was opened at 20090528 14:39 Message generated for change (Comment added) made by crategus You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2797885&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: Includes proposed fix Status: Open Resolution: None Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: problem with integration Initial Comment: (%i3) integrate((%e**(%i*x))*sin(x),x); Division by 0  an error. To debug this try debugmode(true); (%i4) integrate((cos(x) + %i*sin(x))*sin(x),x); sin(2 x) %i (x  ) 2 2 cos (x) (%o4)    2 2 Maxima version: 5.18.1 Maxima build date: 11:35 5/25/2009 host type: i686pclinuxgnuoldld lispimplementationtype: CLISP lispimplementationversion: 2.44.1 (20080223) (built 3437275172) (memory 3452232938) Maybe I don't know something... maybe some mathematic details? Or maybe maxima is using two different methods in each case?  >Comment By: Dieter Kaiser (crategus) Date: 20090528 19:21 Message: The problem is the routine sceint, which uses the following formula: (%i7) integrate(exp(a*x)*sin(b*x),x); (%o7) %e^(a*x)*(a*sin(b*x)b*cos(b*x))/(b^2+a^2) But for a=%i and b=1 this does not work. b^2+a^2 is zero and we get the error division by zero. A correct solution after a fix is: (%i8) integrate(exp(%i*x)*sin(x),x); (%o8) %i*x/2%e^(2*%i*x)/4 This is a possible fix: (defun sceint (exp sc var) (let* ((ecoef (car (islinear (caddr exp) var))) (sccoef (car (islinear (cadr sc) var))) (scarg (cadr sc)) (absval (add (power ecoef 2) (power sccoef 2)))) (if (zerop1 absval) ;; The numerator is zero. Exponentialize the expression ;; and try again. ($expand (integrator ($exponentialize (mul exp sc)) var)) (mul (div exp (add (power ecoef 2) (power sccoef 2))) (add (mul ecoef sc) (if (eq (caar sc) '%sin) (mul* (neg sccoef) `((%cos) ,scarg)) (mul* sccoef `((%sin) ,scarg)))))))) Dieter Kaiser  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2797885&group_id=4933 
From: SourceForge.net <noreply@so...>  20090528 16:07:52

Bugs item #1053056, was opened at 20041024 07:39 Message generated for change (Comment added) made by crategus You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1053056&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: Robert Dodier (robert_dodier) Assigned to: Nobody/Anonymous (nobody) Summary: TIME(%) always yields 0.0 Initial Comment: TIME(%) always yields 0.0. The cause is that TIME (suprv1.lisp) returns the value of LASTTIME when the TIME argument is %. However LASTTIME is assigned 0 and never assigned anything else; LASTTIME appears to be obsolete, and it is unused except for this reference in TIME. TIME uses the 'TIME property of output labels to fetch the computation time. % isn't assigned the 'TIME property, so presumably that's why TIME was asking for LASTTIME. Let's not resurrect LASTTIME. Instead let's (1) assign % the 'TIME property (search for "putprop dtag" in macsys.lisp) to find the place to do it); and (2) cut out the special case for % in TIME.  >Comment By: Dieter Kaiser (crategus) Date: 20090528 18:07 Message: The suggested change to store the computation time in the symbol '$% has been checked out (rev. 1.74, macsys.lisp). The variable $lasttime has been cut out (rev. 1.80, suprv1.lisp). Closing this bug report as fixed. Dieter Kaiser  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1053056&group_id=4933 
From: SourceForge.net <noreply@so...>  20090528 15:44:00

Bugs item #1053279, was opened at 20041024 19:17 Message generated for change (Comment added) made by crategus You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1053279&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: 3 Private: No Submitted By: Robert Dodier (robert_dodier) Assigned to: Nobody/Anonymous (nobody) Summary: TIME prints out message as well as returning a value Initial Comment: TIME prints out message ("Time:") as well as returning a value. This doesn't seem appropriate: other noninteractive functions only return a value. For example if you execute foo: TIME (%o1, %o2, %o3)$ you still get the "Time:" printout but no value is printed (since the return value printout is suppressed by the dollar sign).  >Comment By: Dieter Kaiser (crategus) Date: 20090528 17:43 Message: The message "Time:" has been cut out in suprv1.lisp with revision 1.33 in 2005. Closing this bug report as fixed. Dieter Kaiser  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1053279&group_id=4933 
From: SourceForge.net <noreply@so...>  20090528 12:39:52

Bugs item #2797885, was opened at 20090528 12:39 Message generated for change (Tracker Item Submitted) made by nobody You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2797885&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: problem with integration Initial Comment: (%i3) integrate((%e**(%i*x))*sin(x),x); Division by 0  an error. To debug this try debugmode(true); (%i4) integrate((cos(x) + %i*sin(x))*sin(x),x); sin(2 x) %i (x  ) 2 2 cos (x) (%o4)    2 2 Maxima version: 5.18.1 Maxima build date: 11:35 5/25/2009 host type: i686pclinuxgnuoldld lispimplementationtype: CLISP lispimplementationversion: 2.44.1 (20080223) (built 3437275172) (memory 3452232938) Maybe I don't know something... maybe some mathematic details? Or maybe maxima is using two different methods in each case?  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2797885&group_id=4933 
From: SourceForge.net <noreply@so...>  20090528 02:20:22

Bugs item #2790984, was opened at 20090513 01:55 Message generated for change (Comment added) made by sfrobot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2790984&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  Integration Group: None >Status: Closed Resolution: Invalid Priority: 5 Private: No Submitted By: caprilo (caprilo) Assigned to: Nobody/Anonymous (nobody) Summary: problem with sqrt(abx^2) calculus Initial Comment: The function integrate(sqrt(abx^2), x); returns sqrt(abx^2)*x which is obviously wrong. Worse is that, the differentiation of the wrong integral, diff(sqrt(abx^2)*x, x); returns the integrand!: sqrt(abx^2)  Maxima version: 5.13.0 Maxima build date: 9:20 12/12/2007 host type: i686pclinuxgnu lispimplementationtype: GNU Common Lisp (GCL) lispimplementationversion: GCL 2.6.8   >Comment By: SourceForge Robot (sfrobot) Date: 20090528 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: Nobody/Anonymous (nobody) Date: 20090513 11:38 Message: Input notation is different from output in mathematical notation as provided by Maxima. rtoy did give the right answer and the worse was for the better, namely that Maxima returned the function when differentiating the integral of the function.  Comment By: Raymond Toy (rtoy) Date: 20090513 03:48 Message: bx^2 is not the same as b*x^2, so you've basically integrated y wrt to x, which is y*x. Same with your differentiation. Marking this as pending/invalid. If this analysis is incorrect, please comment.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2790984&group_id=4933 