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

_{Apr}

_{May}

_{Jun}

_{Jul}

_{Aug}

_{Sep}

_{Oct}

_{Nov}

_{Dec}

S  M  T  W  T  F  S 


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

6
(2) 
7
(2) 
8
(5) 
9
(2) 
10

11

12
(1) 
13
(1) 
14
(2) 
15

16
(1) 
17

18

19

20

21
(3) 
22
(1) 
23
(2) 
24
(1) 
25

26

27
(3) 
28
(1) 
29
(2) 
30





From: SourceForge.net <noreply@so...>  20080929 11:02:53

Bugs item #2135806, was opened at 20080929 06:02 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2135806&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: Barton Willis (willisbl) Assigned to: Nobody/Anonymous (nobody) Summary: noun / verb confusion for real/imag part Initial Comment: I think (%o4) should be (conjugate(z)+z)/2: (%i4) subst(lambda([s], (s + conjugate(s))/2), 'realpart, realpart(z)); (%o4) realpart(z) For the sub to happen, we need to nounify: (%i5) subst(lambda([s], (s + conjugate(s))/2), nounify(realpart), realpart(z)); (%o5) (conjugate(z)+z)/2 For other functions (say cos), the nounify isn't needed: (%i7) subst(lambda([s], 42), 'cos, cos(x)); (%o7) 42 So, I think the nounify(realpart) shouldn't be needed in (%i5).  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2135806&group_id=4933 
From: SourceForge.net <noreply@so...>  20080929 08:39:28

Bugs item #2134791, was opened at 20080929 00:37 Message generated for change (Comment added) made by crategus You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2134791&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: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Dieter Kaiser (crategus) Assigned to: Nobody/Anonymous (nobody) Summary: Gamma ask for the sign of an expression Initial Comment: The Gamma function with an exponential as argument ask for the sign: (%i38) gamma(a^b); Is a positive or negative? p; (%o38) gamma(a^b) The question is unnecessary. The code of simpgamma tries to get the realpart and imagpart of the argument of the Gamma function too early (at the beginning of the function). We need the realpart and imagpart for numerical evaluation. For this case we have numbers and we get no questions. So, it would be better to extract the realpart and imagpart later when we know that we have numbers. Dieter Kaiser  >Comment By: Dieter Kaiser (crategus) Date: 20080929 10:39 Message: The following code first test if we have a complex number. If we know we have a complex number we extract the realpart and imagpart. With this change the function gamma(z) no longer ask unnecessary questions. Index: csimp2.lisp =================================================================== RCS file: /cvsroot/maxima/maxima/src/csimp2.lisp,v retrieving revision 1.25 diff u r1.25 csimp2.lisp  csimp2.lisp 28 Sep 2008 21:26:32 0000 1.25 +++ csimp2.lisp 28 Sep 2008 23:04:16 0000 @@ 179,9 +179,7 @@ (defmfun simpgamma (x vestigial z) (declare (ignore vestigial)) (oneargcheck x)  (let* ((j (simpcheck (cadr x) z))  (jr ($realpart j))  (ji ($imagpart j))) + (let ((j (simpcheck (cadr x) z))) (cond ((and (floatp j) (or (zerop j) (and (< j 0) @@ 194,16 +192,16 @@ (zerop1 (sub j ($truncate j)))))) (merror "gamma(~:M) is undefined." j)) (($bfloatp j) (mfuncall '$bffac (m+ j 1) $fpprec))  ((and (numberp jr)  (numberp ji)  (or $numer (floatp jr) (floatp ji)))  (complexify (gammalanczos (complex (float jr)  (float ji)))))  ((and (mnump jr)  (mnump ji)  (or $numer ($bfloatp jr) ($bfloatp ji))) + ((and (complexnumberp j) + (or $numer (floatp ($realpart j)) (floatp ($imagpart j)))) + (complexify (gammalanczos (complex (float ($realpart j)) + (float ($imagpart j)))))) + ((and (complexnumberp j 'bigfloatornumberp) + (or $numer ($bfloatp ($realpart j)) + ($bfloatp ($imagpart j)))) (mfuncall '$cbffac  (add 1 ($bfloat jr) (mul '$%i ($bfloat ji))) + (add 1 ($bfloat ($realpart j)) + (mul '$%i ($bfloat ($imagpart j)))) $fpprec)) ((and $gamma_expand (mplusp j) Success, CVS operation completed Dieter Kaiser  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2134791&group_id=4933 
From: SourceForge.net <noreply@so...>  20080928 22:37:57

Bugs item #2134791, was opened at 20080929 00:37 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2134791&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: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Dieter Kaiser (crategus) Assigned to: Nobody/Anonymous (nobody) Summary: Gamma ask for the sign of an expression Initial Comment: The Gamma function with an exponential as argument ask for the sign: (%i38) gamma(a^b); Is a positive or negative? p; (%o38) gamma(a^b) The question is unnecessary. The code of simpgamma tries to get the realpart and imagpart of the argument of the Gamma function too early (at the beginning of the function). We need the realpart and imagpart for numerical evaluation. For this case we have numbers and we get no questions. So, it would be better to extract the realpart and imagpart later when we know that we have numbers. Dieter Kaiser  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2134791&group_id=4933 
From: SourceForge.net <noreply@so...>  20080927 19:16:12

Bugs item #1093138, was opened at 20041230 08:05 Message generated for change (Comment added) made by crategus You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1093138&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: double factorial defn incorrect for noninteger operand Initial Comment: The double factorial x!! yields an incorrect result for x other than an integer. It appears that x!! is computed as the product x*(x2)*(x4)*...*y, where y is the least term (x2*k) s.t. x2*k > 1. This agrees with published defns (Arfken, Mathworld) for positive integers but not otherwise. Mathworld (http://mathworld.wolfram.com/DoubleFactorial.html) states a formula for z!!, z complex, translated into Maxima as follows  doublefact (z) := block ([a: 1+2*zcos(%pi*z), b: cos(%pi*z)1], 2^(a/4) * %pi^(b/4) * gamma(1+z/2)); It seems that Maxima could evaluate this function for noninteger arguments. Note that Maxima translates input x!! into an noun form genfact (x, x/2, 2).  >Comment By: Dieter Kaiser (crategus) Date: 20080927 21:16 Message: Change resolution to "fixed".  Comment By: Dieter Kaiser (crategus) Date: 20080927 14:30 Message: Closing this bug report. The function $genfact(x,y,z) no longer gives wrong results. A function factorial_double has been implemented. Dieter Kaiser  Comment By: Dieter Kaiser (crategus) Date: 20080922 00:17 Message: In a first step (asum.lisp, Rev. 1.30) the numerical evaluation of the function genfact(x,y,z) is specialized to integer arguments within the following range x, y, z, integer and z <= x and y <= x/z. For non valid integers a Maxima error is thrown. For all other numbers Maxima returns a noun form. With this changes Maxima no longer calculate wrong results. To get more general results for real and complex values for the Double factorial function a new function factorial_double has been suggested on the mailing list. Because Maxima no longer gets incorrect results this bug report could be closed. Dieter Kaiser  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1093138&group_id=4933 
From: SourceForge.net <noreply@so...>  20080927 12:30:37

Bugs item #1093138, was opened at 20041230 08:05 Message generated for change (Comment added) made by crategus You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1093138&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: None Priority: 3 Private: No Submitted By: Robert Dodier (robert_dodier) Assigned to: Nobody/Anonymous (nobody) Summary: double factorial defn incorrect for noninteger operand Initial Comment: The double factorial x!! yields an incorrect result for x other than an integer. It appears that x!! is computed as the product x*(x2)*(x4)*...*y, where y is the least term (x2*k) s.t. x2*k > 1. This agrees with published defns (Arfken, Mathworld) for positive integers but not otherwise. Mathworld (http://mathworld.wolfram.com/DoubleFactorial.html) states a formula for z!!, z complex, translated into Maxima as follows  doublefact (z) := block ([a: 1+2*zcos(%pi*z), b: cos(%pi*z)1], 2^(a/4) * %pi^(b/4) * gamma(1+z/2)); It seems that Maxima could evaluate this function for noninteger arguments. Note that Maxima translates input x!! into an noun form genfact (x, x/2, 2).  >Comment By: Dieter Kaiser (crategus) Date: 20080927 14:30 Message: Closing this bug report. The function $genfact(x,y,z) no longer gives wrong results. A function factorial_double has been implemented. Dieter Kaiser  Comment By: Dieter Kaiser (crategus) Date: 20080922 00:17 Message: In a first step (asum.lisp, Rev. 1.30) the numerical evaluation of the function genfact(x,y,z) is specialized to integer arguments within the following range x, y, z, integer and z <= x and y <= x/z. For non valid integers a Maxima error is thrown. For all other numbers Maxima returns a noun form. With this changes Maxima no longer calculate wrong results. To get more general results for real and complex values for the Double factorial function a new function factorial_double has been suggested on the mailing list. Because Maxima no longer gets incorrect results this bug report could be closed. Dieter Kaiser  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1093138&group_id=4933 
From: SourceForge.net <noreply@so...>  20080927 12:27:41

Bugs item #1486452, was opened at 20060511 14:09 Message generated for change (Comment added) made by crategus You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1486452&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: None Status: Open Resolution: None Priority: 3 Private: No Submitted By: Barton Willis (willisbl) Assigned to: Nobody/Anonymous (nobody) Summary: minfactorial doesn't look inside "!" Initial Comment: The minfactorial function doesn't look inside the factorial function. So it misses some simplifications that it could do: (%i1) (n!/(n1)!)!; (%o1) (n!/(n1)!)! (%i2) minfactorial(%); (%o2) (n!/(n1)!)! < could be n! (%i3) build_info(); Maxima version: 5.9.3 Maxima build date: 0:52 3/20/2006 host type: i686pcmingw32 lispimplementationtype: GNU Common Lisp (GCL) lispimplementationversion: GCL 2.6.7 Barton  >Comment By: Dieter Kaiser (crategus) Date: 20080927 14:27 Message: When we implement the simplification of expressions like factorial(n+m) and factorial (nm) with integer m, the factorials simplifies immediatly. The simplification depends on the Maxima User flag $factoriol_expand. This could be the implementation of the expansion: ((and $factorial_expand (mplusp y) (integerp (cadr y))) ;; factorial(z+m) and m integer. Expand. (let ((m (cadr y)) (n (simplify (cons '(mplus) (cddr y))))) (cond ((>= m 0) (mul (simplify (list '($pochhammer) (add n 1) m)) (simplify (list '(mfactorial) n)))) ((< m 0) (setq m ( m)) (div (mul (power 1 m) (simplify (list '(mfactorial) n))) (simplify (list '($pochhammer) (mul 1 n) m))))))) This is the result without simplification and minfactorial: (%i15) (n!/(n1)!)!; (%o15) (n!/(n1)!)! (%i16) minfactorial(%); (%o16) (n!/(n1)!)! Now we set the flag to expand the Factorials: (%i18) factorial_expand:true$ (%i20) factorial(n+2); (%o20) (n+1)*(n+2)*n! (%i21) factorial(n2); (%o21) n!/((1n)*n) The epression of this bug report simplifies: (%i22) (n!/(n1)!)!; (%o22) n! Because the simplification is done by the simplifier we have no problems with nested expressions. This mechanism of simplification has already be implemented for Double factorial, the Gamma function and the Incomplete Gamma function. Dieter Kaiser  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1486452&group_id=4933 
From: SourceForge.net <noreply@so...>  20080924 00:05:26

Bugs item #2125317, was opened at 20080923 18:30 Message generated for change (Comment added) made by rtoy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2125317&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: Xmaxima or other UI Group: None >Status: Pending >Resolution: Invalid Priority: 5 Private: No Submitted By: Lindsay Dunseith (dunseith) Assigned to: Nobody/Anonymous (nobody) Summary: Multiplication of matrices Initial Comment: For the matrix " matrix M =([m,0],[0,m]), the power M^n is determined correctly. However, for other matrices, e.g. P =([3,1],[1,3])Maxima determines P^2 as matrix([9,1],[1,9]), instead of the correct: matrix([10,6],[6,10]) I haven't tried multiplying more general matrices, but does this mean there is a problem with matrix multiplication? Maxima build as follows: Maxima version: 5.15.0 Maxima build date: 17:36 4/20/2008 host type: i686pcmingw32 lispimplementationtype: GNU Common Lisp (GCL) lispimplementationversion: GCL 2.6.8  >Comment By: Raymond Toy (rtoy) Date: 20080923 20:05 Message: Please be more explicit and show exactly what you did. However, I suspect you used * to multiply matrices. This is an elementbyelement multiply. The matrix multiply operator is ".". So: p:matrix([3,1],[1,3]); p . p; matrix([10,6],[6,10]) Marking as pending/invalid.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2125317&group_id=4933 
From: SourceForge.net <noreply@so...>  20080923 22:30:19

Bugs item #2125317, was opened at 20080924 00:30 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2125317&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: Xmaxima or other UI Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Lindsay Dunseith (dunseith) Assigned to: Nobody/Anonymous (nobody) Summary: Multiplication of matrices Initial Comment: For the matrix " matrix M =([m,0],[0,m]), the power M^n is determined correctly. However, for other matrices, e.g. P =([3,1],[1,3])Maxima determines P^2 as matrix([9,1],[1,9]), instead of the correct: matrix([10,6],[6,10]) I haven't tried multiplying more general matrices, but does this mean there is a problem with matrix multiplication? Maxima build as follows: Maxima version: 5.15.0 Maxima build date: 17:36 4/20/2008 host type: i686pcmingw32 lispimplementationtype: GNU Common Lisp (GCL) lispimplementationversion: GCL 2.6.8  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2125317&group_id=4933 
From: SourceForge.net <noreply@so...>  20080923 00:01:20

Bugs item #1175458, was opened at 20050402 11:10 Message generated for change (Comment added) made by robert_dodier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1175458&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: describe confused by @defun longer than 1 line Initial Comment: describe is confused by a @defun (let's say it has lots of arguments or the arguments have long names) which yields a function definition longer than one line (80 characters or so). What happens is that all the text after the long function definition is lost. This behavior isn't shown by any existing texinfo description item, since the @defuns which trigger it have been commented out. That is just a workaround, however, and src/clinfo.lisp should be fixed so long @defuns aren't a problem.  >Comment By: Robert Dodier (robert_dodier) Date: 20080922 18:01 Message: Fixed by describe system revision a couple of years ago. Closing this report.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1175458&group_id=4933 
From: SourceForge.net <noreply@so...>  20080922 23:54:26

Bugs item #2123651, was opened at 20080922 19:54 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2123651&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  Complex Group: Includes proposed fix Status: Open Resolution: None Priority: 5 Private: No Submitted By: The Henman (rvh2007) Assigned to: Nobody/Anonymous (nobody) Summary: min and max of imaginary and real numbers Initial Comment: There was a discussion about an infinity correct Maxima, was the issue resolved? Anyway I also found this problem with Max and Min. When comparing imaginary and real inf I think returning the noun form is the only right answer. I think the same is true for complex numbers and max and min usually work but I see one case below where you get an error message. If you do this min(a+b*i, a+b*i) or max(a+b*i, a+b*i) then you should get a+b*i even if a and b are +inf. I think these are all wrong, except for %o14 (%i5) min(%i*inf,inf); (%o5) %i inf (%i6) min(%i*minf,minf); (%o6) minf (%i7) (%i5) min(%i*inf,inf); (%o5) %i inf (%i6) min(%i*minf,minf); (%o6) minf (%i7) min(%i*inf,inf); (%o7) minf (%i8) min(%i*inf,minf); (%o8) minf (%i9) min(%i*minf,inf); (%o9) minf (%i10) max(%i*minf,inf); (%o10) inf (%i11) max(%i*minf,minf); (%o11) %i minf (%i12) max(%i*inf,inf); (%o12) inf (%i13) min(%i*inf,inf); (%o13) %i inf (%i14) max(%i*inf,inf); (%o14) max( inf,  %i inf) (%i15) max(%i*minf,minf); (%o15) %i minf The noun form is returned in only one case that I have found above. For complex number there is also this min bug in (%i4). (%i1) max(7*%i*inf+4*inf,4*%i*inf+3); (%o1) max(4 %i inf + 3, 7 %i inf + 4 inf) (%i2) min(7*%i*inf+4*inf,4*%i*inf+3); (%o2) min(7 %i inf + 4 inf, 4 %i inf + 3) (%i3) min(7*%i*minf+4*inf,4*%i*minf+3); (%o3) min(7 %i minf + 4 inf, 4 %i minf + 3) (%i4) min(7*%i*minf+4*inf,4*%i*inf+3); The sign of und is undefined  an error. To debug this try debugmode(true); There is one other with real infinity. Try (%i5) min(inf,minf); (%o5) inf (%i6) max(inf,minf); The sign of und is undefined  an error. To debug this try debugmode(true) These last two shoud not return and noun form but %i6 should not give an error either. In my humble opinion. Rich (%i1) build_info()$ Maxima version: 5.16.3 Maxima build date: 22:48 8/24/2008 host type: i686pcmingw32lispimplementationtype: GNU Common Lisp (GCL)lispimplementationversion: GCL 2.6.8  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2123651&group_id=4933 
From: SourceForge.net <noreply@so...>  20080921 22:28:36

Bugs item #2013668, was opened at 20080708 19:32 Message generated for change (Comment added) made by crategus You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2013668&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  Floating point Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: floor/ceiling(NaN) => finite number Initial Comment: floor(gamma(250.0)) => an integer near 2*10^308 (floatmax). But gamma(250.0) is returning a NaN, so floor should give an error. Of course it shouldn't, but it's better if other code would be NaNproof. GCL's floor function is the culprit (the CL spec seems to be silent on NaN behavior, though you'd think that (floor NaN) should be an error). simpfloor and company should check explicitly for NaNs. This is easier said than done, since in GCL (= (gammalanczos 250.0) (gammalanczos 260.0)) => t, but NaNs are supposed to compare nonequal to themselves.... What's a reliable test for NaN/inf in GCL? Maxima 5.14.0 GCL Windows  >Comment By: Dieter Kaiser (crategus) Date: 20080922 00:28 Message: gammalanczos no longer returns a float value beyond extreme values (csimp2.lisp, Rev. 1.22). Maxima signals an overflow error. Therefore Maxima no longer calculate a wrong result for floor(gamma(250.0)) too. I think for this special example the bug report could be closed. Dieter Kaiser  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2013668&group_id=4933 
From: SourceForge.net <noreply@so...>  20080921 22:21:22

Bugs item #2013650, was opened at 20080708 19:01 Message generated for change (Comment added) made by crategus You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2013650&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  Floating point Group: None >Status: Closed Resolution: None Priority: 5 Private: No Submitted By: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: gamma(250.0) returns nonnumber; gamma(1.0) finite Initial Comment: gamma(250.0) and 250.0! return nonnumbers. This causes an error in printing ("Can't print a nonnumber"). It should cause a clean overflow error. The problem is in gammalanczos, which doesn't check that its return value is welldefined (not infinite, not a NaN) before returning it. gammalanczos also does not report an error for negative integer arguments: gamma(1.0) => 2.6e+16 Worse, bfloat(gamma(250.0)) returns a grossly incorrect result  see next error report. Tested on Maxima 5.14.0 GCL Windows  >Comment By: Dieter Kaiser (crategus) Date: 20080922 00:21 Message: Closing this bug report. There have been no problems reported to the changes in csimp2.lisp (Rev. 1.22). Dieter Kaiser  Comment By: Dieter Kaiser (crategus) Date: 20080914 18:52 Message: After adding code to simpgamma and gammalanczos Maxima get the following results: (%i3) gamma(250.0); Overflow in `gammalanczos'.  an error. To debug this try debugmode(true); (%i4) 250.0!; Overflow in `gammalanczos'.  an error. To debug this try debugmode(true); (%i5) gamma(1.0); gamma(1.0) is undefined.  an error. To debug this try debugmode(true); (%i6) gamma(1.0b0); gamma(1.0b0) is undefined.  an error. To debug this try debugmode(true); (%i7) bfloat(gamma(250.0)); Overflow in `gammalanczos'.  an error. To debug this try debugmode(true); For negative integers the result infinity would be nicer, but Maxima can not do calculations with infinities. Because we get a Maxima Error for negative integers, it is the best to give a Maxima Error for the float and bigfloat representations of a negative integer too. For GCL 2.6.8 and CLISP 2.46 gammalanzcos will detected an overflow for values greater than about 171.6243. When the tests will not give new problems with other compilers, we could close the bug report. Dieter Kaiser  Comment By: Stavros Macrakis (macrakis) Date: 20080717 15:51 Message: Logged In: YES user_id=588346 Originator: YES As long as we don't have a welldefined policy for Maxima's handling of IEEE infs and NaNs, it is a bug for any routine to return an IEEE inf or NaN. When/if we define the behavior and update the code to work correctly in the presence of inf/NaN, then it will be fine.  Comment By: Robert Dodier (robert_dodier) Date: 20080712 05:41 Message: Logged In: YES user_id=501686 Originator: NO I 'm not convinced the problem is in GAMMALANCZOS. If the Lisp implementation permits infinity and NaN as floating point results, then Maxima functions could just pass those along. The only bug that I see here for sure is that GCL cannot display NaN and infinity (although such values can be computed by GCL). For the sake of uniform behavior, I suppose Maxima functions could reject NaN and infinity, no matter which Lisp, or allow them. Probably it is easier to reject NaN and infinity. I'm undecided at this point about having a uniform policy wrt floating point special values, or letting it remain an implementationdependent feature.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2013650&group_id=4933 
From: SourceForge.net <noreply@so...>  20080921 22:17:58

Bugs item #1093138, was opened at 20041230 08:05 Message generated for change (Comment added) made by crategus You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1093138&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: 3 Private: No Submitted By: Robert Dodier (robert_dodier) Assigned to: Nobody/Anonymous (nobody) Summary: double factorial defn incorrect for noninteger operand Initial Comment: The double factorial x!! yields an incorrect result for x other than an integer. It appears that x!! is computed as the product x*(x2)*(x4)*...*y, where y is the least term (x2*k) s.t. x2*k > 1. This agrees with published defns (Arfken, Mathworld) for positive integers but not otherwise. Mathworld (http://mathworld.wolfram.com/DoubleFactorial.html) states a formula for z!!, z complex, translated into Maxima as follows  doublefact (z) := block ([a: 1+2*zcos(%pi*z), b: cos(%pi*z)1], 2^(a/4) * %pi^(b/4) * gamma(1+z/2)); It seems that Maxima could evaluate this function for noninteger arguments. Note that Maxima translates input x!! into an noun form genfact (x, x/2, 2).  >Comment By: Dieter Kaiser (crategus) Date: 20080922 00:17 Message: In a first step (asum.lisp, Rev. 1.30) the numerical evaluation of the function genfact(x,y,z) is specialized to integer arguments within the following range x, y, z, integer and z <= x and y <= x/z. For non valid integers a Maxima error is thrown. For all other numbers Maxima returns a noun form. With this changes Maxima no longer calculate wrong results. To get more general results for real and complex values for the Double factorial function a new function factorial_double has been suggested on the mailing list. Because Maxima no longer gets incorrect results this bug report could be closed. Dieter Kaiser  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1093138&group_id=4933 
From: SourceForge.net <noreply@so...>  20080916 01:48:59

Bugs item #2113751, was opened at 20080916 17:48 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2113751&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: Satoshi Adachi (satoshi_adachi) Assigned to: Nobody/Anonymous (nobody) Summary: Incomprehensible behavior of coeff(). Initial Comment: Dear Developers of Maxima, I met an incomprehensible behavior of coeff(). This is an example program for demonstration:  /* * incomprehensible_behavior_of_coeff.maxima: * * S.Adachi 2008/09/13 */ display2d:false; comprehensible_1_0:coeff(%e^x, x, 0); INCOMPREHENSIBLE_2_0:coeff(2*%e^x, x, 0); INCOMPREHENSIBLE_3_0:coeff(3*%e^x, x, 0); comprehensible_1_1:coeff(x*%e^x, x, 1); comprehensible_2_1:coeff(2*x*%e^x, x, 1); comprehensible_3_1:coeff(3*x*%e^x, x, 1); comprehensible_1_2:coeff(x^2*%e^x, x, 2); comprehensible_2_2:coeff(2*x^2*%e^x, x, 2); comprehensible_3_2:coeff(3*x^2*%e^x, x, 2); /* END */  The result of execution is as follows:  Maxima 5.14.0cvs http://maxima.sourceforge.net Using Lisp GNU Common Lisp (GCL) GCL 2.6.7 (aka GCL) 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) batch(incomprehensible_behavihor_of_coeff.maxima) batching #p/Volumes/HFS+2/home/adachi/work/306/incomprehensible_behavihor_of_coeff.maxima (%i2) display2d : false (%o2) false (%i3) comprehensible_1_0:coeff(%e^x,x,0) (%o3) %e^x (%i4) INCOMPREHENSIBLE_2_0:coeff(2*%e^x,x,0) (%o4) 0 (%i5) INCOMPREHENSIBLE_3_0:coeff(3*%e^x,x,0) (%o5) 0 (%i6) comprehensible_1_1:coeff(x*%e^x,x,1) (%o6) %e^x (%i7) comprehensible_2_1:coeff(2*x*%e^x,x,1) (%o7) 2*%e^x (%i8) comprehensible_3_1:coeff(3*x*%e^x,x,1) (%o8) 3*%e^x (%i9) comprehensible_1_2:coeff(x^2*%e^x,x,2) (%o9) %e^x (%i10) comprehensible_2_2:coeff(2*x^2*%e^x,x,2) (%o10) 2*%e^x (%i11) comprehensible_3_2:coeff(3*x^2*%e^x,x,2) (%o11) 3*%e^x (%o12) "incomprehensible_behavihor_of_coeff.maxima"  By seeing the results at other lines, I expect that coeff(2*%e^x,x,0) is calculated to be 2*%e^x and coeff(3*%e^x,x,0) is calculated to be 3*%e^x. However, they are not in actuality. This phenomenon may be a bug of coeff(). Or it may be a part of ``specification'' of coeff(). I cannot judge which is the case. If someone can access some old version of Maxima, which is old enough, he or she can run the above example program by using the old Maxima to get the result by that version of Maxima to compare the result with my result. This may help to judge whether this phenomenon is a bug or a part of specification of coeff(). If this phenomenon is a bug of coeff(), plase fix it. Since this phenomenon of coeff() exists, I had to put an ugly fragment of code in my Maxima program for the workaround. Sincerely yours, Satoshi Adachi  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2113751&group_id=4933 
From: SourceForge.net <noreply@so...>  20080914 17:17:31

Bugs item #1571099, was opened at 20061005 05:51 Message generated for change (Comment added) made by crategus You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1571099&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: Julien B. O. (jul059) Assigned to: Nobody/Anonymous (nobody) Summary: handling of large factorials Initial Comment: evaluation of large factorials, such as 143311! leads to a value stack overflow when evaluated in wxMaxima 0.7.0a, but not in the command line version of maxima: Maxima encountered a Lisp error: Error in FORMAT [or a callee]: Value stack overflow.Automatically continuing.To reenable the Lisp debugger set *debuggerhook* to nil. The error is explicit enough to understand it is an overflow... but when trying to evaluate even larger factorials, such as 1433115!, windows simply reports a standard program failure with no message from maxima regardless of the interface you use. version used: Maxima version: 5.10.0 Maxima build date: 19:9 9/21/2006 host type: i686pcmingw32 lispimplementationtype: GNU Common Lisp (GCL) lispimplementationversion: GCL 2.6.7 also using Windows XP profesionnal with SP2.  >Comment By: Dieter Kaiser (crategus) Date: 20080914 19:17 Message: As desribed on the mailing list we get unpredictable errors for integers greater than about 100,000 at least for GCL 2.6.8 and CLISP 2.46. We get system hangs, killed sessions, output with random chars,... A semiliar problem we get for half integral values. The calculation is done if the argument is less then $gammalim which has a default value of 1,000,000. This value is far too big. A value of 100,000 for $gammalim might work for most (all?) systems. Perhaps it is even better to choose a much smaller value like 1,000 or 10,000. To prevent the Maxima User to unintentional produce such errors I would like to suggest the following changes: 1. Set $factlim to a default value of 100,000. (GCL 2.6.0 and CLISP works on the console  evaluating and printing,wxmaxima get a result but can not print it  value stack overflow) Perhaps much smaller. A value of 10,000 might be very sure. 2. In simpgamma test against $factlim (not $gammalim) before calling simpfact. So $gammalim and $factlim are independend. 3. Set the default value of $gammalim to 10,000. Perhaps 1,000. A user who has a more powerful compiler or system could extend the range by setting new values to $factlim and $gammalim. But he has to be warned in the documentation that Maxima could fail. Dieter Kaiser  Comment By: Julien B. O. (jul059) Date: 20070712 04:27 Message: Logged In: YES user_id=1610192 Originator: YES I have done some new testing and maxima can indeed compute 143311!$ with the config described above (regardless of the interface). It can also display if it is computed first with a:143311!$ and then displayed with a;. this does works in the console and xMaxima, but not in wxMaxima. The latter gives a stack overflow. But please note than the display is MUCH longer than the actual calculation (about 30x40x). Also, a2 can compute with 1433115!$ (about 14s) but maxima crashes on display (the standard windows failure thing). The behaviour is slightly different from what robert_dodier reported in (2).  Comment By: Robert Dodier (robert_dodier) Date: 20061021 20:38 Message: Logged In: YES user_id=501686 Interesting problem. If I had to guess I would say that GCL is not verifying whether some memory allocation has succeeded. Some additional data. (1) With Maxima 5.10.0cvs + GCL 2.6.7 + Linux, computations of a:143311!$ succeeds (3 s) and a2:1433115$ succeeds (76 s). Note that display of a and a2 is suppressed by $. (2) (Again with GCL 2.6.7) Display of a and a2 fails, however. a; yields (after a short delay) some garbage (spaces and backslashes observed on some occasions and random characters on another) and a2; causes a segfault. (3) Maxima 5.10.0 + clisp 2.38 + Linux: 143311!; yields "overflow during multiplication of large numbers". (4) Maxima 5.10.0cvs + sbcl 0.9.16: a:143311!$ takes about 100 s, and a2:1433115!$ didn't terminate within an hour. Display a; seems to take longer than I'm willing to wait.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1571099&group_id=4933 
From: SourceForge.net <noreply@so...>  20080914 16:52:30

Bugs item #2013650, was opened at 20080708 19:01 Message generated for change (Comment added) made by crategus You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2013650&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  Floating point Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: gamma(250.0) returns nonnumber; gamma(1.0) finite Initial Comment: gamma(250.0) and 250.0! return nonnumbers. This causes an error in printing ("Can't print a nonnumber"). It should cause a clean overflow error. The problem is in gammalanczos, which doesn't check that its return value is welldefined (not infinite, not a NaN) before returning it. gammalanczos also does not report an error for negative integer arguments: gamma(1.0) => 2.6e+16 Worse, bfloat(gamma(250.0)) returns a grossly incorrect result  see next error report. Tested on Maxima 5.14.0 GCL Windows  >Comment By: Dieter Kaiser (crategus) Date: 20080914 18:52 Message: After adding code to simpgamma and gammalanczos Maxima get the following results: (%i3) gamma(250.0); Overflow in `gammalanczos'.  an error. To debug this try debugmode(true); (%i4) 250.0!; Overflow in `gammalanczos'.  an error. To debug this try debugmode(true); (%i5) gamma(1.0); gamma(1.0) is undefined.  an error. To debug this try debugmode(true); (%i6) gamma(1.0b0); gamma(1.0b0) is undefined.  an error. To debug this try debugmode(true); (%i7) bfloat(gamma(250.0)); Overflow in `gammalanczos'.  an error. To debug this try debugmode(true); For negative integers the result infinity would be nicer, but Maxima can not do calculations with infinities. Because we get a Maxima Error for negative integers, it is the best to give a Maxima Error for the float and bigfloat representations of a negative integer too. For GCL 2.6.8 and CLISP 2.46 gammalanzcos will detected an overflow for values greater than about 171.6243. When the tests will not give new problems with other compilers, we could close the bug report. Dieter Kaiser  Comment By: Stavros Macrakis (macrakis) Date: 20080717 15:51 Message: Logged In: YES user_id=588346 Originator: YES As long as we don't have a welldefined policy for Maxima's handling of IEEE infs and NaNs, it is a bug for any routine to return an IEEE inf or NaN. When/if we define the behavior and update the code to work correctly in the presence of inf/NaN, then it will be fine.  Comment By: Robert Dodier (robert_dodier) Date: 20080712 05:41 Message: Logged In: YES user_id=501686 Originator: NO I 'm not convinced the problem is in GAMMALANCZOS. If the Lisp implementation permits infinity and NaN as floating point results, then Maxima functions could just pass those along. The only bug that I see here for sure is that GCL cannot display NaN and infinity (although such values can be computed by GCL). For the sake of uniform behavior, I suppose Maxima functions could reject NaN and infinity, no matter which Lisp, or allow them. Probably it is easier to reject NaN and infinity. I'm undecided at this point about having a uniform policy wrt floating point special values, or letting it remain an implementationdependent feature.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2013650&group_id=4933 
From: SourceForge.net <noreply@so...>  20080913 02:35:08

Bugs item #2108205, was opened at 20080912 19:41 Message generated for change (Comment added) made by rtoy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2108205&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: Pending >Resolution: Rejected Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: sin(10^22), numer; returns wrong value Initial Comment: sin(10^22),numer; results in 0.41214336710708. The correct value is apparently 0.8522008497671888017727... according to p.176 of Elementary functions : algorithms and implementation / JeanMichel Muller.2nd ed. ISBN 0817643729  >Comment By: Raymond Toy (rtoy) Date: 20080912 22:35 Message: This is an issue with the underlying Lisp used to build maxima. Cmucl and ecl return the correct value. clisp returns 0.0. I'm guessing you're using gcl. You should request your lisp vendor to fix this or use a different lisp. Marking this as pending/rejected. If you (or someone else) disagrees, please comment.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2108205&group_id=4933 
From: SourceForge.net <noreply@so...>  20080912 23:41:54

Bugs item #2108205, was opened at 20080912 23:41 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2108205&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: Open Resolution: None Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: sin(10^22), numer; returns wrong value Initial Comment: sin(10^22),numer; results in 0.41214336710708. The correct value is apparently 0.8522008497671888017727... according to p.176 of Elementary functions : algorithms and implementation / JeanMichel Muller.2nd ed. ISBN 0817643729  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2108205&group_id=4933 
From: SourceForge.net <noreply@so...>  20080909 13:21:12

Bugs item #1374700, was opened at 20051206 13:41 Message generated for change (Comment added) made by rtoy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1374700&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: Rejected Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: integrate((1+tan(x)^2)/tan(x),x); Initial Comment: Nonreal result  >Comment By: Raymond Toy (rtoy) Date: 20080909 09:21 Message: Yes, I found that. I guess every one is in agreement that log(sin(x)^21) is ok. So, I'll close this bug report.  Comment By: Dan Gildea (dgildea) Date: 20080908 10:02 Message: Logged In: YES user_id=1797506 Originator: NO The variable b was changed to *b* in sin.lisp rev 1.19.  Comment By: Raymond Toy (rtoy) Date: 20080908 09:30 Message: Logged In: YES user_id=28849 Originator: NO Yes, you are right. Still, for real values of x, it is a bit surprising to see maxima give a complex result in log(sin(x)^21)/2, but of course once you substitute actual integral limits, the complex part goes away. But we should fix the b vs bb issue in schatc.lisp in any case. Or at least make sure b is not special in schatc. Or change b to *b* in sin.lisp. Or something.  Comment By: Dan Gildea (dgildea) Date: 20080903 20:43 Message: Logged In: YES user_id=1797506 Originator: NO Is this really a bug? log(sin(x))  log(sin(x)^21)/2 seems to differ from log(tan(x)) by a constant within each sheet. log(tan(x)) is also complex in general.  Comment By: Raymond Toy (rtoy) Date: 20060831 19:46 Message: Logged In: YES user_id=28849 Yes, replacing all occurrences of b in schatc.lisp with bb makes clisp behave like cmucl. But we can see now how to get log(tan(x)) as the answer. We can move case 5 before case 4. Not exactly sure what impact that will have on the algorithm.  Comment By: Raymond Toy (rtoy) Date: 20060831 19:41 Message: Logged In: YES user_id=28849 FWIW, maxima uses trigint to do this integral, and when it gets to case 4, it tries to match the integrand. With cmucl, it matches, but with clisp it doesn't. In rat1, b is NIL in clisp, but is 'cos* in cmucl. b is declared special, and is set to 'cos* in case 4, just before the call to m2, which calls rat1. But note that coeffpt in schatc.lisp also uses the variable b. There is probably some confusion with b here. I am guessing the b in coeffpt is not the global special variablle b in sin.lisp.  Comment By: Raymond Toy (rtoy) Date: 20060831 16:40 Message: Logged In: YES user_id=28849 Maxima 5.9.3.99rc2 and cmucl 200609 says log(sin(x))  log(sin(x)^21)/2 But the same maxima with clisp 2.35 says log(tan(x)). I don't know why.  Comment By: Robert Dodier (robert_dodier) Date: 20060814 22:46 Message: Logged In: YES user_id=501686 Maxima 5.9.3.99rc1 / Clisp 2.38: integrate((1+tan(x)^2)/tan(x),x); => log(tan(x)) which seems right. Maybe if someone else wants to weigh in here. If someone else agrees this result is OK, we can close this report.  Comment By: Raymond Toy (rtoy) Date: 20060213 13:07 Message: Logged In: YES user_id=28849 This integral is transformed to cos(x)/sin(x)*(sin(x)^2/cos(x)^2+1). Then maxima uses the substitution y=sin(x) to get 1/y*(y^2/(1y^2)+1. However: integrate(1/y*(y^2/(1y^2)+1),y) > log(y)log(y^21)/2. But integrate(expand(1/y*(y^2/(1y^2)+1)),y) > log(y)log(1y^2)/2. The former is wrong for our integration problem; the latter would produce the desired answer.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1374700&group_id=4933 
From: SourceForge.net <noreply@so...>  20080909 04:37:17

Bugs item #2099542, was opened at 20080907 22:07 Message generated for change (Comment added) made by robert_dodier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2099542&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: None >Status: Closed >Resolution: Works For Me Priority: 5 Private: No Submitted By: Jack O'Connor (oconnor663) Assigned to: Nobody/Anonymous (nobody) Summary: Common sum simplification unsuccessful Initial Comment: The following sum fails to simplify: sum( n / 2^n, n, 1, inf), simpsum; Presumably the answer should be 2, but instead Maxima just returns the sum in sigma notation.  >Comment By: Robert Dodier (robert_dodier) Date: 20080908 22:37 Message: simplify_sum applies simpsum and some more powerful methods (Gosper and Zeilberger and some others if I remember correctly). Anyway simplify_sum does know how to do this problem. load (simplify_sum); simplify_sum (sum( n / 2^n, n, 1, inf)); => 2 Closing this report.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2099542&group_id=4933 
From: SourceForge.net <noreply@so...>  20080908 14:08:23

Bugs item #635606, was opened at 20021108 12:47 Message generated for change (Comment added) made by dgildea You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=635606&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  Limit Group: None >Status: Pending >Resolution: Fixed Priority: 5 Private: No Submitted By: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: limit(abs(log(x))) internal error, UND Initial Comment: Maxima 5.5/Windows/gcl limit(abs(log(x)),x,0) Error: The tag LIMIT is undefined. Should of course be INF. More controversially, perhaps, limit(log(x),x,0) gives UND  I believe it should give INFINITY; after all, limit(log (x),x,0,minus) gives INFINITY.  >Comment By: Dan Gildea (dgildea) Date: 20080908 10:08 Message: Logged In: YES user_id=1797506 Originator: NO As of limit.lisp rev 1.56: (%i6) limit(log(x), x, 0, minus); (%o6) minf+%i*%pi (%i7) limit(log(x), x, 0, plus); (%o7) minf (%i8) limit(abs(log(x)), x, 0, minus); (%o8) inf (%i9) limit(abs(log(x)), x, 0, plus); (%o9) inf (%i10) limit(abs(log(x)), x, 0); (%o10) inf (%i11) limit(1/x, x, 0, minus); (%o11) minf (%i12) limit(1/x, x, 0, plus); (%o12) inf (%i13) limit(1/x, x, 0); (%o13) infinity  Comment By: Stavros Macrakis (macrakis) Date: 20061109 18:45 Message: Logged In: YES user_id=588346 re limit(abs(log(x)),x,0) If we're working over real x and the complex log function, then if x>0, it should clearly be inf. If x<0, log(x) is not real, but abs(log(x)) is, and sure enough limit(abs(log(x)),x,0,minus) gives inf. This is I believe correct. And it's all consistent with limit(abs(log(x)),x,0) => inf. If on the other hand you take the position that limit operates on real functions, then negative x are not part of the domain of log(x), so we should look only at the limit for x>0, which also gives us the result inf. But limit is actually happy to return imaginary results, e.g. limit(sqrt(x),x,1) => %i. By the way, currently, limit(log(x),x,0,minus) gives minf+%i*%pi, which makes some sort of intuitive sense, but isn't really a valid expression  it should be infinity.  Comment By: Raymond Toy (rtoy) Date: 20061108 21:49 Message: Logged In: YES user_id=28849 The error no longer occurs in current CVS. It returns UND, after asking if x is positive or negative. Why should the answer be INF? log(x) is undefined for negative real x.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=635606&group_id=4933 
From: SourceForge.net <noreply@so...>  20080908 14:02:35

Bugs item #1374700, was opened at 20051206 13:41 Message generated for change (Comment added) made by dgildea You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1374700&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: Rejected Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: integrate((1+tan(x)^2)/tan(x),x); Initial Comment: Nonreal result  Comment By: Dan Gildea (dgildea) Date: 20080908 10:02 Message: Logged In: YES user_id=1797506 Originator: NO The variable b was changed to *b* in sin.lisp rev 1.19.  Comment By: Raymond Toy (rtoy) Date: 20080908 09:30 Message: Logged In: YES user_id=28849 Originator: NO Yes, you are right. Still, for real values of x, it is a bit surprising to see maxima give a complex result in log(sin(x)^21)/2, but of course once you substitute actual integral limits, the complex part goes away. But we should fix the b vs bb issue in schatc.lisp in any case. Or at least make sure b is not special in schatc. Or change b to *b* in sin.lisp. Or something.  Comment By: Dan Gildea (dgildea) Date: 20080903 20:43 Message: Logged In: YES user_id=1797506 Originator: NO Is this really a bug? log(sin(x))  log(sin(x)^21)/2 seems to differ from log(tan(x)) by a constant within each sheet. log(tan(x)) is also complex in general.  Comment By: Raymond Toy (rtoy) Date: 20060831 19:46 Message: Logged In: YES user_id=28849 Yes, replacing all occurrences of b in schatc.lisp with bb makes clisp behave like cmucl. But we can see now how to get log(tan(x)) as the answer. We can move case 5 before case 4. Not exactly sure what impact that will have on the algorithm.  Comment By: Raymond Toy (rtoy) Date: 20060831 19:41 Message: Logged In: YES user_id=28849 FWIW, maxima uses trigint to do this integral, and when it gets to case 4, it tries to match the integrand. With cmucl, it matches, but with clisp it doesn't. In rat1, b is NIL in clisp, but is 'cos* in cmucl. b is declared special, and is set to 'cos* in case 4, just before the call to m2, which calls rat1. But note that coeffpt in schatc.lisp also uses the variable b. There is probably some confusion with b here. I am guessing the b in coeffpt is not the global special variablle b in sin.lisp.  Comment By: Raymond Toy (rtoy) Date: 20060831 16:40 Message: Logged In: YES user_id=28849 Maxima 5.9.3.99rc2 and cmucl 200609 says log(sin(x))  log(sin(x)^21)/2 But the same maxima with clisp 2.35 says log(tan(x)). I don't know why.  Comment By: Robert Dodier (robert_dodier) Date: 20060814 22:46 Message: Logged In: YES user_id=501686 Maxima 5.9.3.99rc1 / Clisp 2.38: integrate((1+tan(x)^2)/tan(x),x); => log(tan(x)) which seems right. Maybe if someone else wants to weigh in here. If someone else agrees this result is OK, we can close this report.  Comment By: Raymond Toy (rtoy) Date: 20060213 13:07 Message: Logged In: YES user_id=28849 This integral is transformed to cos(x)/sin(x)*(sin(x)^2/cos(x)^2+1). Then maxima uses the substitution y=sin(x) to get 1/y*(y^2/(1y^2)+1. However: integrate(1/y*(y^2/(1y^2)+1),y) > log(y)log(y^21)/2. But integrate(expand(1/y*(y^2/(1y^2)+1)),y) > log(y)log(1y^2)/2. The former is wrong for our integration problem; the latter would produce the desired answer.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1374700&group_id=4933 
From: SourceForge.net <noreply@so...>  20080908 13:30:48

Bugs item #1374700, was opened at 20051206 13:41 Message generated for change (Comment added) made by rtoy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1374700&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: Rejected Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: integrate((1+tan(x)^2)/tan(x),x); Initial Comment: Nonreal result  >Comment By: Raymond Toy (rtoy) Date: 20080908 09:30 Message: Logged In: YES user_id=28849 Originator: NO Yes, you are right. Still, for real values of x, it is a bit surprising to see maxima give a complex result in log(sin(x)^21)/2, but of course once you substitute actual integral limits, the complex part goes away. But we should fix the b vs bb issue in schatc.lisp in any case. Or at least make sure b is not special in schatc. Or change b to *b* in sin.lisp. Or something.  Comment By: Dan Gildea (dgildea) Date: 20080903 20:43 Message: Logged In: YES user_id=1797506 Originator: NO Is this really a bug? log(sin(x))  log(sin(x)^21)/2 seems to differ from log(tan(x)) by a constant within each sheet. log(tan(x)) is also complex in general.  Comment By: Raymond Toy (rtoy) Date: 20060831 19:46 Message: Logged In: YES user_id=28849 Yes, replacing all occurrences of b in schatc.lisp with bb makes clisp behave like cmucl. But we can see now how to get log(tan(x)) as the answer. We can move case 5 before case 4. Not exactly sure what impact that will have on the algorithm.  Comment By: Raymond Toy (rtoy) Date: 20060831 19:41 Message: Logged In: YES user_id=28849 FWIW, maxima uses trigint to do this integral, and when it gets to case 4, it tries to match the integrand. With cmucl, it matches, but with clisp it doesn't. In rat1, b is NIL in clisp, but is 'cos* in cmucl. b is declared special, and is set to 'cos* in case 4, just before the call to m2, which calls rat1. But note that coeffpt in schatc.lisp also uses the variable b. There is probably some confusion with b here. I am guessing the b in coeffpt is not the global special variablle b in sin.lisp.  Comment By: Raymond Toy (rtoy) Date: 20060831 16:40 Message: Logged In: YES user_id=28849 Maxima 5.9.3.99rc2 and cmucl 200609 says log(sin(x))  log(sin(x)^21)/2 But the same maxima with clisp 2.35 says log(tan(x)). I don't know why.  Comment By: Robert Dodier (robert_dodier) Date: 20060814 22:46 Message: Logged In: YES user_id=501686 Maxima 5.9.3.99rc1 / Clisp 2.38: integrate((1+tan(x)^2)/tan(x),x); => log(tan(x)) which seems right. Maybe if someone else wants to weigh in here. If someone else agrees this result is OK, we can close this report.  Comment By: Raymond Toy (rtoy) Date: 20060213 13:07 Message: Logged In: YES user_id=28849 This integral is transformed to cos(x)/sin(x)*(sin(x)^2/cos(x)^2+1). Then maxima uses the substitution y=sin(x) to get 1/y*(y^2/(1y^2)+1. However: integrate(1/y*(y^2/(1y^2)+1),y) > log(y)log(y^21)/2. But integrate(expand(1/y*(y^2/(1y^2)+1)),y) > log(y)log(1y^2)/2. The former is wrong for our integration problem; the latter would produce the desired answer.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1374700&group_id=4933 
From: SourceForge.net <noreply@so...>  20080908 11:01:28

Bugs item #2098866, was opened at 20080907 11:39 Message generated for change (Comment added) made by willisbl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2098866&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: The Henman (rvh2007) Assigned to: Nobody/Anonymous (nobody) Summary: strings not comparable by lessthan sign Initial Comment: To reproduce this (%i1) is("John">"Barry"); Maxima encountered a Lisp error: Error in PROGN [or a callee]: Caught fatal error [memory may be damaged] Automatically continuing. To reenable the Lisp debugger set *debuggerhook* to nil. (%i2) build_info()$ Maxima version: 5.16.3 Maxima build date: 22:48 8/24/2008 host type: i686pcmingw32lispimplementationtype: GNU Common Lisp (GCL) lispimplementationversion: GCL 2.6.8 This is a bug even though it is not the right way to compare strings. Rich  >Comment By: Barton Willis (willisbl) Date: 20080908 06:01 Message: Logged In: YES user_id=895922 Originator: NO Strings can sometimes be used as identifiers: (%i5) "a+b"  (ab); (%o5) ba+a+b (%i6) %"a+b"; (%o6) ba (%i7) cos("a"); (%o7) cos(a) (%i10) "a" : 42; "a" improper value assignment Sometimes they cannot be: assume("a" > 0) > error and floor("a") > error. Before we allow mgrp and mgqp to work on strings, we need a general policy on string identifiers.  Comment By: Robert Dodier (robert_dodier) Date: 20080907 17:31 Message: Logged In: YES user_id=501686 Originator: NO Looks like MGRP and MGQP in src/compar.lisp should be equipped with special cases to handle strings.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2098866&group_id=4933 
From: SourceForge.net <noreply@so...>  20080908 04:07:40

Bugs item #2099542, was opened at 20080908 00:07 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2099542&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: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Jack O'Connor (oconnor663) Assigned to: Nobody/Anonymous (nobody) Summary: Common sum simplification unsuccessful Initial Comment: The following sum fails to simplify: sum( n / 2^n, n, 1, inf), simpsum; Presumably the answer should be 2, but instead Maxima just returns the sum in sigma notation.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2099542&group_id=4933 