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}
(6) 
_{Mar}

_{Apr}

_{May}

_{Jun}

_{Jul}

_{Aug}

_{Sep}

_{Oct}

_{Nov}

_{Dec}

S  M  T  W  T  F  S 

1
(2) 
2
(6) 
3
(7) 
4
(2) 
5
(9) 
6
(14) 
7
(10) 
8
(6) 
9
(12) 
10
(1) 
11
(4) 
12
(9) 
13
(5) 
14
(18) 
15

16
(3) 
17
(3) 
18
(3) 
19
(1) 
20
(2) 
21
(5) 
22
(14) 
23
(2) 
24
(5) 
25
(1) 
26

27
(4) 
28
(8) 
29
(17) 
30
(8) 





From: SourceForge.net <noreply@so...>  20091112 23:17:06

Bugs item #2896713, was opened at 20091112 17:26 Message generated for change (Comment added) made by crategus You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2896713&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: Pending >Resolution: Duplicate Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: integration error Initial Comment: Maxima version: 5.17.1 Maxima build date: 14:9 7/13/2009 host type: i686pclinuxgnu lispimplementationtype: GNU Common Lisp (GCL) lispimplementationversion: GCL 2.6.7 On Ubuntu 9.10 when trying to integrate I get the following: (%i1) integrate(1/(x^3+1),x); Universal error handler called recursively (:ERROR NIL CONDITIONS::CLCSUNIVERSALERRORHANDLER "" "Couldn't protect") Universal error handler called recursively (:ERROR NIL CONDITIONS::CLCSUNIVERSALERRORHANDLER "" "Couldn't protect") Maxima encountered a Lisp error: Error in CONDITIONS::CLCSUNIVERSALERRORHANDLER [or a callee]: Caught fatal error [memory may be damaged] Automatically continuing. To reenable the Lisp debugger set *debuggerhook* to nil. It is strange, since on the previous version such error was not present. I am sure it is related to GCL, since with the same version on newly compiled FreeBSD maxima things goe the way they should: (%i1) integrate(1/(x^3+1),x); 2 x  1 2 atan() log(x  x + 1) sqrt(3) log(x + 1) (%o1)   +  +  6 sqrt(3) 3 html garbles the text! (%i2) build_info(); Maxima version: 5.17.1 Maxima build date: 15:58 11/4/2009 host type: i386portbldfreebsd7.0 lispimplementationtype: CLISP lispimplementationversion: 2.47 (20081023) (built 3466356167) (memory 3466357114) The difference is in the LISP!  >Comment By: Dieter Kaiser (crategus) Date: 20091113 00:17 Message: I think this bug report is a duplicate of the bug report ID: 2896728 "function sqrt() crashes". I suppose that again a debian package of Maxima is the source of the problems. An installation from souce code or cvs with serveral Lisp compilers does not give any problems. Setting the status to pending and the resolution to duplicate. Dieter Kaiser  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2896713&group_id=4933 
From: SourceForge.net <noreply@so...>  20091112 23:09:56

Bugs item #2896728, was opened at 20091112 17:47 Message generated for change (Settings changed) made by crategus You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2896728&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: To be reviewed >Status: Pending >Resolution: Works For Me Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: function sqrt() crashes Initial Comment: typing :sqrt(100); Answer : Universal error handler called recursively (:ERROR NIL CONDITIONS::CLCSUNIVERSALERRORHANDLER "" "Couldn't protect") Universal error handler called recursively (:ERROR NIL CONDITIONS::CLCSUNIVERSALERRORHANDLER "" "Couldn't protect") Maxima encountered a Lisp error: Error in CONDITIONS::CLCSUNIVERSALERRORHANDLER [or a callee]: Caught fatal error [memory may be damaged] Automatically continuing. To reenable the Lisp debugger set *debuggerhook* to nil. Maxima version: 5.17.1 Maxima build date: 14:9 7/13/2009 host type: i686pclinuxgnu lispimplementationtype: GNU Common Lisp (GCL) lispimplementationversion: GCL 2.6.7  >Comment By: Dieter Kaiser (crategus) Date: 20091113 00:09 Message: This bug report and the bug report ID: 2896713  "integration error" are not a problem of Maxima and not a problem of Ubuntu 9.10. Today, I have updated my system to Ubuntu 9.10 and I have no problems to compile and to run the testsuite of Maxima. I am sure that even Maxima 5.17.1 would have no problem to run on Ubuntu 9.10. The problem is the debian package for Maxima 5.17.1 with a binary which is compiled with GCL 2.6.7. The best that could be done is to distribute a new and clean debian package. Remark: I have started to build a debian package. Perhaps there is interest to get a working package. But I need some help to get it all correct. Setting this bug report to pending and the resulution to "Works for me". Dieter Kaiser  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2896728&group_id=4933 
From: SourceForge.net <noreply@so...>  20091112 16:47:51

Bugs item #2896728, was opened at 20091112 16:47 Message generated for change (Tracker Item Submitted) made by nobody You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2896728&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: To be reviewed Status: Open Resolution: None Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: function sqrt() crashes Initial Comment: typing :sqrt(100); Answer : Universal error handler called recursively (:ERROR NIL CONDITIONS::CLCSUNIVERSALERRORHANDLER "" "Couldn't protect") Universal error handler called recursively (:ERROR NIL CONDITIONS::CLCSUNIVERSALERRORHANDLER "" "Couldn't protect") Maxima encountered a Lisp error: Error in CONDITIONS::CLCSUNIVERSALERRORHANDLER [or a callee]: Caught fatal error [memory may be damaged] Automatically continuing. To reenable the Lisp debugger set *debuggerhook* to nil. Maxima version: 5.17.1 Maxima build date: 14:9 7/13/2009 host type: i686pclinuxgnu lispimplementationtype: GNU Common Lisp (GCL) lispimplementationversion: GCL 2.6.7  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2896728&group_id=4933 
From: SourceForge.net <noreply@so...>  20091112 16:26:18

Bugs item #2896713, was opened at 20091112 16:26 Message generated for change (Tracker Item Submitted) made by nobody You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2896713&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: Open Resolution: None Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: integration error Initial Comment: Maxima version: 5.17.1 Maxima build date: 14:9 7/13/2009 host type: i686pclinuxgnu lispimplementationtype: GNU Common Lisp (GCL) lispimplementationversion: GCL 2.6.7 On Ubuntu 9.10 when trying to integrate I get the following: (%i1) integrate(1/(x^3+1),x); Universal error handler called recursively (:ERROR NIL CONDITIONS::CLCSUNIVERSALERRORHANDLER "" "Couldn't protect") Universal error handler called recursively (:ERROR NIL CONDITIONS::CLCSUNIVERSALERRORHANDLER "" "Couldn't protect") Maxima encountered a Lisp error: Error in CONDITIONS::CLCSUNIVERSALERRORHANDLER [or a callee]: Caught fatal error [memory may be damaged] Automatically continuing. To reenable the Lisp debugger set *debuggerhook* to nil. It is strange, since on the previous version such error was not present. I am sure it is related to GCL, since with the same version on newly compiled FreeBSD maxima things goe the way they should: (%i1) integrate(1/(x^3+1),x); 2 x  1 2 atan() log(x  x + 1) sqrt(3) log(x + 1) (%o1)   +  +  6 sqrt(3) 3 html garbles the text! (%i2) build_info(); Maxima version: 5.17.1 Maxima build date: 15:58 11/4/2009 host type: i386portbldfreebsd7.0 lispimplementationtype: CLISP lispimplementationversion: 2.47 (20081023) (built 3466356167) (memory 3466357114) The difference is in the LISP!  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2896713&group_id=4933 
From: SourceForge.net <noreply@so...>  20091112 15:49:07

Bugs item #2880886, was opened at 20091017 08:13 Message generated for change (Comment added) made by crategus You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2880886&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: Robert Marik (robertmarik) Assigned to: Nobody/Anonymous (nobody) Summary: definite integral  bad answer Initial Comment: This bug has been reported at Sage forum http://groups.google.cz/group/sagedevel/t/c9c147c4dd4ea840 integrate(cos(x)^2 * (1 + sin(x)^2)^3,x,0,%pi/2) returns a value wich is numericaly about 1.4.... but the correct value is close to 0.49 This is my bug_report(), but according to the discussion, the same problem is in the CVS version. Maxima version: 5.18.1 Maxima build date: 13:5 5/3/2009 host type: i686pclinuxgnu lispimplementationtype: CMU Common Lisp lispimplementationversion: CVS 19d 19drelease (19D)  >Comment By: Dieter Kaiser (crategus) Date: 20091112 16:49 Message: For the record: This bug is related to the bugs: ID: 2890315  integrate(cot(x)^4,x,%pi/6,%pi/2) ID: 2880797  bad answer in integrate(sqrt(sin(t)^2+cos(t)^2),t,0,2*%pi) Again we get wrong poles for an atan expression. The suggested patch in the thread to the bug report ID: 2890315  integrate(cot(x)^4,x,%pi/6,%pi/2) does not help for this examle. Dieter Kaiser  Comment By: Andrej Vodopivec (andrejv) Date: 20091018 15:05 Message: I think the error comes from samesheetsubs (defint.lisp). The function substitutes the limits of integration into expressions which look like atan(something). It substitutes the limits plus it adds contributions from poles of something between the limits. The error is that it also adds contributions from poles on the limits, which I think should be ignored. The patch below fixes this behavior and with the patch applied we get (%i3) integrate(cos(x)^2 * (1 + sin(x)^2)^3,x,0,%pi/2); (%o3) 7*%pi/2^(11/2) (%i4) %, numer; (%o4) 0.485940321361071 Index: defint.lisp =================================================================== RCS file: /cvsroot/maxima/maxima/src/defint.lisp,v retrieving revision 1.66 diff u r1.66 defint.lisp  defint.lisp 6 Sep 2009 13:50:43 0000 1.66 +++ defint.lisp 18 Oct 2009 12:19:35 0000 @@ 938,7 +938,7 @@ ((not (equal (sratsimp ipart) 0)) ()) (t (let ((pole (polesininterval (let (($algebraic t)) (sratsimp (cadr exp)))  var ll ul))) + var ll ul :onboundary nil))) (cond ((and pole (not (or (eq pole '$unknown) (eq pole '$no)))) (do ((l pole (cdr l)) (llist ())) @@ 3259,7 +3259,7 @@ ;;; Returns $no $unknown or a list of poles in the interval (ll ul) ;;; for exp w.r.t. var. ;;; Form of list ((pole . multiplicity) (pole1 . multiplicity) ....) (defun polesininterval (exp var ll ul) +(defun polesininterval (exp var ll ul &key (onboundary t)) (let* ((denom (cond ((mplusp exp) ($denom (sratsimp exp))) ((and (mexptp exp) @@ 3290,7 +3290,7 @@ (t '$no))) (let* ((soltn (caar dummy)) ;; (multiplicity (cdar dummy)) (not used?  cwh)  (rootinllul (ininterval soltn ll ul))) + (rootinllul (ininterval soltn ll ul :onboundary onboundary))) (cond ((eq rootinllul '$no) '$no) ((eq rootinllul '$yes) (let ((limans (isapole exp soltn))) @@ 3365,7 +3365,7 @@ 'epsilon)) 'epsilon 0 '$plus)) (defun ininterval (place ll ul) +(defun ininterval (place ll ul &key (onboundary t)) ;; real values for ll and ul; place can be imaginary. (let ((order (askgreateq ul ll))) (cond ((eq order '$yes)) @@ 3374,8 +3374,8 @@ (list '(mlist simp) ll ul))))) (if (not (equal ($imagpart place) 0)) '$no  (let ((lessequl (askgreateq ul place))  (greateqll (askgreateq place ll))) + (let ((lessequl (askgreateq ul place :onboundary onboundary)) + (greateqll (askgreateq place ll :onboundary onboundary))) (if (and (eq lessequl '$yes) (eq greateqll '$yes)) '$yes '$no)))) (defun realroots (exp var) @@ 3401,7 +3401,7 @@ (cadr dummy)) rootlist))))))))))) (defun askgreateq (x y) +(defun askgreateq (x y &key (onboundary t)) ;;; Is x > y. X or Y can be $MINF or $INF, zeroA or zeroB. (let ((x (cond ((among 'zeroa x) (subst 0 'zeroa x)) @@ 3432,8 +3432,10 @@ ((eq y '$minf) '$yes) (t (let ((ans ($asksign (m+ x (m y)))))  (cond ((member ans '($zero $pos) :test #'eq) + (cond ((eq ans '$pos) '$yes) + ((eq ans '$zero) + (if onboundary '$yes '$no)) ((eq ans '$neg) '$no) (t '$unknown)))))))  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2880886&group_id=4933 
From: SourceForge.net <noreply@so...>  20091112 15:36:31

Bugs item #2890315, was opened at 20091101 16:54 Message generated for change (Comment added) made by crategus You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2890315&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: Open Resolution: None Priority: 5 Private: No Submitted By: mitreuden (mitreude) Assigned to: Nobody/Anonymous (nobody) Summary: integrate(cot(x)^4,x,%pi/6,%pi/2) answer Initial Comment: The first time integrate(cot(x)^4,x,%pi/6,%pi/2) is executed, the answer of %pi/3 returned is correct. However, when the integral is computed again, an incorrect answer of 4*%pi/3 is returned.  >Comment By: Dieter Kaiser (crategus) Date: 20091112 16:36 Message: I think the routine atanpoles does not work correctly for expressions like atan(tan(x)). It does not take into account the cases where we have more than one pole in the interval and it add extra poles which are not present. With triginverses set to ALL these bugs in atanpoles do not occur, because atan(tan(x)) is always simplified to x. The routine atanpoles therefore is never called. This error in atanpoles is responsible for both bugs: ID: 2890315  integrate(cot(x)^4,x,%pi/6,%pi/2) ID: 2880797  bad answer in integrate(sqrt(sin(t)^2+cos(t)^2),t,0,2*%pi) I have no idea what can be done in the routine atanpoles, but we can add a test in the routine intsubs. We simplify look for a atan(tan(x)) expression, simplify it and call limitsubs to go on: (t (setq rpart (sratsimp rpart)) (cond ((limitsubs rpart a b)) > ((eq (caar (cadr rpart)) '%tan) > ;; We have atan(tan(x)). We simplify it to x. > (limitsubs (cadr (cadr rpart)) a b)) (t (samesheetsubs rpart a b))))))))) With this extension we avoid to set the flag $triginverses. All works fine. The testsuite has no problems and the reported examples are correct: (%i5) integrate(sin(x)^2+cos(x)^2,x,0,2*%pi); (%o5) 2*%pi (%i6) integrate(cot(x)^4,x,%pi/6,%pi/2); (%o6) %pi/3 Remark: It does not help to avoid the usage of trigsimp in the routine samesheetsubs. I have replaced the call with the following function: (defun substtansin/cos (expr) (let (old new) (cond ((not (setq old (isinop expr '%tan))) expr) (t (let* ((arg (cadr old)) (new (div (simplify (list '(%sin) arg)) (simplify (list '(%cos) arg))))) (setq expr (maximasubstitute new old expr))) (substtansin/cos expr))))) This is the change in the function samesheetsubs: (defun samesheetsubs (exp ll ul &aux ans) (let* (;(exp (mfuncall '$trigsimp exp)) > (exp (substtansin/cos exp)) (poles (atanpoles exp ll ul))) With this replacement I always get wrong result for the integral integrate(cot(x)^4,x,%pi/6,%pi/2). This way I found that we have no problem with trigsimp, but with atanpoles. Dieter Kaiser  Comment By: Raymond Toy (rtoy) Date: 20091109 16:19 Message: Some simple tests show that just applying the rule tan(a)=sin(a)/cos(a) in samesheetsubs is enough to fix this problem. I do not know why running trigsimp itself causes problems or why, as mitreude says, changing the order of the rules in trgsmp makes it work. Especially in this case since the expression is atan(tan(x+%pi/6)).  Comment By: Raymond Toy (rtoy) Date: 20091106 17:45 Message: Just to note that trgsmp gets loaded because samesheetsubs (in defint.lisp) calls trigsimp. The whole purpose (based on the comments) is to convert tan to sin/cos. Also, on the first integrate, samesheetsubs is called just once on atan(tan(x+%pi/6)) for x=0,%pi/3, and returns 4*%pi/3. On the second integration, samesheetsubs is called twice with the same arguments and same results. Have not figured out anything more.  Comment By: mitreuden (mitreude) Date: 20091104 21:45 Message: OK, I examined the file trgsmp.mac and found that if I changed the order of simplification rules in the definition of the function trigsimp(),I can consistently get the correct answer. Here is what I did: load(trgsmp)$ defrule(trigrule1,sec(a),1/cos(a))$ defrule(trigrule2,csc(a),1/sin(a))$ defrule(trigrule3,tan(a),sin(a)/cos(a))$ defrule(trigrule4,cot(a),cos(a)/sin(a))$ defrule(htrigrule1,sech(a),1/cosh(a))$ defrule(htrigrule2,csch(a),1/sinh(a))$ defrule(htrigrule3,tanh(a),sinh(a)/cosh(a))$ defrule(htrigrule4,coth(a),cosh(a)/sinh(a))$ trigsimp(x):=trigsimp3(ratsimp(apply1(x,trigrule4,trigrule1,trigrule2,trigrule3,trigrule4, htrigrule1,htrigrule2,htrigrule3,htrigrule4)))$ integrate(cot(x)^4,x,%pi/6,%pi/2); It seems that the tangent simplification should not come first. Why this works on this particular problem, I don't have a clue. Also, might changing the simplification order cause a problem in an integral where Maxima previously found the correct answer? I have more questions than answers. Mike Treuden  Comment By: Raymond Toy (rtoy) Date: 20091104 18:01 Message: Sorry, you are correct. My working tree had a fix for Bug 2880797. Why this makes a difference, I don't know.  Comment By: Dieter Kaiser (crategus) Date: 20091103 23:21 Message: I can see this bug too with CLISP 2.44 and Maxima 5.19post on my Linux system: (%i2) integrate(cot(x)^4,x,%pi/6,%pi/2); (%o2) %pi/3 (%i3) integrate(cot(x)^4,x,%pi/6,%pi/2); (%o3) 4*%pi/3 Evaluating this integral the package trgsmp is loaded: (%i5) functions; (%o5) [trigonometricp(exp),trigsimp(x),trigsimp3(expn),trigsimp1(expn), improve(expn,subsofar,listoftrigsq),listoftrigsq(expn), specialunion(list1,list2),update(form,complement),expnlength(expr), argslength(args)] When I kill the functions defined by this package the integral is correct again: (%i6) kill(functions); (%o6) done (%i7) integrate(cot(x)^4,x,%pi/6,%pi/2); (%o7) %pi/3 And the next evaluation is wrong again: (%i8) integrate(cot(x)^4,x,%pi/6,%pi/2); (%o8) 4*%pi/3 When I preload the package trgsmp I get the error immediately: (%i11) kill(functions); (%o11) done (%i12) load(trgsmp); (%o12) "/usr/local/share/maxima/5.19post/share/trigonometry/trgsmp.mac" (%i13) integrate(cot(x)^4,x,%pi/6,%pi/2); (%o13) 4*%pi/3 Reopening the bug report. Dieter Kaiser  Comment By: Raymond Toy (rtoy) Date: 20091102 17:25 Message: Neat bug. But current cvs returns %pi/3 both times. Do not know what has changed, but it seems current CVS has fixed this issue. Marking as pending/worksforme  Comment By: mitreuden (mitreude) Date: 20091102 04:46 Message: This problem occurs with version 5.19.2 of Maxima.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2890315&group_id=4933 
From: SourceForge.net <noreply@so...>  20091112 13:13:03

Bugs item #2893299, was opened at 20091106 15:20 Message generated for change (Comment added) made by crategus You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2893299&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: Pending >Resolution: Wont Fix Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: integration of signum fails miserably Initial Comment: (%i1) plot2d(integrate(signum(x),x,2,y),[y,1,2]); Unrecoverable error: invocation history stack overflow.  >Comment By: Dieter Kaiser (crategus) Date: 20091112 14:13 Message: Yes, your are right. On my system (CLISP and Linux) the example of this bug report returns after about 1 hour without an error: (%i1) plot2d(integrate(signum(x),x,2,y),[y,1,2]); plot2d: expression evaluates to nonnumeric value somewhere in plotting range. I think we can close this bug report. Maxima returns a noun form for the integral. That is not a bug. We have a package which does the integration. Unfortunately, Maxima needs a long time to return from plot2d and perhaps runs out of memory, but the user can not expect to get a plot for noun form. Setting the status to pending and the resolution to "Wont fix". Dieter Kaiser  Comment By: Raymond Toy (rtoy) Date: 20091110 00:17 Message: It's not hung; it's just slow. With the adaptive plotter, maxima is trying very hard to refine the graph because every calculated point is not a number which makes maxima think some kind of discontinuity exists. I think this is a deficiency caused by gcl not quite supporting the needed feature to make it stop early. Perhaps the level to which the adaptive plotter divides intervals should be made smaller so fewer subdivisions are tried?  Comment By: Dieter Kaiser (crategus) Date: 20091109 22:32 Message: First, I think it is not a problem of the integration of signum. Maxima does not find the integral and returns a noun form (without abs_integrate). That is O.K., because we have the abs_integrate package. Here another example: (%i28) integrate(sin(x)*expintegral_ei(x),x,2,y); (%o28) 'integrate(expintegral_ei(x)*sin(x),x,2,y) (%i29) plot2d(%,[y,1,2]); At this point Maxima hangs on my system (Linux and CLISP). I have tried several noun forms of integrals of this type and I have got the problem that plot2d does not return. Dieter Kaiser  Comment By: Barton Willis (willisbl) Date: 20091107 00:22 Message: Workaround (%i1) load(abs_integrate)$ (%i2) plot2d(integrate(signum(x),x,2,y),[y,1,2]);  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2893299&group_id=4933 
From: SourceForge.net <noreply@so...>  20091112 10:33:16

Bugs item #2892329, was opened at 20091105 02:16 Message generated for change (Settings changed) made by crategus You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2892329&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  Plotting Group: None >Status: Pending >Resolution: Wont Fix Priority: 5 Private: No Submitted By: William Holtz (wmholtz) Assigned to: Nobody/Anonymous (nobody) Summary: Plot2d sometimes incorrect when using logscale Initial Comment: Using 5.19.2 on winXP. plot2d([1/(x+1)], [x,1e3,1e3], [logx])$ plot2d([1/(x+1)], [x,1e3,1e3], [gnuplot_preamble, "set logscale x"])$ These should give identical plots, but I the second version gives me a "knee" in the plot that is incorrect. This only happens with certain x ranges. I have attached an image of the incorrect plot. Please let me know if there is additional information I can provide  great program overall!  >Comment By: Dieter Kaiser (crategus) Date: 20091112 11:33 Message: As described in the last posting it is expected that the plots are different, because of a different sampling of points for the plot. I think this is not a bug. This can be seen when using the style points to plot the function: plot2d([1/(x+1)], [x,1e3,1e3], [style, points], [gnuplot_preamble, "set logscale x"])$ plot2d([1/(x+1)], [x,1e3,1e3], [style,points], [logx])$ Setting this bug report to pending and the resolution to "Wont Fix". Dieter Kaiser  Comment By: Raymond Toy (rtoy) Date: 20091105 02:31 Message: The issue is how maxima does plots. Basically, plots are done by uniformly sampling the x range. (Roughly). But when you want to do a log plot, the x range should be sampled logarithmically. When you specify logx, maxima knows to do the sampling correctly. That's why you get a nice smooth curve. But with the preamble, maxima doesn't know you're producing a log plot, so it does the normal sampling. That's why you see the knee. The samples selected are at 0.001 and about 0.78. (The sampling is roughly uniform, because maxima has an adaptive algorithm that will sample more if the plot is not smooth enough.)  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2892329&group_id=4933 
From: SourceForge.net <noreply@so...>  20091112 09:55:27

Bugs item #2888450, was opened at 20091029 02:21 Message generated for change (Comment added) made by crategus You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2888450&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: Rudolf Vyborny (ynrobyvr) Assigned to: Nobody/Anonymous (nobody) >Summary: limit of x*floor(1/x) as x goes to 0 Initial Comment: wrong result in calculating limit of x*floor(1/x) as x goes to 0  >Comment By: Dieter Kaiser (crategus) Date: 20091112 10:55 Message: For the record: Maxima 5.19post gives the result: (%i2) limit(x*floor(1/x),x,0); (%o2) 'limit(floor(1/x)*x,x,0) That is we get noun form. We expect the answer 1. Changing the title of this bug report to reflect the problem better and the resolution ID to none. Dieter Kaiser  Comment By: Rudolf Vyborny (ynrobyvr) Date: 20091111 03:11 Message: Answer to rtoy. The limit is 1, your proof is essentially orrect. I prefer the following proof: 1/x1<floor(1/x)<=1/x, hence for x>0 we have 1x<xfloor(1/x)<=1. It follows that the limit from the right is 1. The proof for the limit from the left is similar. Answer to crategus: The function does have a limit, namely 0. Your staement 2. is correct but your conclusion 3. is erroneous.  Comment By: Dieter Kaiser (crategus) Date: 20091109 22:11 Message: Sorry, I have no mathematical proof. I have come to the conclusion because of the follwing: 1. The function floor(x) is discontinuous. 2. The function x*floor(1/x) has an infinite number of points of discontinuity in any infinitesimal intervall when aproching zero. 3. Therefore, the function does not approach a limit. I could be wrong. Dieter Kaiser  Comment By: Raymond Toy (rtoy) Date: 20091109 18:17 Message: Isn't the limit 1? Let any x small enough, 1/x = n + e, where n is an integer and e < 1. Then floor(1/x) = n and x*floor(1/x) is n/(n+e) = 1  e/(n+e). As n gets larger (and x gets smaller), this approaches 1. Did I make a mistake?  Comment By: Dieter Kaiser (crategus) Date: 20091109 17:59 Message: With Maxima 5.19post I get a noun form too. There have been serveal changes the last time to improve limit. Furthermore, I think the limit of the example is not defined. Therefore, it seems to be not wrong to return a noun form. Setting the status to pending and works for me. Dieter Kaiser  Comment By: Rudolf Vyborny (ynrobyvr) Date: 20091029 04:02 Message: I got the wrong result, namely 0. I attached my file  Comment By: Raymond Toy (rtoy) Date: 20091029 03:12 Message: I get the noun form back. Not wrong, but could be better. What were you expecting?  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2888450&group_id=4933 