Screenshot instructions:
Windows
Mac
Red Hat Linux
Ubuntu
Click URL instructions:
Rightclick on ad, choose "Copy Link", then paste here →
(This may not be possible with some types of ads)
You can subscribe to this list here.
2002 
_{Jan}

_{Feb}

_{Mar}

_{Apr}

_{May}

_{Jun}
(67) 
_{Jul}
(61) 
_{Aug}
(49) 
_{Sep}
(43) 
_{Oct}
(59) 
_{Nov}
(24) 
_{Dec}
(18) 

2003 
_{Jan}
(34) 
_{Feb}
(35) 
_{Mar}
(72) 
_{Apr}
(42) 
_{May}
(46) 
_{Jun}
(15) 
_{Jul}
(64) 
_{Aug}
(62) 
_{Sep}
(22) 
_{Oct}
(41) 
_{Nov}
(57) 
_{Dec}
(56) 
2004 
_{Jan}
(48) 
_{Feb}
(47) 
_{Mar}
(33) 
_{Apr}
(39) 
_{May}
(6) 
_{Jun}
(17) 
_{Jul}
(19) 
_{Aug}
(10) 
_{Sep}
(14) 
_{Oct}
(74) 
_{Nov}
(80) 
_{Dec}
(22) 
2005 
_{Jan}
(43) 
_{Feb}
(33) 
_{Mar}
(52) 
_{Apr}
(74) 
_{May}
(32) 
_{Jun}
(58) 
_{Jul}
(18) 
_{Aug}
(41) 
_{Sep}
(71) 
_{Oct}
(28) 
_{Nov}
(65) 
_{Dec}
(68) 
2006 
_{Jan}
(54) 
_{Feb}
(37) 
_{Mar}
(82) 
_{Apr}
(211) 
_{May}
(69) 
_{Jun}
(75) 
_{Jul}
(279) 
_{Aug}
(139) 
_{Sep}
(135) 
_{Oct}
(58) 
_{Nov}
(81) 
_{Dec}
(78) 
2007 
_{Jan}
(141) 
_{Feb}
(134) 
_{Mar}
(65) 
_{Apr}
(49) 
_{May}
(61) 
_{Jun}
(90) 
_{Jul}
(72) 
_{Aug}
(53) 
_{Sep}
(86) 
_{Oct}
(61) 
_{Nov}
(62) 
_{Dec}
(101) 
2008 
_{Jan}
(100) 
_{Feb}
(66) 
_{Mar}
(76) 
_{Apr}
(95) 
_{May}
(77) 
_{Jun}
(93) 
_{Jul}
(103) 
_{Aug}
(76) 
_{Sep}
(42) 
_{Oct}
(55) 
_{Nov}
(44) 
_{Dec}
(75) 
2009 
_{Jan}
(103) 
_{Feb}
(105) 
_{Mar}
(121) 
_{Apr}
(59) 
_{May}
(103) 
_{Jun}
(82) 
_{Jul}
(67) 
_{Aug}
(76) 
_{Sep}
(85) 
_{Oct}
(75) 
_{Nov}
(181) 
_{Dec}
(133) 
2010 
_{Jan}
(107) 
_{Feb}
(116) 
_{Mar}
(145) 
_{Apr}
(89) 
_{May}
(138) 
_{Jun}
(85) 
_{Jul}
(82) 
_{Aug}
(111) 
_{Sep}
(70) 
_{Oct}
(83) 
_{Nov}
(60) 
_{Dec}
(16) 
2011 
_{Jan}
(61) 
_{Feb}
(16) 
_{Mar}
(52) 
_{Apr}
(41) 
_{May}
(34) 
_{Jun}
(41) 
_{Jul}
(57) 
_{Aug}
(73) 
_{Sep}
(21) 
_{Oct}
(45) 
_{Nov}
(50) 
_{Dec}
(28) 
2012 
_{Jan}
(70) 
_{Feb}
(36) 
_{Mar}
(71) 
_{Apr}
(29) 
_{May}
(48) 
_{Jun}
(61) 
_{Jul}
(44) 
_{Aug}
(54) 
_{Sep}
(20) 
_{Oct}
(28) 
_{Nov}
(41) 
_{Dec}
(137) 
2013 
_{Jan}
(62) 
_{Feb}
(55) 
_{Mar}
(31) 
_{Apr}
(23) 
_{May}
(54) 
_{Jun}
(54) 
_{Jul}
(90) 
_{Aug}
(46) 
_{Sep}
(38) 
_{Oct}
(60) 
_{Nov}
(92) 
_{Dec}
(17) 
2014 
_{Jan}
(62) 
_{Feb}
(35) 
_{Mar}
(72) 
_{Apr}
(30) 
_{May}
(97) 
_{Jun}
(81) 
_{Jul}
(63) 
_{Aug}
(64) 
_{Sep}
(28) 
_{Oct}
(45) 
_{Nov}
(48) 
_{Dec}
(109) 
2015 
_{Jan}
(106) 
_{Feb}
(36) 
_{Mar}
(65) 
_{Apr}
(63) 
_{May}
(95) 
_{Jun}
(56) 
_{Jul}
(48) 
_{Aug}
(55) 
_{Sep}
(100) 
_{Oct}
(57) 
_{Nov}
(33) 
_{Dec}
(46) 
2016 
_{Jan}
(76) 
_{Feb}
(53) 
_{Mar}
(88) 
_{Apr}
(79) 
_{May}
(62) 
_{Jun}
(65) 
_{Jul}
(37) 
_{Aug}
(23) 
_{Sep}
(108) 
_{Oct}
(68) 
_{Nov}
(66) 
_{Dec}
(47) 
2017 
_{Jan}
(55) 
_{Feb}
(11) 
_{Mar}
(30) 
_{Apr}
(19) 
_{May}
(14) 
_{Jun}
(21) 
_{Jul}
(30) 
_{Aug}
(48) 
_{Sep}
(39) 
_{Oct}
(30) 
_{Nov}
(75) 
_{Dec}
(28) 
2018 
_{Jan}
(70) 
_{Feb}

_{Mar}

_{Apr}
(1) 
_{May}

_{Jun}

_{Jul}

_{Aug}

_{Sep}

_{Oct}

_{Nov}

_{Dec}

S  M  T  W  T  F  S 






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

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

17

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

31
(3) 






From: SourceForge.net <noreply@so...>  20090524 21:18:52

Bugs item #2796194, was opened at 20090524 17:12 Message generated for change (Comment added) made by rvh2007 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2796194&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: Rich Hennessy (rvh2007) Assigned to: Nobody/Anonymous (nobody) Summary: error doing a Fourier transform Initial Comment: (%i1) integrate(%pi*exp(2*%pi*t)*exp(2*%pi*x*t*%i),t,minf,inf); Maxima encountered a Lisp error: Unhandled kernel in tvarlim Automatically continuing. To reenable the Lisp debugger set *debuggerhook* to nil.  >Comment By: Rich Hennessy (rvh2007) Date: 20090524 17:18 Message: I get this same error in my pwdefint() function in pw.mac. I don't think it is a problem with pwdefint(). See the second case. (%i1) pwdefint(%pi*exp(2*%pi*abs(t))*exp(2*%pi*%i*x*t),t,minf,inf); Maxima encountered a Lisp error: Unhandled kernel in tvarlim Automatically continuing. To reenable the Lisp debugger set *debuggerhook* to nil. case 2: (%i1) integrate(%pi*exp(2*%pi*abs(t))*exp(2*%pi*%i*x*t),t,minf,inf); Maxima encountered a Lisp error: Unhandled kernel in tvarlim Automatically continuing. To reenable the Lisp debugger set *debuggerhook* to nil. (%i2) load(abs_integrate); (%o2) C:/Maxima5.18.1/share/maxima/5.18.1/share/contrib/integration/abs_integrate.mac (%i3) integrate(%pi*exp(2*%pi*abs(t))*exp(2*%pi*%i*x*t),t,minf,inf); Maxima encountered a Lisp error: Unhandled kernel in tvarlim Automatically continuing. To reenable the Lisp debugger set *debuggerhook* to nil. (%i4)  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2796194&group_id=4933 
From: SourceForge.net <noreply@so...>  20090524 21:12:29

Bugs item #2796194, was opened at 20090524 17:12 Message generated for change (Tracker Item Submitted) made by rvh2007 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2796194&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: Rich Hennessy (rvh2007) Assigned to: Nobody/Anonymous (nobody) Summary: error doing a Fourier transform Initial Comment: (%i1) integrate(%pi*exp(2*%pi*t)*exp(2*%pi*x*t*%i),t,minf,inf); Maxima encountered a Lisp error: Unhandled kernel in tvarlim Automatically continuing. To reenable the Lisp debugger set *debuggerhook* to nil.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2796194&group_id=4933 
From: SourceForge.net <noreply@so...>  20090524 14:57:59

Bugs item #1891216, was opened at 20080211 16:38 Message generated for change (Comment added) made by crategus You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1891216&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  Assume Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: is(if a>0 and a>0 and a>0 ...) => internal error Initial Comment: is(if a>0 and a>0 then 1) => unknown (OK) is(if a>0 and a>0 and a>0 then 1) => Maxima encountered a Lisp error: Error in PROGN [or a callee]: Bad plist ((MGREATERP $A (0 DATA (((MGRP ... Same for is(if a>0 and a>0 and a>0 then true else false) i.e. it is not because the return value is a nonboolean Maxima 5.13.0 http://maxima.sourceforge.net Using Lisp GNU Common Lisp (GCL) GCL 2.6.8 (aka GCL)  >Comment By: Dieter Kaiser (crategus) Date: 20090524 16:57 Message: This bug may be related to the bug SF[1891911] "is(f(a+b+c)) > Lisp error". Here we have an even or odd number of arguments to AND. The algorithm fails at the same point in the routine QUEUE+P in db.lisp as for the bug SF[1891911]. Dieter Kaiser  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1891216&group_id=4933 
From: SourceForge.net <noreply@so...>  20090524 14:43:15

Bugs item #1891911, was opened at 20080212 14:03 Message generated for change (Comment added) made by crategus You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1891911&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  Assume Group: None Status: Open Resolution: None Priority: 6 Private: No Submitted By: Barton Willis (willisbl) Assigned to: Nobody/Anonymous (nobody) Summary: is(f(a+b+c)) > Lisp error Initial Comment: OK: (%i1) is(f(a)); (%o1) unknown OK: (%i2) is(f(a+b)); (%o2) unknown Not OK (%i3) is(f(a+b+c)); Maxima encountered a Lisp error: Error in PROGN [or a callee]: Bad plist ($A $B $C) (%i4) build_info();Maxima version: 5.14.0Maxima build date: 21:46 12/27/2007host type: i686pcmingw32lispimplementationtype: GNU Common Lisp (GCL)lispimplementationversion: GCL 2.6.8  >Comment By: Dieter Kaiser (crategus) Date: 20090524 16:43 Message: The error occurs for every odd number of arguments of a sum or a product which is passed as an argument to a function (The function can be a known function like sin too): is(f(a+b+c)) > error is(f(a+b+c+d)) > no error is(f(a+b+c+d+e)) > error ... We get the same error with a product: is(f(a*b*c)) > error is(f(a*b*c*d)) > no error is(f(a*b*c*d*e)) > error ... In the second example of this bug report unk((a*z)/10), we have an odd number of terms of a product too. When we add a term e.g. unk((b*a*z)/10) it will work again. The error occurs in the routine QUEUE+P in the file db.lisp: (defun queue+p (nd lab) cond ((null (setq *db* (+labs nd))) ... For an odd number of arguments of a sum or a product which is an argument of a function the first line of code in the routine QUEUE+P does not work and gives a Lisp error. Dieter Kaiser  Comment By: Barton Willis (willisbl) Date: 20080214 14:01 Message: Logged In: YES user_id=895922 Originator: YES This might help find the bug: OK (%i1) notequal((a*z)/10,0)$ (%i2) maybe(%); (%o2) unknown Not OK (%i3) unk((a*z)/10,0)$ (%i4) maybe(%); Maxima encountered a Lisp error: Error in PROGN [or a callee]: Bad plist ((RAT  Comment By: Barton Willis (willisbl) Date: 20080212 14:11 Message: Logged In: YES user_id=895922 Originator: YES See also SF bug 1726550 "not bugs." These bugs might be the same.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1891911&group_id=4933 
From: SourceForge.net <noreply@so...>  20090524 13:18:30

Bugs item #2166223, was opened at 20081014 16:14 Message generated for change (Comment added) made by crategus You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2166223&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: Pending >Resolution: Wont Fix Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: is(ind<1) gives error Initial Comment: is(ind<1) gives an error: The sign of ind is undefined  an error. To debug this try debugmode(true); It should give <unknown>. Maxima 5.15.0 http://maxima.sourceforge.net Using Lisp GNU Common Lisp (GCL) GCL 2.6.8 (aka GCL)  >Comment By: Dieter Kaiser (crategus) Date: 20090524 15:18 Message: I do not think that we have a bug. The sign of the undeterminates IND and UND is undefined by design on the user level. Internally, when sign is called by limit routines the sign is declared to be PNZ (that is UNKOWN). This can be changed, but I do not see a benefit. Do I have missed something. Setting this bug report to pending. Dieter Kaiser  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2166223&group_id=4933 
From: SourceForge.net <noreply@so...>  20090523 17:51:15

Bugs item #2795799, was opened at 20090523 12:55 Message generated for change (Comment added) made by l_butler You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2795799&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: Share Libraries Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Leo Butler (l_butler) >Assigned to: Robert Dodier (robert_dodier) Summary: lsquares_estimates_approximate ignores initial Initial Comment: The following example is selfexplanatory. >> load(lsquares)$ >> M:matrix( [1900,75.995], [1910,91.972], [1920,105.711], [1930,123.203], [1940,131.669], [1950,150.697], [1960,179.323], [1970,203.212], [1980,226.505], [1990,249.633], [2000,281.422] )$ mse:lsquares_mse(M,[x,y],y=a*exp(b*(x1900)));  The problem appears to be that lsquares_estimates_approximate ignores the initial value passed to it: lsquares_estimates_approximate(mse,'[a,b],initial=[82,0.01],iprint=[1,3]); ************************************************* VECTOR X= 1.000000000000000D+00 1.000000000000000D+00 GRADIENT VECTOR G= 1.313813415094471D+86 1.313813414823674D+88 You can see that the initial vector X is [1,1], although [82,0.01] is passed. The minimisation diverges because of the poor initial condiition. If you redefine mse so that [1,1] is a reasonable initial value, you will get an estimate: mse:subst([a=82*a,b=0.01*b],mse)$ lsquares_estimates_approximate(mse,'[a,b],iprint=[1,3]); THE MINIMIZATION TERMINATED WITHOUT DETECTING ERRORS. IFLAG = 0 [[a = 1.005034579667296, b = 1.243184045872825]]  >Comment By: Leo Butler (l_butler) Date: 20090523 18:51 Message: Robert, In the documentation, the initial guess is specified by 'initial =' while in lsquares.mac, you use 'initial_guess'. If you change 'initial_guess' to 'initial', this fixes the problem  Function: lsquares_estimates_approximate (<MSE>, <a>, initial = <L>, tol = <t>) lsquares_estimates_approximate (MSE, parameters, [optional_args]) := block ([initial_guess : makelist (1, i, 1, length (parameters)), iprint : [1, 0], tol : 1e3], with_parameters (optional_args, lbfgs (MSE, parameters, initial_guess, tol, iprint), [%%])); Leo  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2795799&group_id=4933 
From: SourceForge.net <noreply@so...>  20090523 11:55:47

Bugs item #2795799, was opened at 20090523 12:55 Message generated for change (Tracker Item Submitted) made by l_butler You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2795799&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: Share Libraries Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Leo Butler (l_butler) Assigned to: Nobody/Anonymous (nobody) Summary: lsquares_estimates_approximate ignores initial Initial Comment: The following example is selfexplanatory. >> load(lsquares)$ >> M:matrix( [1900,75.995], [1910,91.972], [1920,105.711], [1930,123.203], [1940,131.669], [1950,150.697], [1960,179.323], [1970,203.212], [1980,226.505], [1990,249.633], [2000,281.422] )$ mse:lsquares_mse(M,[x,y],y=a*exp(b*(x1900)));  The problem appears to be that lsquares_estimates_approximate ignores the initial value passed to it: lsquares_estimates_approximate(mse,'[a,b],initial=[82,0.01],iprint=[1,3]); ************************************************* VECTOR X= 1.000000000000000D+00 1.000000000000000D+00 GRADIENT VECTOR G= 1.313813415094471D+86 1.313813414823674D+88 You can see that the initial vector X is [1,1], although [82,0.01] is passed. The minimisation diverges because of the poor initial condiition. If you redefine mse so that [1,1] is a reasonable initial value, you will get an estimate: mse:subst([a=82*a,b=0.01*b],mse)$ lsquares_estimates_approximate(mse,'[a,b],iprint=[1,3]); THE MINIMIZATION TERMINATED WITHOUT DETECTING ERRORS. IFLAG = 0 [[a = 1.005034579667296, b = 1.243184045872825]]  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2795799&group_id=4933 
From: SourceForge.net <noreply@so...>  20090522 18:46:35

Bugs item #2795534, was opened at 20090522 20:46 Message generated for change (Tracker Item Submitted) made by crategus You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2795534&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: Dieter Kaiser (crategus) Assigned to: Nobody/Anonymous (nobody) Summary: integrate(expintegral_ei(x),x,0,1) gives result with TRUE Initial Comment: When we do the above integral we get an expression with the symbol TRUE in it: (%i14) integrate(expintegral_ei(x),x,0,1); (%o14) expintegral_ei(1)true%e The same for expintegral_ci and expintegral_chi: (%i16) integrate(expintegral_ci(x),x,0,1); (%o16) sin(1)+expintegral_ci(1)true (%i18) integrate(expintegral_chi(x),x,0,1); (%o18) sinh(1)+expintegral_chi(1)true Dieter Kaiser  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2795534&group_id=4933 
From: SourceForge.net <noreply@so...>  20090522 16:01:35

Bugs item #2724669, was opened at 20090401 08:03 Message generated for change (Comment added) made by nobody You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2724669&group_id=4933 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Doesn't work correctly under MS Windows Vista Initial Comment: It doesn't start in command line mode. It starts in GUI mode (wxMaxima and XMaxima) but I can do nothing. I can put nothing in main window. If I put data e.g. for function factor, Maxima doesn't print any results.  Comment By: Nobody/Anonymous (nobody) Date: 20090522 16:01 Message: i had the same problem, i tried this and it works: at C:\Program Files\Maxima5.16.3\lib\maxima\5.16.3\binarygcl\maxima.exe (or where you have installed it) try to put with windows xp compatibility, when i open wxMaxima, after few seconds , the window shows the welcome message and it can be use perfectly !  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2724669&group_id=4933 
From: SourceForge.net <noreply@so...>  20090522 11:05:43

Bugs item #1041570, was opened at 20041006 18:05 Message generated for change (Comment added) made by crategus You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1041570&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  Assume Group: Includes proposed fix >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: assume(abs(x)<1) should imply x<1 and x>1 Initial Comment: assume(abs(x)<1)$ sign(x1) => doesn't know (should be NEG) sign(1x) => doesn't know (should be POS) assume(x>1) => doesn't notice contradiction The easy fix is of course to make the original assumption add x<1 and x>1 to the database, but how do you ensure that they get *removed* if you remove (forget) the original assertion. And what if x<1 has been explicitly added in the meantime? Same problem in the reverse direction: assume(y<1,y>1)$ sign(abs(y)1) => PNZ (should be NEG)  >Comment By: Dieter Kaiser (crategus) Date: 20090522 13:05 Message: The suggested extension (with some modifications) has been implemented. The examples assume(abs(x)<1), forget(abs(x)<1), sign(x1), sign(1x) work as expected. assume(x>1) will give inconsistent. More general cases will work too. The reverse direction is not implemented. Closing this bug report as fixed, because the introducing problem now works. Dieter Kaiser  Comment By: Dieter Kaiser (crategus) Date: 20090508 18:13 Message: I think the handling of the abs funtion is a missing feature of assume. This would be some code to add this feature in a way assume can handle it: ;; This function is like isinop, but returns in addition ;; the expression with the operator and not only T or NIL (defmfun isopinexprp (exp var) (let ((tmp nil)) (cond ((atom exp) nil) ((and (eq (caar exp) var) (not (member 'array (cdar exp) :test #'eq))) (setq tmp exp)) (t (do ((exp (cdr exp) (cdr exp))) ((null exp)) (cond ((setq tmp (isopinexprp (car exp) var)) (return tmp)))))))) ;; The modified routine assume (defmfun assume (pat) (if (and (not (atom pat)) (eq (caar pat) 'mnot) (eq (caaadr pat) '$equal)) (setq pat `(($notequal) ,@(cdadr pat)))) (let (tmp) ;; Look for mabs in the expression, check the bounds and substitute ;; accordingly, e. g. abs(x)<1 > x<1 and x<1 (when (and (setq tmp (isopinexprp pat 'mabs)) (or (and (eq (caar pat) 'mlessp) (isopinexprp (cadr pat) 'mabs) (member ($sign (caddr pat)) '($pos $pz))) (and (eq (caar pat) 'mgreaterp) (member ($sign (cadr pat)) '($pos $pz)) (isopinexprp (caddr pat) 'mabs)))) (let ((pat1 ($substitute (cadr tmp) tmp pat)) (pat2 ($substitute (mul 1 (cadr tmp)) tmp pat))) (assume pat1) (assume pat2)))) (let ((dummy (let ($assume_pos) (car (mevalp1 pat))))) (cond ((eq dummy t) '$redundant) ((null dummy) '$inconsistent) ((atom dummy) '$meaningless) (t (learn pat t))))) ;; The modified routine forget (defmfun forget (pat) (cond (($listp pat) (cons '(mlist simp) (mapcar #'forget1 (cdr pat)))) (t (let (tmp) (when (setq tmp (isopinexprp pat 'mabs)) (let ((pat1 ($substitute (cadr tmp) tmp pat)) (pat2 ($substitute (mul 1 (cadr tmp)) tmp pat))) (forget1 pat1) (forget1 pat2)))) (forget1 pat)))) With this extension we get: (%i3) assume(abs(x)<1); (%o3) [abs(x) < 1] (%i4) facts(); (%o4) [1 > x,x > 1,1 > abs(x)] (%i5) sign(x1); (%o5) neg (%i6) sign(1x); (%o6) pos An example with a positive symbol as an upper bound: (%i1) assume(y>0); (%o1) [y > 0] (%i2) assume(abs(x)<y); (%o2) [y > abs(x)] (%i3) facts(); (%o3) [y > 0,y > x,y+x > 0,y > abs(x)] (%i4) sign(yx); (%o4) pos (%i5) sign(x+y); (%o5) pos (%i6) sign(xy); (%o6) neg (%i7) sign(xy); (%o7) neg This will work together with forget: (%i2) assume(abs(x)<1)$ (%i3) facts(); (%o3) [1 > x,x > 1,1 > abs(x)] (%i4) forget(abs(x)<1)$ (%i5) facts(); (%o5) [] The bound has to be a positive value: (%i6) assume(abs(x)<1); (%o6) [inconsistent] This does not sovlve the problem for the reverse direction. This feature might be added to the $signfunction. Dieter Kaiser  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1041570&group_id=4933 
From: SourceForge.net <noreply@so...>  20090521 19:44:39

Bugs item #609464, was opened at 20020915 05:18 Message generated for change (Comment added) made by crategus You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=609464&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: Fixed Priority: 5 Private: No Submitted By: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: 1+%e,numer and %e^%e,numer Initial Comment: %e^%e,numer does not evaluate numerically to 15.15... as it should, it simply returns the simplified expression %e^%e.  >Comment By: Dieter Kaiser (crategus) Date: 20090521 21:44 Message: The flag %enumer has not been cut out as suggested in the last posting, but code has been added to simp.lisp with revision 1.77 to simplify %e in expressions, when $numer is true. The examples 1+%e, %e^%e give the expected numerical values. Furhtermore functions with %e as an argument simplify accordingly. Closing this bug report as fixed. Dieter Kaiser  Comment By: Dieter Kaiser (crategus) Date: 20090514 00:48 Message: We have the flag %enumer which should prevent the evaluation of %e to its numerical value when the flag $numer is true. The evaluation occurs only when $%enumer is true too. But we have the following code in the function $ev: (if (and (cdr l) (null (cddr l)) (eq (car l) '$%e) (eq (cadr l) '$numer)) (setq l (append l '($%enumer)))) This code is responsible for some of the inconsistent behaviors as reported in this bug report: %e is evaluated because of the above special handling: (%i5) %e,numer; (%o5) 2.718281828459045 Partially evaluation with a multiplication: (%i7) %e*(%e+1)^2,numer; (%o7) 2.7182817*(%e+1)^2 All examples are evaluated with %enumer true: (%i10) %e*(%e+1)^2,numer,%enumer; (%o10) 37.581930949508 We can prevent evaluation: (%i4) %e,numer,noeval; (%o4) %e A further complication is the simplifier. If we have an exponent, simplification and not evaluation causes the numerical evaluation. (%i5) %e^1,numer,noeval; (%o5) 2.718281828459045 First I tried to get this all more consistent by removing the hack in $ev which causes evaluation of %e in certain expressions. But because of the simplifier, as shown in the last example, this does not help completely. So, I think it would be most consistent to cut out the special handling of the flag %enumer in the code of meval1. ((and $numer (setq val (safemget form '$numer)) ;(or (not (eq form '$%e)) $%enumer) ) (return (meval1 val))) There are two further pieces of code we can cut out. With this changes %enumer has no longer a function and we would get: (%i8) %e,numer; (%o8) 2.718281828459045 (%i9) %e+1,numer; (%o9) 3.718281828459045 (%i10) sin(%e),numer; (%o10) .4107812905029088 (%i11) (%e+1)^2,numer; (%o11) 13.82561975584874 When we cut out %enumer, the flag %numer would be more consistent with the results of he flag bfloat and the functions float and bfloat, too. The testsuite and the share_testsuite would have no problem. Is there a reason not to cut out the flag %enumer? Dieter Kaiser  Comment By: Stavros Macrakis (macrakis) Date: 20080127 20:22 Message: Logged In: YES user_id=588346 Originator: YES What is by design is that %e^x,numer does not become 2.718^x (unless %enumer is true). The other cases are because the original coder either didn't care about cases like %e+1 or thought it would be too computationally expensive to handle them differently, since they can't be handled bottomup. After all, all of %e^2, %e^%pi, %e^(2/3) with ,numer *do* evaluate to floats. If we fix %e+1,numer we should also fix sin(%pi+x),numer. Currently, that gives sin(3.14+x); it should give sin(x) (that is, the %pi should not simplify to 3.14; the regular simplifier should take over). There is a special hack so that *at the top level*, %e,numer => 2.718. This is really ugly: %e,numer => 2.7 %e+1,numer => %e+1 [%e],numer => [%e] The correct intuition is this: with numer=true, if simplifying a constant (like %e or %pi or for that matter %i and inf) to a float would cause the expression it is contained in (and not just the constant itself) to become a float/complex float, then do it. Otherwise don't. For the purposes of this definition, consider that a toplevel constant is "contained in" some sort of expression. This design would give numer:true %e^x => %e^x sin(%pi+x) => sin(x) inf => <<IEEE positive infinity>> but of course we don't currently handle that %e^2 => 7.4 2^%e => 6.6 atan(1) => .78 atan(inf) => 1.57 sin(2/3*%pi + x) => sin(x+2.1) %e^%i => .5+.8*%i %i^%i => .27 sin(1+%pi) => 0.84 I don't think we can easily fix all these cases, but we should start. The current behavior is incoherent and not very useful.  Comment By: Robert Dodier (robert_dodier) Date: 20080127 20:01 Message: Logged In: YES user_id=501686 Originator: NO I'm pretty sure we should change the behavior of %e in the presence of numer, whether or not the current behavior is intentional. Reopening this report accordingly. I've been bitten by this inconsistency repeatedly. %e, numer; => 2.718281828459045 %e + 1, numer; => %e + 1 %e^%pi, numer; => 23.14069263277927 %e^%e, numer; => %e^%e Preserving %e in %e^foo, numer when foo is nonnumeric is OK by me. I suppose that's the original intent of %enumer but for whatever reason it is not the sole effect.  Comment By: Dan Gildea (dgildea) Date: 20080127 19:26 Message: Logged In: YES user_id=1797506 Originator: NO This seems to be by design. (%i5) %e^%e,numer,%enumer; (%o5) 15.15426224147926 (%i6) %e^%e,numer; (%o6) %e^%e (%i7) %e+1,numer,%enumer; (%o7) 3.718281828459045 (%i8) %e+1,numer; (%o8) %e+1  Comment By: Robert Dodier (robert_dodier) Date: 20060626 20:17 Message: Logged In: YES user_id=501686 Still present in 5.9.3.  Comment By: Stavros Macrakis (macrakis) Date: 20040323 18:48 Message: Logged In: YES user_id=588346 cf. bug 531466 re float(exp(exp(2)))  Comment By: Stavros Macrakis (macrakis) Date: 20020919 05:12 Message: Logged In: YES user_id=588346 1+%e,numer also fails These examples work with bfloat, e.g. 1+%e,bfloat; %e^%e,bfloat;  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=609464&group_id=4933 
From: SourceForge.net <noreply@so...>  20090521 19:31:39

Bugs item #2003386, was opened at 20080626 20:49 Message generated for change (Settings changed) made by crategus You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2003386&group_id=4933 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Lisp Core Group: Includes proposed fix >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Raymond Toy (rtoy) Assigned to: Nobody/Anonymous (nobody) Summary: float(elliptic_kc(1)) causes Lisp error Initial Comment: float(elliptic_kc(1)) signals a Lisp error. I think it should do something else. Perhaps return inf since elliptic_kc(x) > inf as x > 1, so elliptic_kc(1) might return inf instead of a noun form.  >Comment By: Dieter Kaiser (crategus) Date: 20090521 21:31 Message: A check for an argument 1 has been added to simp%elliptic_kc with revision 1.68 of ellipt.lisp. elliptic_kc(1), elliptic_kc(1.0), and elliptic_kc(1.0b0) give a Maxima error. The function is undefined. The suggested further simplifications for some special values are not implemented. Closing this bug report as fixed. Dieter Kaiser  Comment By: Dieter Kaiser (crategus) Date: 20090512 16:31 Message: I think a check for an argument 1 for the function elliptic_kc should be added before we call the numerical routines and a Maxima error should be thrown. A more general result would be infinity. Because Maxima can not handle infinities correctly, we do not return infinities in other cases too. In the following code the handling of infinities as an argument and the handling of the number 1 for elliptic_ec has been added too. Index: ellipt.lisp =================================================================== RCS file: /cvsroot/maxima/maxima/src/ellipt.lisp,v retrieving revision 1.67 diff u r1.67 ellipt.lisp  ellipt.lisp 29 Mar 2009 06:24:51 0000 1.67 +++ ellipt.lisp 12 May 2009 14:22:49 0000 @@ 1947,13 +1947,23 @@ (declare (ignore yy)) (oneargcheck form) (let ((m (simpcheck (cadr form) z)))  (cond ((floatnumericalevalp m) + (cond ((onep1 m) + (merror + (intl:gettext "elliptic_kc: elliptic_kc(~:M) is undefined.") + m)) + ((floatnumericalevalp m) ;; Numerically evaluate it (elliptick (float m))) ((complexfloatnumericalevalp m) (complexify (bigfloat::bfelliptick (complex ($realpart m) ($imagpart m))))) ((complexbigfloatnumericalevalp m) (to (bigfloat::bfelliptick (bigfloat:to ($bfloat m))))) + ((or (member m '($inf $minf $infinity)) + (member (mul 1 m) '($inf $minf)) + (member (mul '$%i m) '($inf $minf)) + (member (mul 1 '$%i m) '($inf $minf))) + ;; Handle infinities as an argument. + 0) ((zerop1 m) '((mtimes) ((rat) 1 2) $%pi)) ((alike1 m 1//2) @@ 2002,6 +2012,11 @@ ((zerop1 m) '((mtimes) ((rat) 1 2) $%pi)) ;; Some special cases we know about. + ((onep1 m) m) + ((or (eq m '$minf) + (eq (mul 1 m) '$inf)) + '$inf) + ((eq m '$infinity) '$infinity) (t ;; Nothing to do (eqtest (list '(%elliptic_ec) m) form))))) Success, CVS operation completed Dieter Kaiser  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2003386&group_id=4933 
From: SourceForge.net <noreply@so...>  20090520 04:32:38

Bugs item #2793868, was opened at 20090519 08:51 Message generated for change (Comment added) made by willisbl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2793868&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: FrancoB (franco68tn) Assigned to: Nobody/Anonymous (nobody) Summary: Additivity of integration on intervals Initial Comment: It seems like Maxima doesn't know of the property of additivity of integration on intervals. It is unable to evaluate the following integral: (%i1) integrate(exp(abs(x)),x,1,+inf); (%o1) integrate(%e^(abs(x)),x,1,inf) If we divide the integral over two intervals, Maxima can perform the calculation: (%i2) integrate(exp(abs(x)),x,1,0)+integrate(exp(abs(x)),x,0,+inf); (%o2) 2%e^(1) Franco B.  Maxima version: 5.18.1 Maxima build date: 20:57 4/19/2009 host type: i686pcmingw32 lispimplementationtype: GNU Common Lisp (GCL) lispimplementationversion: GCL 2.6.8   >Comment By: Barton Willis (willisbl) Date: 20090519 23:32 Message: (%i3) load("abs_integrate")$ (%i4) integrate(exp(abs(x)),x,1,inf); (%o4) %e^(1)*(%e1)+1  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2793868&group_id=4933 
From: SourceForge.net <noreply@so...>  20090520 02:13:02

Bugs item #2794173, was opened at 20090519 21:12 Message generated for change (Tracker Item Submitted) made by chrisdwhite You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2794173&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: Documentation Group: Includes proposed fix Status: Open Resolution: None Priority: 5 Private: No Submitted By: Christopher White (chrisdwhite) Assigned to: Nobody/Anonymous (nobody) Summary: Manpage gives incorrect website Initial Comment: The last line of the manpage gives the website as "<http://maxima.sourcforge.net>";, when it should be <http://maxima.sourceforge.net>;. I've attached a patch.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2794173&group_id=4933 
From: SourceForge.net <noreply@so...>  20090519 17:02:53

Bugs item #2793906, was opened at 20090519 17:11 Message generated for change (Settings changed) made by riotorto You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2793906&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: Closed >Resolution: Invalid Priority: 5 Private: No Submitted By: BeCase (becase) Assigned to: Nobody/Anonymous (nobody) Summary: Plot2d: nonnumeric value Initial Comment: Maxima 5.18.1, SBCL 1.0.25 Try to exec next code: showtime:true$ C1:125000$ C2:15$ Q:2000$ P:1/4$ F(b):=integrate(%e^(s^2/(2*Q^2)),s,minf,b)$ f(x):=((1P)*C1*(1F(x)) + P*C2*Q*(x/2 + 2*%pi/4) * F(x/2  sqrt(2*%pi)/4)); plot2d(f,[x,3000,2990]); And we get: plot2d: expression evaluates to nonnumeric value everywhere in plotting range. plot2d: nothing to plot. Evaluation took 3140.9800 seconds (3539.6040 elapsed) using 23500.930 MB. (%o8) false Mathematica don't have this bug and calculate this at seconds.  Comment By: BeCase (becase) Date: 20090519 18:46 Message: Thanks, it works :)  Comment By: Mario Rodriguez Riotorto (riotorto) Date: 20090519 18:42 Message: try plot2d(f(x),[x,3000,2990]);  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2793906&group_id=4933 
From: SourceForge.net <noreply@so...>  20090519 16:46:29

Bugs item #2793906, was opened at 20090519 15:11 Message generated for change (Comment added) made by becase You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2793906&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: Open Resolution: Remind Priority: 5 Private: No Submitted By: BeCase (becase) Assigned to: Nobody/Anonymous (nobody) Summary: Plot2d: nonnumeric value Initial Comment: Maxima 5.18.1, SBCL 1.0.25 Try to exec next code: showtime:true$ C1:125000$ C2:15$ Q:2000$ P:1/4$ F(b):=integrate(%e^(s^2/(2*Q^2)),s,minf,b)$ f(x):=((1P)*C1*(1F(x)) + P*C2*Q*(x/2 + 2*%pi/4) * F(x/2  sqrt(2*%pi)/4)); plot2d(f,[x,3000,2990]); And we get: plot2d: expression evaluates to nonnumeric value everywhere in plotting range. plot2d: nothing to plot. Evaluation took 3140.9800 seconds (3539.6040 elapsed) using 23500.930 MB. (%o8) false Mathematica don't have this bug and calculate this at seconds.  >Comment By: BeCase (becase) Date: 20090519 16:46 Message: Thanks, it works :)  Comment By: Mario Rodriguez Riotorto (riotorto) Date: 20090519 16:42 Message: try plot2d(f(x),[x,3000,2990]);  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2793906&group_id=4933 
From: SourceForge.net <noreply@so...>  20090519 16:42:15

Bugs item #2793906, was opened at 20090519 17:11 Message generated for change (Comment added) made by riotorto You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2793906&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: Remind Priority: 5 Private: No Submitted By: BeCase (becase) Assigned to: Nobody/Anonymous (nobody) Summary: Plot2d: nonnumeric value Initial Comment: Maxima 5.18.1, SBCL 1.0.25 Try to exec next code: showtime:true$ C1:125000$ C2:15$ Q:2000$ P:1/4$ F(b):=integrate(%e^(s^2/(2*Q^2)),s,minf,b)$ f(x):=((1P)*C1*(1F(x)) + P*C2*Q*(x/2 + 2*%pi/4) * F(x/2  sqrt(2*%pi)/4)); plot2d(f,[x,3000,2990]); And we get: plot2d: expression evaluates to nonnumeric value everywhere in plotting range. plot2d: nothing to plot. Evaluation took 3140.9800 seconds (3539.6040 elapsed) using 23500.930 MB. (%o8) false Mathematica don't have this bug and calculate this at seconds.  >Comment By: Mario Rodriguez Riotorto (riotorto) Date: 20090519 18:42 Message: try plot2d(f(x),[x,3000,2990]);  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2793906&group_id=4933 
From: SourceForge.net <noreply@so...>  20090519 15:11:11

Bugs item #2793906, was opened at 20090519 15:11 Message generated for change (Tracker Item Submitted) made by becase You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2793906&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: Open Resolution: None Priority: 5 Private: No Submitted By: BeCase (becase) Assigned to: Nobody/Anonymous (nobody) Summary: Plot2d: nonnumeric value Initial Comment: Maxima 5.18.1, SBCL 1.0.25 Try to exec next code: showtime:true$ C1:125000$ C2:15$ Q:2000$ P:1/4$ F(b):=integrate(%e^(s^2/(2*Q^2)),s,minf,b)$ f(x):=((1P)*C1*(1F(x)) + P*C2*Q*(x/2 + 2*%pi/4) * F(x/2  sqrt(2*%pi)/4)); plot2d(f,[x,3000,2990]); And we get: plot2d: expression evaluates to nonnumeric value everywhere in plotting range. plot2d: nothing to plot. Evaluation took 3140.9800 seconds (3539.6040 elapsed) using 23500.930 MB. (%o8) false Mathematica don't have this bug and calculate this at seconds.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2793906&group_id=4933 
From: SourceForge.net <noreply@so...>  20090519 14:30:42

Bugs item #2793888, was opened at 20090519 16:30 Message generated for change (Tracker Item Submitted) made by raniuale You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2793888&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  Differential eqns Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Renato AlvarezNodarse (raniuale) Assigned to: Nobody/Anonymous (nobody) Summary: additional package dynamics Initial Comment: The dynamic package does not work properly. The commands orbits, evolution, staircase and chaosgame etc do not accept any opctions including the ones used in the documentation. The problems is that the way os passing the options to plot2d fails. I include some examples: (%i12) evolution(cos(y), 2, 11, [yaxislabel, "y"], [xaxislabel,"n"]); Unknown plot option specified: yaxislabel #0: evolution(fun=cos(y),initial=2,n=11,options=[[yaxislabel,"y"],[xaxislabel,"n"]])(dynamics.mac line 54)  an error. To debug this try debugmode(true); Unknown plot option specified: real #0: staircase(fun=cos(y),initial=1,n=11,options=[[real,0,1.2]])(dynamics.mac line 96)  an error. To debug this try debugmode(true); (%i14) orbits(x+y^2, 0, 100, 400, [x,1,1.53,0.001], [pointsize,0.9],[ycenter,1.2], [yradius,0.4]); Graph passed to plot2d... Unknown plot option specified: pointsize #0: orbits(f=y^2+x,y0=0,n1=100,n2=400,domain=[x,1,1.53,0.001],options=[[pointsize,0.9],[ycenter,1.2],[yradius,0.4]])(dynamics.mac line 367)  an error. To debug this try debugmode(true); (%i15) chaosgame([[0, 0], [1, 0], [0.5, sqrt(3)/2]], [0.1, 0.1], 1/2, 30000, [pointsize,0.7]); Unknown plot option specified: pointsize #0: chaosgame(point=[[0,0],[1,0],[0.5,0.86602540378444]],p0=[0.1,0.1],b=0.5,n=30000,options=[[pointsize,0.7]])(dynamics.mac line 195)  an error. To debug this try debugmode(true); Cheers, Renato (ran@...) Renato  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2793888&group_id=4933 
From: SourceForge.net <noreply@so...>  20090519 13:58:58

Bugs item #2793827, was opened at 20090519 08:14 Message generated for change (Settings changed) made by rtoy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2793827&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: Fixed Priority: 5 Private: No Submitted By: Andrej Vodopivec (andrejv) Assigned to: Nobody/Anonymous (nobody) Summary: internal error in integrate Initial Comment: We get an error in integrate: (%i24) expr: ((g32475^n*(n*g32475n1))/(g324751)^2+1/(g324751)^2)/(1g32475)  (g32475^(n+1)/(g324751)^2+(g32475^(2*n+1)*(n*g32475n1))/(g324751)^2)/(1g32475)$ (%i25) integrate(expr, g32475, 0, 1); Maxima encountered a Lisp error: Argument Y is not a NUMBER: NIL. Automatically continuing. To reenable the Lisp debugger set *debuggerhook* to nil. Maxima can compute the integral if expr is simplified: (%i26) integrate(ratsimp(expr), g32475, 0, 1); Is n positive, negative, or zero?pos; (%o26) (n+1)^2/21/2  Comment By: Nobody/Anonymous (nobody) Date: 20090519 09:56 Message: Bug is in behavior in src/limit.lisp. Fixed in limit.lisp, rev. 1.69  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2793827&group_id=4933 
From: SourceForge.net <noreply@so...>  20090519 13:57:01

Bugs item #2793827, was opened at 20090519 12:14 Message generated for change (Comment added) made by nobody You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2793827&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: Andrej Vodopivec (andrejv) Assigned to: Nobody/Anonymous (nobody) Summary: internal error in integrate Initial Comment: We get an error in integrate: (%i24) expr: ((g32475^n*(n*g32475n1))/(g324751)^2+1/(g324751)^2)/(1g32475)  (g32475^(n+1)/(g324751)^2+(g32475^(2*n+1)*(n*g32475n1))/(g324751)^2)/(1g32475)$ (%i25) integrate(expr, g32475, 0, 1); Maxima encountered a Lisp error: Argument Y is not a NUMBER: NIL. Automatically continuing. To reenable the Lisp debugger set *debuggerhook* to nil. Maxima can compute the integral if expr is simplified: (%i26) integrate(ratsimp(expr), g32475, 0, 1); Is n positive, negative, or zero?pos; (%o26) (n+1)^2/21/2  Comment By: Nobody/Anonymous (nobody) Date: 20090519 13:56 Message: Bug is in behavior in src/limit.lisp. Fixed in limit.lisp, rev. 1.69  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2793827&group_id=4933 
From: SourceForge.net <noreply@so...>  20090519 13:51:18

Bugs item #2793868, was opened at 20090519 15:51 Message generated for change (Tracker Item Submitted) made by franco68tn You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2793868&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: FrancoB (franco68tn) Assigned to: Nobody/Anonymous (nobody) Summary: Additivity of integration on intervals Initial Comment: It seems like Maxima doesn't know of the property of additivity of integration on intervals. It is unable to evaluate the following integral: (%i1) integrate(exp(abs(x)),x,1,+inf); (%o1) integrate(%e^(abs(x)),x,1,inf) If we divide the integral over two intervals, Maxima can perform the calculation: (%i2) integrate(exp(abs(x)),x,1,0)+integrate(exp(abs(x)),x,0,+inf); (%o2) 2%e^(1) Franco B.  Maxima version: 5.18.1 Maxima build date: 20:57 4/19/2009 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=2793868&group_id=4933 
From: SourceForge.net <noreply@so...>  20090519 12:14:57

Bugs item #2793827, was opened at 20090519 14:14 Message generated for change (Tracker Item Submitted) made by andrejv You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2793827&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: Andrej Vodopivec (andrejv) Assigned to: Nobody/Anonymous (nobody) Summary: internal error in integrate Initial Comment: We get an error in integrate: (%i24) expr: ((g32475^n*(n*g32475n1))/(g324751)^2+1/(g324751)^2)/(1g32475)  (g32475^(n+1)/(g324751)^2+(g32475^(2*n+1)*(n*g32475n1))/(g324751)^2)/(1g32475)$ (%i25) integrate(expr, g32475, 0, 1); Maxima encountered a Lisp error: Argument Y is not a NUMBER: NIL. Automatically continuing. To reenable the Lisp debugger set *debuggerhook* to nil. Maxima can compute the integral if expr is simplified: (%i26) integrate(ratsimp(expr), g32475, 0, 1); Is n positive, negative, or zero?pos; (%o26) (n+1)^2/21/2  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2793827&group_id=4933 
From: SourceForge.net <noreply@so...>  20090519 02:20:25

Bugs item #2784167, was opened at 20090430 06:41 Message generated for change (Comment added) made by sfrobot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2784167&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: Tests Group: None >Status: Closed Resolution: Works For Me Priority: 5 Private: No Submitted By: Kenneth Sloan (kennethrsloan) Assigned to: Nobody/Anonymous (nobody) Summary: 101 & 139 fail MacOSX Initial Comment:  Maxima version: 5.18.1 Maxima build date: 14:34 4/18/2009 host type: i686appledarwin8.11.1 lispimplementationtype: CMU Common Lisp lispimplementationversion: 19f (19F)  ********************** Problem 101 *************** Input: ev(e5, au = 0, omega = 2) Result: [0.4, 2.104312740630307e12, 225, 0] This differed from the expected result: [.4000000000000001, 2.216570948815925e11, 175, 0] ********************** Problem 139 *************** Input: expintegral_chi(z)  conjugate(expintegral_chi(conjugate(z))) Result: 0.0339413106060743  .07647309974404348 %i This differed from the expected result: 0.0  >Comment By: SourceForge Robot (sfrobot) Date: 20090519 02:20 Message: This Tracker item was closed automatically by the system. It was previously set to a Pending status, and the original submitter did not respond within 14 days (the time period specified by the administrator of this Tracker).  Comment By: Raymond Toy (rtoy) Date: 20090504 14:45 Message: Ok. Since this appears not to be repeatable, I'm marking this as Pending/Works For Me. If there's any additional information, please update this bug report.  Comment By: Nobody/Anonymous (nobody) Date: 20090501 17:48 Message: ($i1) run_testsuite(); ... No unexpected errors found. ; Evaluation took: ; 162.15f0 seconds of real time ; 133.21613f0 seconds of user run time ; 20.53623f0 seconds of system run time ; 350,844,228,618 CPU cycles ; [Run times include 9.95f0 seconds GC run time] ; 0 page faults and ; 9,363,027,080 bytes consed. ; (%o0) done Now *that* is interesting... I'd like to say "nevermind"  but now I'm very puzzled. Just for completeness: (%i1) z:0.5+%i; (%o1) %i + 0.5 (%i2) expintegral_chi(z); (%o2) 1.341686846905066 %i + .4971469507996198 (%i3) conjugate(expintegral_chi(conjugate(z))); (%o3) 1.341686846905066 %i + .4971469507996198 and (%i7) 0.5*(expintegral_e(1,z)+expintegral_e(1,z)+log(z)log(z)); (%o7)  0.5 ( 2.683373693810132 %i  .9942939015992396) (%i8) expand(%); (%o8) 1.341686846905066 %i + .4971469507996198 This seems to match your results (except for a bit more precision). At this point, I have no idea how the first test_suite() went wrong, and can't replicate it. Chalk it up to a gravity wave.  Comment By: Nobody/Anonymous (nobody) Date: 20090501 17:28 Message: I'm using the MacOSX build  not building from source. I ran the entire test suite  these were the only two errors. Working on the numerical results in response to the previous comment, now.  Comment By: Raymond Toy (rtoy) Date: 20090501 17:01 Message: I ran the entire testsuite using CMUCL 200904 on Mac OS X 10.5 with the current CVS code. I do not get any test failures either. Did you run the entire testsuite or just parts of it?  Comment By: Dieter Kaiser (crategus) Date: 20090501 14:36 Message: Hello Kenneth, I cannot verify the failures with GCL 2.6.8 and CLISP 2.44. There might be problem with the numericial calculations of expintegral_chi which is special to your Lisp implementation. For the problem 139 in rtest_expintegral.mac I get the following numerical results with CLISP 2.44: (%i12) z:0.5+%i; (%o12) %i + 0.5 (%i13) expintegral_chi(z); (%o13) 1.341686846905066 %i + 0.49714695079962 (%i14) conjugate(expintegral_chi(conjugate(z))); (%o14) 1.341686846905066 %i + 0.49714695079962 Internally, the following formula for the calculation is used: (%i20) 0.5*(expintegral_e(1,z)+expintegral_e(1,z)+log(z)log(z)); (%o20)  0.5 ( 2.683373693810132 %i  0.99429390159924) (%i21) expand(%); (%o21) 1.341686846905066 %i + 0.49714695079962 Can you post your numerical results. Dieter Kaiser  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2784167&group_id=4933 
From: SourceForge.net <noreply@so...>  20090518 19:08:11

Bugs item #2793294, was opened at 20090518 12:54 Message generated for change (Comment added) made by crategus You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2793294&group_id=4933 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Lisp Core Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: derivative of gamma_incomplete Initial Comment: (%i1) diff(gamma_incomplete(x,y),x,2); log(0) has been generated.  an error. To debug this try debugmode(true); (%i2) build_info(); Maxima version: 5.18post Maxima build date: 5:51 5/18/2009 host type: i686pcmingw32 lispimplementationtype: Clozure Common Lisp lispimplementationversion: Version 1.3dev (WindowsX8632)  >Comment By: Dieter Kaiser (crategus) Date: 20090518 21:08 Message: I do not think that this is really a bug, but a problem of the domain of the functions involved. The first derivative gives: (%i4) diff(gamma_incomplete(a,x),a); (%o4) gamma_incomplete_generalized(a,0,x)*log(x) +gamma(a)^2*hypergeometric_generalized([a,a],[a+1,a+1],x)*x^a +psi[0](a)*gamma(a) This result contains the function gamma_incomplete_generalized(a,0,x). That is equivalent to gamma_incomplete(a,0)gamma_incomplete(a,x). But gamma_incomplete(a,0) is not defined for a<=0. The derivative of gamma_incomplete(a,0) and gamma_incomplete_generalized(a,0,x) causes the error log(0) generated. We can avoid this error when assuming that a>0. For this case we get the simplification: (%i2) assume(a>0); (%o2) [a > 0] gamma_incomplete simplifies: (%i3) gamma_incomplete(a,0); (%o3) gamma(a) gamma_incomplete_generalized simplifies accordingly: (%i4) gamma_incomplete_generalized(a,0,x); (%o4) gamma(a)gamma_incomplete(a,x) With a>0 the second derivative is: (%i5) diff(gamma_incomplete(a,x),a,2); (%o5) log(x)*((gamma(a)gamma_incomplete(a,x))*log(x) gamma(a)^2*hypergeometric_generalized([a,a],[a+1,a+1],x)*x^a) +gamma(a)^2*hypergeometric_generalized([a,a],[a+1,a+1],x)*x^a*log(x) +gamma(a)^2*'diff(hypergeometric_generalized([a,a],[a+1,a+1],x),a,1) *x^a +2*psi[0](a)*gamma(a)^2*hypergeometric_generalized([a,a],[a+1,a+1],x) *x^a+psi[1](a)*gamma(a)+psi[0](a)^2*gamma(a) When we try to get the derivative for a negative parameter an error is generated: (%i6) diff(gamma_incomplete(a,x),a,2); log(0) has been generated.  an error. To debug this try debugmode(true); It seems to me that the derivatives are only well defined for a positive parameter a. I am not sure what we should do to improve this behavior. Perhaps we can include a test for the sign of the parameter and return a noun form if the sign is not known to be positive. Dieter Kaiser  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2793294&group_id=4933 