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}
(63) 
_{Sep}

_{Oct}

_{Nov}

_{Dec}

S  M  T  W  T  F  S 



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

6

7
(13) 
8
(6) 
9
(2) 
10
(8) 
11
(4) 
12

13
(15) 
14
(19) 
15
(3) 
16
(4) 
17
(2) 
18
(1) 
19
(1) 
20

21
(4) 
22
(7) 
23
(3) 
24

25
(2) 
26
(1) 
27
(1) 
28
(4) 
29
(7) 
30
(3) 
31
(1) 


From: SourceForge.net <noreply@so...>  20091213 22:52:13

Bugs item #593351, was opened at 20020810 04:48 Message generated for change (Comment added) made by crategus You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=593351&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: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: limit/sin(inf)etc. should give 0, not IND Initial Comment: limit(cos(1/x)*sin(x)sin(x),x,inf) should give 0, not IND.  >Comment By: Dieter Kaiser (crategus) Date: 20091213 23:52 Message: Fixed in limit.lisp revision 1.88. Closing this bug report as fixed. Dieter Kaiser  Comment By: Rupert Swarbrick (rswarbrick) Date: 20090215 19:00 Message: This happens for limit ( (cos(1/x)1) * sin(x), x, inf) because $limit is somehow refactoring before it gets around to calling limit. Tracing shows: (LIMIT ((MPLUS SIMP) ((MTIMES SIMP) 1 ((%SIN SIMP) $X)) ((MTIMES SIMP) ((%COS SIMP) ((MEXPT SIMP) $X 1)) ((%SIN SIMP) $X))) $X $INF THINK) which then gets evaluated for each term in the plus, giving $ind  $ind = $ind. The following call works: (let ((lhp?)) (declare (special lhp?)) (limit #$(cos(1/x)1) * sin(x)$ '$X '$INF 'THINK)) giving '$zerob. I'm not sure if there's a canonical way to expand the right things in general though. Rupert  Comment By: Stavros Macrakis (macrakis) Date: 20020919 05:55 Message: Logged In: YES user_id=588346 Strangely enough, limit even gets this wrong if you feed it the factored form: limit ( (cos(1/x)1) * sin(x), x, inf) even though it correctly gets limit(cos(1/x)1,x,inf) => 0 and limit(sin(x),x,inf) => ind and 0*ind is always 0. On the other hand, it does get it right if you factor the exponentialized form: limit(factor(ev(...,exponentialize)),x,inf) => 0  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=593351&group_id=4933 
From: SourceForge.net <noreply@so...>  20091213 21:54:23

Bugs item #2911891, was opened at 20091210 10:28 Message generated for change (Comment added) made by crategus You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2911891&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: Fixed Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: gcfac gives Lisp error Initial Comment: a : diff(diff(diff(integrate(integrate(integrate(sin(sqrt(x)),x),x),x),x),x),x); load (scifac)$ gcfac(a); Maxima encountered a Lisp error: Error in AND [or a callee]: The function $MIN is undefined. Automatically continuing. To reenable the Lisp debugger set *debuggerhook* to nil.  >Comment By: Dieter Kaiser (crategus) Date: 20091213 22:54 Message: Corrected in scifac.lisp revision 1.5. Closing this bug report as fixed. Dieter Kaiser  Comment By: Dieter Kaiser (crategus) Date: 20091213 19:16 Message: This example is a bit strange. The result should be sin(sqrt(x)), but we get: (%i6) diff(diff(diff(integrate(integrate(integrate(sin(sqrt(x)),x),x),x),x),x),x); (%o6) 2*(2*(2*(sin(sqrt(x))/(2*x)cos(sqrt(x))*(x2)/(8*x^(3/2)) 3*cos(sqrt(x))/(4*x^(3/2)) +3*sin(sqrt(x))*(x2)/(8*x^2) +3*sin(sqrt(x))/(4*x^2) +3*cos(sqrt(x))*(x2)/(8*x^(5/2)) +3*cos(sqrt(x))/(4*x^(5/2))) sin(sqrt(x))/(4*x)cos(sqrt(x))/(4*x^(3/2))) 2*(2*(sin(sqrt(x))*(8*sqrt(x)x^(3/2))/(8*x^(3/2)) +3*cos(sqrt(x))*(8*sqrt(x)x^(3/2))/(8*x^2) 3*sin(sqrt(x))*(8*sqrt(x)x^(3/2))/(8*x^(5/2)) cos(sqrt(x))*(3*x8)/(8*x^(3/2))+3*sin(sqrt(x))*(3*x8)/(8*x^2) +3*cos(sqrt(x))*(3*x8)/(8*x^(5/2)) 3*sin(sqrt(x))*(3/(4*sqrt(x))2/x^(3/2))/(2*sqrt(x)) 3*cos(sqrt(x))*(4/sqrt(x)3*sqrt(x)/2)/(4*x) 9*sin(sqrt(x))/(4*x) +3*sin(sqrt(x))*(4/sqrt(x)3*sqrt(x)/2)/(4*x^(3/2)) 9*cos(sqrt(x))/(4*x^(3/2)) +cos(sqrt(x))*(3/(8*x^(3/2))+3/x^(5/2))) +4*(sin(sqrt(x))/(2*x)cos(sqrt(x))*(x2)/(8*x^(3/2)) 3*cos(sqrt(x))/(4*x^(3/2)) +3*sin(sqrt(x))*(x2)/(8*x^2) +3*sin(sqrt(x))/(4*x^2) +3*cos(sqrt(x))*(x2)/(8*x^(5/2)) +3*cos(sqrt(x))/(4*x^(5/2))))) We have a small bug in scifac.lisp. It is easy to correct it: (%i7) gcfac(%); (%o7) 4*(2*((3*sin(sqrt(x))*(4/sqrt(x)3*sqrt(x)/2)*x/4 +cos(sqrt(x))*(315*x/8)) /x^(5/2) +((3*cos(sqrt(x))*(4/sqrt(x)3*sqrt(x)/2)/49*sin(sqrt(x))/4)*x 3*sin(sqrt(x))*(3*x/42)/2) /x^2 +(3*(sin(sqrt(x))/x^2+cos(sqrt(x))/x^(5/2))/8 cos(sqrt(x))/(8*x^(3/2))) *(3*x8) +(sin(sqrt(x))/(8*x)+3*cos(sqrt(x))/(8*x^(3/2)) 3*sin(sqrt(x))/(8*x^2)) *(8x) +2*(sin(sqrt(x))/(2*x)+cos(sqrt(x))*((x2)/83/4)/x^(3/2) +sin(sqrt(x))*(3*(x2)/8+3/4)/x^2 +cos(sqrt(x))*(3*(x2)/8+3/4)/x^(5/2))) +(sin(sqrt(x))/x+cos(sqrt(x))/x^(3/2))/4 +2*(sin(sqrt(x))/(2*x)+cos(sqrt(x))*((x2)/83/4)/x^(3/2) +sin(sqrt(x))*(3*(x2)/8+3/4)/x^2 +cos(sqrt(x))*(3*(x2)/8+3/4)/x^(5/2))) Of course ratsimp simplifies the expression immediately to the expected simple answer: (%i8) ratsimp(%); (%o8) sin(sqrt(x)) Dieter Kaiser  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2911891&group_id=4933 
From: SourceForge.net <noreply@so...>  20091213 21:11:13

Bugs item #767556, was opened at 20030708 07:00 Message generated for change (Comment added) made by crategus You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=767556&group_id=4933 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Lisp Core Group: None >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: Distributing operations over = Initial Comment: x * (a=b) => x*a = x*b x + (a=b) => x+a = x+b (a=b)^2 => a^2 = b^2 so why do we have x . (a=b) => x . (a=b) (??) rather than x . a = x . b (a=b)^^2 => (a=b)^^2 (??) etc. I do understand why we have f(a=b) => f(a=b) rather than f(a)=f(b) ... because in general f may be an operation on equations. Some operations nonetheless do distribute over "=", notably diff, taylor, limit, cabs, rectform, realpart, imagpart, etc. integrate is particularly clever, adding an integration constant though mathematical functions such as sin, log, etc. do not.  >Comment By: Dieter Kaiser (crategus) Date: 20091213 22:11 Message: The distribution over an equation has been implemented in mdot.lisp revision 1.9 for the operators "." and "^^". Closing this bug report as fixed. Dieter Kaiser  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=767556&group_id=4933 
From: SourceForge.net <noreply@so...>  20091213 19:28:35

Bugs item #2913752, was opened at 20091213 17:13 Message generated for change (Comment added) made by maxim You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2913752&group_id=4933 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Lisp Core  Plotting Group: None Status: Pending Resolution: Wont Fix Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: plot2d(a[x], [x,0,5]); STACK OVERFLOW Initial Comment: Tested on Maxima 5.18.1, Maxima 5.19.2 (with clisp 2.47 and 2.48), Maxima 5.20.0 (with clisp 2.47 and 2.48) on Gentoo Linux amd64. The same error occurs each time I try the following:  Maxima 5.20.0 http://maxima.sourceforge.net using Lisp CLISP 2.47 (20081023) 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) a[0] : 3; a[n] := 2*a[n1] 1; (%o1) 3 (%o2) a := 2 a  1 n n  1 (%i3) plot2d(a[x], [x,0,5]); ***  Program stack overflow. RESET [../src/eval.d:573] reset() found no driver frame (sp=0xb9d812100xb9d7ae40) Exiting on signal 6 Aborted  I know that you shouldn't try graphing discrete values like that but this is still a serious bug because it causes Maxima to crash and you lose all your session!. I noticed that the same bug was reported previously (http://sourceforge.net/tracker/index.php?func=detail&aid=1533584&group_id=4933&atid=104933) and closed but it's still here.  Comment By: m_a_xim (maxim) Date: 20091213 20:28 Message: I still find it very frustrating to lose a whole session (defined variables and functions) because of this. A program that ends with a stack overflow or segmentation fault  whatever the circumstances  has got a bug. I think most programmers would agree that user input should never be trusted and that errors in this input should be dealt with by gracefully telling the user that he made an error and giving him back control. It doesn't seem to me as though implementing a simple check to see if a function is defined for a certain value would be so difficult. Do you think it is acceptable if a TI (or Casio or whatever) calculator crashes losing all your session because you made a slight mistake in your input? And why would it be more acceptable for Maxima?  Comment By: Dieter Kaiser (crategus) Date: 20091213 18:32 Message: The reported problem is not a problem of the plot function. The recursively defined function can not handle floating point numbers which are needed for the plot function.: (%i1) a[0] : 3; a[n] := 2*a[n1] 1; (%o1) 3 (%o2) a[n]:=2*a[n1]1 We try to evaluate the function for a floating point number, but this is not possible. The algorithm of the function loops endlessly: (%i3) a[0.5]; ***  Program stack overflow. RESET [/build/buildd/clisp2.44.1/src/eval.d:527] reset() found no driver frame (sp=0xbfd464a00xbfd407b0) Exiting on signal 6 Aborted The user defined function has to be improved to handle floating point numbers to allow a plot. I think it is by the user to transfer a valid function definition to the plot routine. This problem is not related to the closed bug ID: 1533584. This bug seems to be no longer present. Setting the status to pending and the resolution to "wont fix". Dieter Kaiser  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2913752&group_id=4933 
From: SourceForge.net <noreply@so...>  20091213 18:16:15

Bugs item #2911891, was opened at 20091210 10:28 Message generated for change (Comment added) made by crategus You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2911891&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: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: gcfac gives Lisp error Initial Comment: a : diff(diff(diff(integrate(integrate(integrate(sin(sqrt(x)),x),x),x),x),x),x); load (scifac)$ gcfac(a); Maxima encountered a Lisp error: Error in AND [or a callee]: The function $MIN is undefined. Automatically continuing. To reenable the Lisp debugger set *debuggerhook* to nil.  >Comment By: Dieter Kaiser (crategus) Date: 20091213 19:16 Message: This example is a bit strange. The result should be sin(sqrt(x)), but we get: (%i6) diff(diff(diff(integrate(integrate(integrate(sin(sqrt(x)),x),x),x),x),x),x); (%o6) 2*(2*(2*(sin(sqrt(x))/(2*x)cos(sqrt(x))*(x2)/(8*x^(3/2)) 3*cos(sqrt(x))/(4*x^(3/2)) +3*sin(sqrt(x))*(x2)/(8*x^2) +3*sin(sqrt(x))/(4*x^2) +3*cos(sqrt(x))*(x2)/(8*x^(5/2)) +3*cos(sqrt(x))/(4*x^(5/2))) sin(sqrt(x))/(4*x)cos(sqrt(x))/(4*x^(3/2))) 2*(2*(sin(sqrt(x))*(8*sqrt(x)x^(3/2))/(8*x^(3/2)) +3*cos(sqrt(x))*(8*sqrt(x)x^(3/2))/(8*x^2) 3*sin(sqrt(x))*(8*sqrt(x)x^(3/2))/(8*x^(5/2)) cos(sqrt(x))*(3*x8)/(8*x^(3/2))+3*sin(sqrt(x))*(3*x8)/(8*x^2) +3*cos(sqrt(x))*(3*x8)/(8*x^(5/2)) 3*sin(sqrt(x))*(3/(4*sqrt(x))2/x^(3/2))/(2*sqrt(x)) 3*cos(sqrt(x))*(4/sqrt(x)3*sqrt(x)/2)/(4*x) 9*sin(sqrt(x))/(4*x) +3*sin(sqrt(x))*(4/sqrt(x)3*sqrt(x)/2)/(4*x^(3/2)) 9*cos(sqrt(x))/(4*x^(3/2)) +cos(sqrt(x))*(3/(8*x^(3/2))+3/x^(5/2))) +4*(sin(sqrt(x))/(2*x)cos(sqrt(x))*(x2)/(8*x^(3/2)) 3*cos(sqrt(x))/(4*x^(3/2)) +3*sin(sqrt(x))*(x2)/(8*x^2) +3*sin(sqrt(x))/(4*x^2) +3*cos(sqrt(x))*(x2)/(8*x^(5/2)) +3*cos(sqrt(x))/(4*x^(5/2))))) We have a small bug in scifac.lisp. It is easy to correct it: (%i7) gcfac(%); (%o7) 4*(2*((3*sin(sqrt(x))*(4/sqrt(x)3*sqrt(x)/2)*x/4 +cos(sqrt(x))*(315*x/8)) /x^(5/2) +((3*cos(sqrt(x))*(4/sqrt(x)3*sqrt(x)/2)/49*sin(sqrt(x))/4)*x 3*sin(sqrt(x))*(3*x/42)/2) /x^2 +(3*(sin(sqrt(x))/x^2+cos(sqrt(x))/x^(5/2))/8 cos(sqrt(x))/(8*x^(3/2))) *(3*x8) +(sin(sqrt(x))/(8*x)+3*cos(sqrt(x))/(8*x^(3/2)) 3*sin(sqrt(x))/(8*x^2)) *(8x) +2*(sin(sqrt(x))/(2*x)+cos(sqrt(x))*((x2)/83/4)/x^(3/2) +sin(sqrt(x))*(3*(x2)/8+3/4)/x^2 +cos(sqrt(x))*(3*(x2)/8+3/4)/x^(5/2))) +(sin(sqrt(x))/x+cos(sqrt(x))/x^(3/2))/4 +2*(sin(sqrt(x))/(2*x)+cos(sqrt(x))*((x2)/83/4)/x^(3/2) +sin(sqrt(x))*(3*(x2)/8+3/4)/x^2 +cos(sqrt(x))*(3*(x2)/8+3/4)/x^(5/2))) Of course ratsimp simplifies the expression immediately to the expected simple answer: (%i8) ratsimp(%); (%o8) sin(sqrt(x)) Dieter Kaiser  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2911891&group_id=4933 
From: SourceForge.net <noreply@so...>  20091213 17:50:12

Bugs item #2912391, was opened at 20091211 03:01 Message generated for change (Comment added) made by crategus You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2912391&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: Works For Me Priority: 5 Private: No Submitted By: Rudolf Vyborny (ynrobyvr) Assigned to: Nobody/Anonymous (nobody) Summary: wrong result Initial Comment: Calculating the limit of x+sqrt(1+x^2) as x goes to  infinity gives the wrong result inf instead of correct answer 0  >Comment By: Dieter Kaiser (crategus) Date: 20091213 18:50 Message: I am not sure about the notation of infinities which is used in this bug report. Maxima knows inf, minf, and infinity. infinity represents the complex infinity, inf and minf the real infinities.Furthermore, we have minf = inf. With these notations I get: (%i11) limit(x+sqrt(1+x^2),x,inf); (%o11) inf (%i12) limit(x+sqrt(1+x^2),x,inf); (%o12) 0 (%i13) limit(x+sqrt(1+x^2),x,minf); (%o13) 0 (%i14) limit(x+sqrt(1+x^2),x,infinity); (%o14) infinity I think all results from above are correct. Setting this bug report to pending and the status to "works for me". Dieter Kaiser  Comment By: Martin (mhs) Date: 20091211 10:05 Message: I cannot reproduce this on  Maxima version: 5.19.2 Maxima build date: 8:55 8/31/2009 host type: i686pcmingw32 lispimplementationtype: GNU Common Lisp (GCL) lispimplementationversion: GCL 2.6.8  (%i1) expr: x+sqrt(1+x^2); (%o1) sqrt(x^2+1)+x (%i2) limit(expr, x, inf); (%o2) 0 (%i3) limit(expr, x, minf); (%o3) 0  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2912391&group_id=4933 
From: SourceForge.net <noreply@so...>  20091213 17:39:49

Bugs item #2913614, was opened at 20091213 11:40 Message generated for change (Comment added) made by crategus You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2913614&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: Andrej Vodopivec (andrejv) Assigned to: Nobody/Anonymous (nobody) Summary: LAPACK: dgesvd is broken Initial Comment: (%i4) A:genmatrix(lambda([i,j], random(2.0)), 4, 4)$ (%i5) dgesvd(A); Maxima encountered a Lisp error: Error during processing of eval option "(cluser::run)": The value "G" is not of type (SIMPLEARRAY DOUBLEFLOAT (*)). Automatically continuing. To enable the Lisp debugger set *debuggerhook* to nil. (%i6) build_info(); Maxima version: 5.20post Maxima build date: 8:37 12/12/2009 Host type: i386appledarwin9.8.0 Lisp implementation type: SBCL Lisp implementation version: 1.0.19  >Comment By: Dieter Kaiser (crategus) Date: 20091213 18:39 Message: On my system I get: (%i2) build_info(); Maxima version: 5.20post Maxima build date: 17:36 12/13/2009 Host type: i686pclinuxgnu Lisp implementation type: CLISP Lisp implementation version: 2.44.1 (20080223) (built 3436700604) (memory 3469710995) (%o2) (%i3) A:genmatrix(lambda([i,j], random(2.0)), 4, 4)$ (%i4) dgesvd(A); (%o4) [[3.755933922081446, 1.830035687063915, .7142611635301948, 0.127875116930834], false, false] I do not get a Lisp error. But the result contains boolean values. Dieter Kaiser  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2913614&group_id=4933 
From: SourceForge.net <noreply@so...>  20091213 17:32:49

Bugs item #2913752, was opened at 20091213 17:13 Message generated for change (Comment added) made by crategus You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2913752&group_id=4933 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Lisp Core  Plotting Group: None >Status: Pending >Resolution: Wont Fix Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: plot2d(a[x], [x,0,5]); STACK OVERFLOW Initial Comment: Tested on Maxima 5.18.1, Maxima 5.19.2 (with clisp 2.47 and 2.48), Maxima 5.20.0 (with clisp 2.47 and 2.48) on Gentoo Linux amd64. The same error occurs each time I try the following:  Maxima 5.20.0 http://maxima.sourceforge.net using Lisp CLISP 2.47 (20081023) 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) a[0] : 3; a[n] := 2*a[n1] 1; (%o1) 3 (%o2) a := 2 a  1 n n  1 (%i3) plot2d(a[x], [x,0,5]); ***  Program stack overflow. RESET [../src/eval.d:573] reset() found no driver frame (sp=0xb9d812100xb9d7ae40) Exiting on signal 6 Aborted  I know that you shouldn't try graphing discrete values like that but this is still a serious bug because it causes Maxima to crash and you lose all your session!. I noticed that the same bug was reported previously (http://sourceforge.net/tracker/index.php?func=detail&aid=1533584&group_id=4933&atid=104933) and closed but it's still here.  >Comment By: Dieter Kaiser (crategus) Date: 20091213 18:32 Message: The reported problem is not a problem of the plot function. The recursively defined function can not handle floating point numbers which are needed for the plot function.: (%i1) a[0] : 3; a[n] := 2*a[n1] 1; (%o1) 3 (%o2) a[n]:=2*a[n1]1 We try to evaluate the function for a floating point number, but this is not possible. The algorithm of the function loops endlessly: (%i3) a[0.5]; ***  Program stack overflow. RESET [/build/buildd/clisp2.44.1/src/eval.d:527] reset() found no driver frame (sp=0xbfd464a00xbfd407b0) Exiting on signal 6 Aborted The user defined function has to be improved to handle floating point numbers to allow a plot. I think it is by the user to transfer a valid function definition to the plot routine. This problem is not related to the closed bug ID: 1533584. This bug seems to be no longer present. Setting the status to pending and the resolution to "wont fix". Dieter Kaiser  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2913752&group_id=4933 
From: SourceForge.net <noreply@so...>  20091213 16:13:50

Bugs item #2913752, was opened at 20091213 16:13 Message generated for change (Tracker Item Submitted) made by nobody You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2913752&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: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: plot2d(a[x], [x,0,5]); STACK OVERFLOW Initial Comment: Tested on Maxima 5.18.1, Maxima 5.19.2 (with clisp 2.47 and 2.48), Maxima 5.20.0 (with clisp 2.47 and 2.48) on Gentoo Linux amd64. The same error occurs each time I try the following:  Maxima 5.20.0 http://maxima.sourceforge.net using Lisp CLISP 2.47 (20081023) 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) a[0] : 3; a[n] := 2*a[n1] 1; (%o1) 3 (%o2) a := 2 a  1 n n  1 (%i3) plot2d(a[x], [x,0,5]); ***  Program stack overflow. RESET [../src/eval.d:573] reset() found no driver frame (sp=0xb9d812100xb9d7ae40) Exiting on signal 6 Aborted  I know that you shouldn't try graphing discrete values like that but this is still a serious bug because it causes Maxima to crash and you lose all your session!. I noticed that the same bug was reported previously (http://sourceforge.net/tracker/index.php?func=detail&aid=1533584&group_id=4933&atid=104933) and closed but it's still here.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2913752&group_id=4933 
From: SourceForge.net <noreply@so...>  20091213 10:42:35

Bugs item #2913610, was opened at 20091213 11:23 Message generated for change (Comment added) made by andrejv You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2913610&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: Fixed Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: plot error Initial Comment: build_info()$ Maxima version: 5.20.0 Maxima build date: 22:10 12/8/2009 Host type: i686pcmingw32 Lisp implementation type: GNU Common Lisp (GCL) Lisp implementation version: GCL 2.6.8 wxplot2d([sin(x)], [x,5,5])$ Error C:/Users/.../maxout_1.png  >Comment By: Andrej Vodopivec (andrejv) Date: 20091213 11:42 Message: This has been fixed in cvs and will work in the final 5.20 release.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2913610&group_id=4933 
From: SourceForge.net <noreply@so...>  20091213 10:41:02

Bugs item #2913614, was opened at 20091213 11:40 Message generated for change (Settings changed) made by andrejv You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2913614&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: Andrej Vodopivec (andrejv) Assigned to: Nobody/Anonymous (nobody) >Summary: LAPACK: dgesvd is broken Initial Comment: (%i4) A:genmatrix(lambda([i,j], random(2.0)), 4, 4)$ (%i5) dgesvd(A); Maxima encountered a Lisp error: Error during processing of eval option "(cluser::run)": The value "G" is not of type (SIMPLEARRAY DOUBLEFLOAT (*)). Automatically continuing. To enable the Lisp debugger set *debuggerhook* to nil. (%i6) build_info(); Maxima version: 5.20post Maxima build date: 8:37 12/12/2009 Host type: i386appledarwin9.8.0 Lisp implementation type: SBCL Lisp implementation version: 1.0.19  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2913614&group_id=4933 
From: SourceForge.net <noreply@so...>  20091213 10:40:42

Bugs item #2913614, was opened at 20091213 11:40 Message generated for change (Tracker Item Submitted) made by andrejv You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2913614&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: Andrej Vodopivec (andrejv) Assigned to: Nobody/Anonymous (nobody) Summary: LAPACK: dgesvn is broken Initial Comment: (%i4) A:genmatrix(lambda([i,j], random(2.0)), 4, 4)$ (%i5) dgesvd(A); Maxima encountered a Lisp error: Error during processing of eval option "(cluser::run)": The value "G" is not of type (SIMPLEARRAY DOUBLEFLOAT (*)). Automatically continuing. To enable the Lisp debugger set *debuggerhook* to nil. (%i6) build_info(); Maxima version: 5.20post Maxima build date: 8:37 12/12/2009 Host type: i386appledarwin9.8.0 Lisp implementation type: SBCL Lisp implementation version: 1.0.19  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2913614&group_id=4933 
From: SourceForge.net <noreply@so...>  20091213 10:23:17

Bugs item #2913610, was opened at 20091213 10:23 Message generated for change (Tracker Item Submitted) made by nobody You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2913610&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: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: plot error Initial Comment: build_info()$ Maxima version: 5.20.0 Maxima build date: 22:10 12/8/2009 Host type: i686pcmingw32 Lisp implementation type: GNU Common Lisp (GCL) Lisp implementation version: GCL 2.6.8 wxplot2d([sin(x)], [x,5,5])$ Error C:/Users/.../maxout_1.png  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2913610&group_id=4933 
From: SourceForge.net <noreply@so...>  20091213 02:20:25

Bugs item #1533584, was opened at 20060803 02:03 Message generated for change (Comment added) made by sfrobot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1533584&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: Works For Me Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: plot2d(sum(1/i,i,1,n),[n,1,10]) produces stack overflow Initial Comment: Executing "plot2d(sum(1/i,i,1,n), [n,1,10])" fails with "Unrecoverable error: bind stack overflow".  >Comment By: SourceForge Robot (sfrobot) Date: 20091213 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: Dieter Kaiser (crategus) Date: 20091129 01:48 Message: I think the problem has gone. I have no problems to get the plot with Maxima 5.19post. Settting the status to pending and "works for me". Dieter Kaiser  Comment By: Robert Dodier (robert_dodier) Date: 20060806 03:14 Message: Logged In: YES user_id=501686 plot2d assumes (unless told otherwise) that the expression to be plotted can be evaluated at any point within [1, 10]. However sum(1/i,i,1,n) is only welldefined for integer n. Perhaps you meant L1 : makelist (n, n, 1, 10); L2 : makelist (sum(1/i, i, 1, n), n, 1, 10); L2 : L2, numer; plot2d ([discrete, L1, L2]); Although "plot2d(sum(1/i,i,1,n), [n,1,10]); isn't valid, plot2d should try to do something smarter than stack overflow in that case.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1533584&group_id=4933 
From: SourceForge.net <noreply@so...>  20091213 02:20:24

Bugs item #2135806, was opened at 20080929 11:02 Message generated for change (Comment added) made by sfrobot 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: Closed Resolution: Wont Fix 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).  >Comment By: SourceForge Robot (sfrobot) Date: 20091213 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: Dieter Kaiser (crategus) Date: 20091128 23:56 Message: The substitution does not work as expected, because internally in Maxima the function realpart lives in two different forms: a noun form with the symbol %realpart and a verb form with the symbol $realpart. Because of this, we do not get the expected answer for the example of the bug report. The symbol 'realpart is passed with its noun form to the function subst. The verb function realpart(z) is evaluated (not simplified) to the internal noun form ((%realpart) $z). The substitution does not work, because subst distinguish the two forms: (%i1) declare(z,complex)$ (%i2) subst(lambda([s], (s + conjugate(s))/2), 'realpart, realpart(z)); (%o2) 'realpart(z) As written in the bug report a nounify helps. Again realpart(z) is evaluated to an internal noun form. Now we do not pass the verb form, but the symbol %realpart to subst: (%i3) subst(lambda([s], (s + conjugate(s))/2), nounify(realpart), realpart(z)); (%o3) (conjugate(z)+z)/2 We get the same result, when we prevent the evaluation of realpart(z) by quoting the function. Now only the verb form is present: (%i4) subst(lambda([s], (s + conjugate(s))/2), 'realpart, '(realpart(z))); (%o4) (conjugate(z)+z)/2 This behavior is different from simplifing functions like sin, cos, ... These functions only have one internal representation, that is a noun form. The "noun/verb confusion" is the expected behavior and is due to the implementation of functions like realpart. Perhaps, we can improve the documentation on this topic. I had no look at the code of subst. Perhaps, it is possible to do an implementation which ignores the noun/verb scheme for symbols. We could change the implementation of the function realpart and friends or we might modify the function subst. I think both ways are feature requests. Therefore, I would like to close this bug report. Dieter Kaiser  Comment By: Dieter Kaiser (crategus) Date: 20090110 23:53 Message: The reason for the different behavior is that the functions realpart() and imagpart() have not the property ALIAS like the functions sin() or cos(). The parser returns for the input 'realpart the symbol $realpart. For fully implemented simplifying functions the parser returns e.g. for the input cos the symbol %cos because of the property ALIAS. Unfortunately, the Lisp function risplitnoun introduces the symbols %realpart and %imagpart and realpart(z) simplifies to the expression ((%realpart) z). The function subst() does not work because of the different symbols. The call nounify(realpart) changes the verb form $realpart to the noun form %realpart and now it works again. This behavior can be changed when we do not use the symbol %realpart but change the function risplitnoun like: (defun risplitnoun (l) (cons (list '($realpart) l) (list '($imagpart) l))) A noun which is declared to be complex now gives the expression: (($REALPART SIMP) $Z) The original code does a simplify, but I think this is not possible for the whole expression (we loop endlessly) and not necessary for the argument l. We get the correct expression from the simplifier. We have to change the symbols %realpart and %imagpart at about 5 places in the whole code. The testsuite has no problems with this changes. With this change the example will work as expected: (%i25) subst(lambda([s], (s + conjugate(s))/2), 'realpart, realpart(z)); (%o25) (conjugate(z)+z)/2 Remark: With the original code and the changed code we get: 'realpart(x+%i*y); 'realpart(x+%i*y) /* intern ((%realpart) .... ) */ In this case the parser returns the symbol %realpart. Because realpart() is not a simplifying function Maxima can not further simplify this expression e.g. rectform('realpart(1)); realpart(1) So what do you think? Should we change %realpart to $realpart in risplitnoun. Perhaps later we can introduce a simplifying function realpart(). Dieter Kaiser  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2135806&group_id=4933 