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}
(47) 
_{Aug}

_{Sep}

_{Oct}

_{Nov}

_{Dec}

S  M  T  W  T  F  S 







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

10
(5) 
11
(3) 
12

13

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

22
(7) 
23
(1) 
24
(1) 
25
(1) 
26
(2) 
27

28
(1) 
29

30
(1) 






From: SourceForge.net <noreply@so...>  20070930 17:36:34

Bugs item #1805179, was opened at 20070930 10:36 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1805179&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: fatal error: Integral calculation failure Initial Comment: (%i1) f(x):=sin(x); (%o1) f(x) := sin(x) (%i2) xx: create_list(i, i, 0, 3); (%o2) [0, 1, 2, 3] (%i3) fi(x):= quad_qags(f(xx), xx, 0, x); (%o3) fi(x) := quad_qags(f(xx), xx, 0, x) (%i4) maplist(lambda([L], fi(L)), xx); Maxima encountered a Lisp error: Error in PROGN [or a callee]: Caught fatal error [memory may be damaged] Automatically continuing. To reenable the Lisp debugger set *debuggerhook* to nil. (%i5) maplist(lambda([L], fi(L)), xx); Segmentation fault  Additional information: Maxima version: 5.13.0 Maxima build date: 1:22 9/30/2007 host type: i686pclinuxgnu lispimplementationtype: GNU Common Lisp (GCL) lispimplementationversion: GCL 2.6.7  I've found that everything works fine if assign %i2 statement to a variable with another name. But I still belive that it's an error.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1805179&group_id=4933 
From: SourceForge.net <noreply@so...>  20070928 00:01:44

Bugs item #702504, was opened at 20030312 15:56 Message generated for change (Comment added) made by dgildea You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=702504&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  Taylor Group: None >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: taylor(exp(%i*x),x,inf,1) => interr Initial Comment: (C2) taylor(exp(%i*x),x,inf,1); Error: $x is not of type LIST. True, Inf is an essential singularity for this function, but (a) it still shouldn't give an internal error and (b) it does just fine with taylor(exp(x),x,inf,1).  >Comment By: Dan Gildea (dgildea) Date: 20070927 20:01 Message: Logged In: YES user_id=1797506 Originator: NO works in current cvs. (%i4) taylor(exp(%i*x), x, inf, 1); (%o4)/T/ %i sin(x) + . . . + cos(x) + . . .  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=702504&group_id=4933 
From: SourceForge.net <noreply@so...>  20070926 13:13:39

Bugs item #1633108, was opened at 20070111 12:52 Message generated for change (Comment added) made by andrejv You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1633108&group_id=4933 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Lisp Core Group: None >Status: Closed Resolution: None Priority: 5 Private: No Submitted By: Barton Willis (willisbl) Assigned to: Nobody/Anonymous (nobody) Summary: infinite sums with simpsum : true Initial Comment: Should be inf, not inf  1: (%i2) sum(exp(k),k,minf,inf),simpsum; (%o2) inf1 I think 'und' is a better value for this sum: (%i3) sum(k,k,minf,inf),simpsum; (%o3) 0 Should be 'und', not 'undefined': (%i4) sum((1)^k,k,0,inf),simpsum; (%o4) undefined Again, should be 'und' (%i5) sum((1)^k,k,minf,inf),simpsum; (%o5) undefined1 At least limit(und1) > und, but limit(undefined1) > undefined1.  >Comment By: Andrej Vodopivec (andrejv) Date: 20070926 15:13 Message: Logged In: YES user_id=1179910 Originator: NO Fixed in cvs: (%i2) sum(exp(k),k,minf,inf),simpsum; (%o2) inf (%i3) sum(k,k,minf,inf),simpsum; (%o3) und (%i4) sum((1)^k,k,0,inf),simpsum; (%o4) und (%i5) sum((1)^k,k,minf,inf),simpsum; (%o5) und Andrej  Comment By: Andrej Vodopivec (andrejv) Date: 20070120 09:36 Message: Logged In: YES user_id=1179910 Originator: NO Compare the following (%i1) integrate(x, x, 0, inf); Integral is divergent  an error. Quitting. To debug this try debugmode(true); (%i2) sum(k, k, 0, inf), simpsum; (%o2) inf Since maxima is not very good with infinities (that is infinf = 0 and inf/inf=1), sum should signal an error instead of returning inf for divergent sums. Andrej  Comment By: Robert Dodier (robert_dodier) Date: 20070113 02:27 Message: Logged In: YES user_id=501686 Originator: NO Maybe 1argument limit should be called to clean up results of infinite summations. Although limit has its own problems so I am hesitant about that ...  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1633108&group_id=4933 
From: SourceForge.net <noreply@so...>  20070926 13:12:17

Bugs item #1638491, was opened at 20070118 12:39 Message generated for change (Comment added) made by andrejv You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1638491&group_id=4933 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Lisp Core Group: None >Status: Closed Resolution: None Priority: 5 Private: No Submitted By: Barton Willis (willisbl) Assigned to: Nobody/Anonymous (nobody) Summary: simpsum and und geometric sum Initial Comment: (%i39) sum((12/10)^k,k,0,inf),simpsum; (%o39) inf < should be und Related problem: (%i42) sum((12/10)^k,k,0,inf) / sum((12/10)^k,k,0,inf),simpsum; (%o42) 1 < should be und  >Comment By: Andrej Vodopivec (andrejv) Date: 20070926 15:11 Message: Logged In: YES user_id=1179910 Originator: NO Fixed in cvs: (%i2) sum((12/10)^k,k,0,inf),simpsum; (%o2) und (%i3) sum((12/10)^k,k,0,inf) / sum((12/10)^k,k,0,inf),simpsum; (%o3) inf/und (%i4) limit(%); (%o4) und %o3 is not simplified to und but this is not a problem with sum. Andrej  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1638491&group_id=4933 
From: SourceForge.net <noreply@so...>  20070925 08:54:02

Bugs item #1799012, was opened at 20070920 12:40 Message generated for change (Comment added) made by willisbl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1799012&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: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: complex sin returns 0.0*%i Initial Comment: sin(1+%i*1e100) => 0.0*%i + 0.84 expand(%) => 0.84 The 0.0*%i should have simplified to 0.0. Presumably the code is consing up the answer without calling the simplifier (of course, in this case, it could specialcase the 0.0 check).  >Comment By: Barton Willis (willisbl) Date: 20070925 03:54 Message: Logged In: YES user_id=895922 Originator: NO The function 'complexify' (defined in ellipt.lisp) doesn't call the simplifier on a sum. Here is a possible replacement (defun complexify (x) (if (realp x) x (add (realpart x) (mul '$%i (imagpart x))))) If the input isn't a CL float or complex, should complexify signal an error?  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1799012&group_id=4933 
From: SourceForge.net <noreply@so...>  20070924 16:03:07

Bugs item #1801287, was opened at 20070924 12:03 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1801287&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: Open Resolution: None Priority: 5 Private: No Submitted By: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: 1arg limit infinite loop Initial Comment: limit( (inf*(inf+1))/((inf+2)/(inf+3)) ) runs for a very long (infinite?) time. It should be able to return UND quickly, the way smaller examples do.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1801287&group_id=4933 
From: SourceForge.net <noreply@so...>  20070923 16:41:57

Bugs item #1797296, was opened at 20070918 14:00 Message generated for change (Settings changed) made by robert_dodier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1797296&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: Open Resolution: None Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Crazy results when doing limit of 'diff Initial Comment: Maxima version: 5.13.0Maxima build date: 15:45 9/16/2007host type: i586pclinuxgnulispimplementationtype: CLISPlispimplementationversion: 2.41 (20061013) (built 3380066971) (memory 3398964343) Maxima returns crazy results when evaluating the limit of an unevaluated derivative: Examples: limit('diff((x+1)/(x^21),x),x,1); limit('diff((x+1),x),x,1); limit('diff((x+n),x),x,1); Not only is the "with respect to" variable in the demoninator of the result wrong, i.e., d/d(x+1), but the limiting value of the variable is wrong. The limit was supposed to as x > 1, but the output shows the limit as x>0  reporter's email: joe.vender AT owensboro.net  Comment By: Stavros Macrakis (macrakis) Date: 20070920 11:34 Message: Logged In: YES user_id=588346 Originator: NO The original bug is valid. A simple case: limit('diff(y,x),x,1) => 'limit('diff(y,x+1,1),x,0) The followup comment is confused. The syntax (..., ..., ...) in Maxima evaluates each of the elements of the list and returns the last value. This is the correct behavior.  Comment By: Nobody/Anonymous (nobody) Date: 20070918 14:45 Message: Logged In: NO also; limit(('diff(x^n),x),x,1); returns 1. Notice the mismatch of the parentheses. The problem lies in that adding ",x" after 'diff(x^n) and putting parentheses around the whole expression returns whatever is put after the comma instead of (del(x^n),x). Ex. 'diff(x^n) returns del(x^n) ('diff(x^n),x) returns x ('diff(x^n),abc) returns abc which is then evaluated by the limit function. It appears that when entering something like (f(x),f(y)) maxima always outputs f(y)  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1797296&group_id=4933 
From: SourceForge.net <noreply@so...>  20070922 16:53:24

Bugs item #611411, was opened at 20020919 00:18 Message generated for change (Comment added) made by dgildea You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=611411&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 asks sign of IND Initial Comment: limit(abs(sin(x)),x,inf) foolishly asks the user Is IND positive, negative, or zero? Moreover, if the user foolishly replies zero, Maxima gets into an infinite loop! (Note that the only case where Limit(abs(IND)) should not return IND is if the limit set consists exactly of { x ,  x } for some x. This does happen, it is true, but Limit has far less subtle bugs.... Yes, I know, single argument Limit only handles the various INFs, not IND and UND.)  >Comment By: Dan Gildea (dgildea) Date: 20070922 12:53 Message: Logged In: YES user_id=1797506 Originator: NO fixed in limit.lisp rev 1.41 (%i4) limit(abs(sin(x)),x,inf); (%o4) ind See also bug 1629723.  Comment By: Robert Dodier (robert_dodier) Date: 20060626 14:27 Message: Logged In: YES user_id=501686 Observed in 5.9.3. This may be due in some part to a bug or wart in asksign  if asksign is asked about ind, it may see that ind is neither pos nor neg nor zero & therefore ask the user about ind. Seems like asksign should return ind. But that in turn supposes that the caller knows how to cope with a ind return value. Just a thought.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=611411&group_id=4933 
From: SourceForge.net <noreply@so...>  20070922 16:49:55

Bugs item #1629723, was opened at 20070107 01:15 Message generated for change (Comment added) made by dgildea You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1629723&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: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: bug in limit, asks sign of IND, encountered in integrator Initial Comment: quoted from the mailing list: On 12/11/06, Daniel Lakeland <dlakelan@...> wrote: >integrate(abs(sin(x)/x),x,0,inf) asks the seemingly stupid question: >Is ind positive, negative, or zero? > >the user has absolutely no idea what maxima is asking... I'm going to >assume that it has something to do with a change of variable deep >within the integrator... but it's completely opaque to me. This is definitely a bug, and should be reported. Integrate is calling limit, and the bug is actually in the limit routine: limit( abs(sin(x))/x , x , inf) => asks sign of ind IND is supposed to be used by Limit as a return value meaning that the limit set is bounded, e.g. limit(sin(x),x,inf) => ind, but obviously here it's gotten its wires crossed. I suggest you write up the limit bug with a note that definite integration encounters it.  >Comment By: Dan Gildea (dgildea) Date: 20070922 12:49 Message: Logged In: YES user_id=1797506 Originator: NO oops, sorry. in limit.lisp rev 1.41: limit(abs(sin(x))/x, x, inf) => 0 however: limit(abs(sin(x))/sin(x), x, inf) => 1 still not correct  Comment By: Raymond Toy (rtoy) Date: 20070922 10:56 Message: Logged In: YES user_id=28849 Originator: NO Why is limit(abs(sin(x))/x, x, inf) ind? Shouldn't it be zero? abs(sin(x))/x is surely bounded between 0 and 1/x. Am I missing something? Reopening.  Comment By: Dan Gildea (dgildea) Date: 20070922 10:47 Message: Logged In: YES user_id=1797506 Originator: NO Fixed in limit.lisp rev 1.40. (%i3) limit( abs(sin(x))/x , x , inf) ; (%o3) ind  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1629723&group_id=4933 
From: SourceForge.net <noreply@so...>  20070922 14:56:10

Bugs item #1629723, was opened at 20070107 01:15 Message generated for change (Comment added) made by rtoy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1629723&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: Open >Resolution: None Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: bug in limit, asks sign of IND, encountered in integrator Initial Comment: quoted from the mailing list: On 12/11/06, Daniel Lakeland <dlakelan@...> wrote: >integrate(abs(sin(x)/x),x,0,inf) asks the seemingly stupid question: >Is ind positive, negative, or zero? > >the user has absolutely no idea what maxima is asking... I'm going to >assume that it has something to do with a change of variable deep >within the integrator... but it's completely opaque to me. This is definitely a bug, and should be reported. Integrate is calling limit, and the bug is actually in the limit routine: limit( abs(sin(x))/x , x , inf) => asks sign of ind IND is supposed to be used by Limit as a return value meaning that the limit set is bounded, e.g. limit(sin(x),x,inf) => ind, but obviously here it's gotten its wires crossed. I suggest you write up the limit bug with a note that definite integration encounters it.  >Comment By: Raymond Toy (rtoy) Date: 20070922 10:56 Message: Logged In: YES user_id=28849 Originator: NO Why is limit(abs(sin(x))/x, x, inf) ind? Shouldn't it be zero? abs(sin(x))/x is surely bounded between 0 and 1/x. Am I missing something? Reopening.  Comment By: Dan Gildea (dgildea) Date: 20070922 10:47 Message: Logged In: YES user_id=1797506 Originator: NO Fixed in limit.lisp rev 1.40. (%i3) limit( abs(sin(x))/x , x , inf) ; (%o3) ind  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1629723&group_id=4933 
From: SourceForge.net <noreply@so...>  20070922 14:50:14

Bugs item #1666354, was opened at 20070222 12:31 Message generated for change (Comment added) made by dgildea You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1666354&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: Raymond Toy (rtoy) Assigned to: Nobody/Anonymous (nobody) Summary: limit(gamma(1/x)*sin(%pi/(2*x))/x,x,inf) wrong Initial Comment: limit(gamma(1/x)*sin(%pi/(2*x))/x,x,inf) returns a noun form. tlimit returns 0, which is right.  >Comment By: Dan Gildea (dgildea) Date: 20070922 10:50 Message: Logged In: YES user_id=1797506 Originator: NO Fixed by new tlimswitch behavior  see bug 1665657. (%i4) limit(gamma(1/x)*sin(%pi/(2*x))/x,x,inf) ; (%o4) 0  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1666354&group_id=4933 
From: SourceForge.net <noreply@so...>  20070922 14:47:38

Bugs item #1629723, was opened at 20070107 01:15 Message generated for change (Comment added) made by dgildea You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1629723&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: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: bug in limit, asks sign of IND, encountered in integrator Initial Comment: quoted from the mailing list: On 12/11/06, Daniel Lakeland <dlakelan@...> wrote: >integrate(abs(sin(x)/x),x,0,inf) asks the seemingly stupid question: >Is ind positive, negative, or zero? > >the user has absolutely no idea what maxima is asking... I'm going to >assume that it has something to do with a change of variable deep >within the integrator... but it's completely opaque to me. This is definitely a bug, and should be reported. Integrate is calling limit, and the bug is actually in the limit routine: limit( abs(sin(x))/x , x , inf) => asks sign of ind IND is supposed to be used by Limit as a return value meaning that the limit set is bounded, e.g. limit(sin(x),x,inf) => ind, but obviously here it's gotten its wires crossed. I suggest you write up the limit bug with a note that definite integration encounters it.  >Comment By: Dan Gildea (dgildea) Date: 20070922 10:47 Message: Logged In: YES user_id=1797506 Originator: NO Fixed in limit.lisp rev 1.40. (%i3) limit( abs(sin(x))/x , x , inf) ; (%o3) ind  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1629723&group_id=4933 
From: SourceForge.net <noreply@so...>  20070922 14:42:28

Bugs item #782099, was opened at 20030802 17:29 Message generated for change (Comment added) made by dgildea You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=782099&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 returns expression in IND Initial Comment: limit(sinh(exp(%i*x)),x,inf) => (%E^IND%E^IND)/2 should be just IND This may be related to limit(%e^ind) not giving IND.  >Comment By: Dan Gildea (dgildea) Date: 20070922 10:42 Message: Logged In: YES user_id=1797506 Originator: NO fixed in limit.lisp rev 1.40 (%i1) limit(sinh(exp(%i*x)),x,inf); (%o1) ind  Comment By: Robert Dodier (robert_dodier) Date: 20060708 14:12 Message: Logged In: YES user_id=501686 See also bug report # 1515430 und not propagated through functions.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=782099&group_id=4933 
From: SourceForge.net <noreply@so...>  20070922 02:20:13

Bugs item #1787111, was opened at 20070903 07:04 Message generated for change (Comment added) made by sfrobot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1787111&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: Problem not in Maxima Group: None >Status: Closed Resolution: Wont Fix Priority: 5 Private: No Submitted By: Abel Pascual (abelpascual) Assigned to: Nobody/Anonymous (nobody) Summary: Floating point imprecission Initial Comment: I don't understand why Maxima rounds down the number... I'm currently running Ubuntu 7.04. Maxima 5.13.0 http://maxima.sourceforge.net Using Lisp GNU Common Lisp (GCL) GCL 2.6.7 (aka GCL) Distributed under the GNU Public License. See the file COPYING. Dedicated to the memory of William Schelter. This is a development version of Maxima. The function bug_report() provides bug reporting information. (%i1) 4.6*10^8; (%o1) 4.5999999999999994E+8  >Comment By: SourceForge Robot (sfrobot) Date: 20070921 19:20 Message: Logged In: YES user_id=1312539 Originator: NO 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: 20070910 08:31 Message: Logged In: YES user_id=28849 Originator: NO Aargh! I completely misread the problem. This whole discussion has been about 4.6e8. But the original problem is 4.6*10^8, which is completely different. 4.6 isn't exactly representable as a float The printed result is, as best as I can tell, the correct answer. However, the issue with clisp printing 4.6e8 incorrectly is still valid. Same with the bug in gcl. Perhaps we should just leave exploden as is.  Comment By: Robert Dodier (robert_dodier) Date: 20070908 12:23 Message: Logged In: YES user_id=501686 Originator: NO Ray, it's OK by me if you want to modify EXPLODEN to treat fpprintprec = 0 as a special case.  Comment By: Raymond Toy (rtoy) Date: 20070908 11:36 Message: Logged In: YES user_id=28849 Originator: NO There is one thing we could do: If fpprintprec is 0, we want to print everything, so in that case ,we might use ~a. If fpprintprec is something else, we use ~e. This will probablly fix the immediate issue. I assume most people leave fpprintprec defaulted.  Comment By: Robert Dodier (robert_dodier) Date: 20070907 17:32 Message: Logged In: YES user_id=501686 Originator: NO Reported the bug (format nil "~ve" 21 46d7) => 4.5999999999999996d+8 as SF bug report # 1790496 for Clisp. http://sourceforge.net/tracker/index.php?func=detail&aid=1790496&group_id=1355&atid=101355 I think we can close this Maxima bug report now since both of problems observed are problems in Lisp implementations. Marking this report as "won't fix" and "pending" (to be closed automatically in 2 weeks) accordingly.  Comment By: Robert Dodier (robert_dodier) Date: 20070907 07:51 Message: Logged In: YES user_id=501686 Originator: NO Ray, I think you are correct on both counts: changing e to a or d shouldn't help, the format indicator should remain e; and the Clisp output in this case (format nil "~ve" 21 46d7) indicates a bug in Clisp. You or I can report the Clisp bug, whoever gets to it first, and then we can close this report, I think.  Comment By: Raymond Toy (rtoy) Date: 20070906 20:22 Message: Logged In: YES user_id=28849 Originator: NO I'm mistaken. Using ~a won't work (which implies ~d won't work either). Consider if fpprintprec is 2. Then (format t "~7a" 1.2345678d9) > 1.2345678d9 But (format t "~7e" 1.2345678d9) > 1.23d8 We need to do something else.  Comment By: Raymond Toy (rtoy) Date: 20070906 19:56 Message: Logged In: YES user_id=28849 Originator: NO We should probably file a bug report for clisp for item 2. Changing ~e to ~d is ok, but ~d is really ~a, so we should just use ~a. There is a difference, however. ~e pads numbers on the left and ~a pads on the right.t. DDoDont' know if that matters or not. In addition, cmucl has a known bug that ~e prints numbers differently from ~a (princ). ~a is more accurate.  Comment By: Robert Dodier (robert_dodier) Date: 20070906 19:06 Message: Logged In: YES user_id=501686 Originator: NO (1) I've reported GCL's failure to parse 4.6e8 correctly to the GCL bug tracker as # 20992. https://savannah.gnu.org/bugs/index.php?20992 So as for this 4.6e8 in Maxima + GCL, we can close it because the problem is not in Maxima. (2) About Clisp printing 46e7 as 4.5999999999999996E+8, it appears that Clisp is interpreting "~ve" to indicate a coercion to singlefloat before formatting it. Changing the "~ve" to "~vd" in EXPLODEN in src/commac.lisp appears to tell Clisp to format 46e7 as 4.6E8. SBCL and GCL are happy with "~vd". Leaving this report open to gather comments on item (2). If nobody is opposed, I'll modify EXPLODEN as described above.  Comment By: Raymond Toy (rtoy) Date: 20070905 07:20 Message: Logged In: YES user_id=28849 Originator: NO Good question. I wasn't sure, so I checked the code. Look at makenumber and readlist in nparse.lisp. If the number is not a bigfloat, readlist is called, which basically calls Lisp readfromstring to read "4.6e8". So the result depends on the underlying Lisp. All Lisps should say (floor 4.6d8) is 46000000 and 0.0d0. Clisp and cmucl do. gcl does not. We could implement our own reader. However, for a bigfloat, maxima sees 4.6, converts it to 46/10 and then multiplies by 10^8 to get a rational number. This is then converted to a bigfloat. I think 21 is because we want upto 16 digits printed, and the 5 is to make sure there's space to print the exponent marker, a sign, and the exponent itself (3 digits). If 16 is used, the number of significant digits would be too small. I think it is a bug in gcl and clisp that it prints something other than 4.6d8.  Comment By: Andrej Vodopivec (andrejv) Date: 20070905 00:27 Message: Logged In: YES user_id=1179910 Originator: NO I don't think 4.6*10^8 is parsed as one number. First 4.6 is parsed, then 10^8, and then they are multiplied. To enter 4.6e8 you should enter it as 4.6e8. OTOH, 4.6e8 is not printed correctly on clisp and gcl. The reason is that floats are printed with (format nil "~ve" 21 4.6e8) I think 21 is arbitrarily chosen  if it was 19, all lisps print it correctly, but then maybe some other example would be printed incorrectly. Why don't we just use (format nil "~ve" 16 4.6e8). Andrej  Comment By: Raymond Toy (rtoy) Date: 20070904 11:47 Message: Logged In: YES user_id=28849 Originator: NO The issues you see with GCL and CLISP are somewhat related, but outside the scope of this bug. If you want to discuss it further, I'd be happy to. Just not here. Please mail me directly or, even better, use the maxima mailing list.  Comment By: Abel Pascual (abelpascual) Date: 20070904 10:50 Message: Logged In: YES user_id=1881850 Originator: YES I don't know if there is any relation, but in GCL I'm having the same issue: >(* 4.6 (expt 10 8)) 4.5999999999999994E8 But otherwise in CLISP this is not happening: [1]> (* 4.6 (expt 10 8)) 4.6E8  Comment By: Raymond Toy (rtoy) Date: 20070904 10:11 Message: Logged In: YES user_id=28849 Originator: NO Actually 4.6e8 is an integer: 460000000. This should be exactly representable as a doublefloat. I think it is an error that maxima prints something else out. Reopening this bug.  Comment By: Abel Pascual (abelpascual) Date: 20070903 14:37 Message: Logged In: YES user_id=1881850 Originator: YES Ok, sorry for my mistake, and thanks for your explanation...  Comment By: Harald Geyer (hgeyer) Date: 20070903 13:12 Message: Logged In: YES user_id=929336 Originator: NO Hi Abel! Thanks for you interest in maxima. The behaviour, that you see is a basic property of fixed precision floating point numbers (maxima acutally is using maschine doubles IIRC): The number 4.6e8 is not representable exactly in base 2 arithmetic, thus maxima rounds the number to the next number that can be represented as double float. If you need higher precision, you can use bfloats: 4.6b8 If you want exact numbers, you can use rational arithmetic. In this case enter the number as: 46*10^7 (that is: without decimal dot) If you still have questions, you might ask on the Mailinglist. I'm closing your bug report now, because this is nothing we can fix in maxima.  Comment By: Abel Pascual (abelpascual) Date: 20070903 07:06 Message: Logged In: YES user_id=1881850 Originator: YES Greetings  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1787111&group_id=4933 
From: SourceForge.net <noreply@so...>  20070920 17:40:31

Bugs item #1799012, was opened at 20070920 13:40 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1799012&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: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: complex sin returns 0.0*%i Initial Comment: sin(1+%i*1e100) => 0.0*%i + 0.84 expand(%) => 0.84 The 0.0*%i should have simplified to 0.0. Presumably the code is consing up the answer without calling the simplifier (of course, in this case, it could specialcase the 0.0 check).  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1799012&group_id=4933 
From: SourceForge.net <noreply@so...>  20070920 17:34:52

Bugs item #1797296, was opened at 20070918 16:00 Message generated for change (Comment added) made by macrakis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1797296&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: Crazy results when doing limit of 'diff Initial Comment: Maxima version: 5.13.0Maxima build date: 15:45 9/16/2007host type: i586pclinuxgnulispimplementationtype: CLISPlispimplementationversion: 2.41 (20061013) (built 3380066971) (memory 3398964343) Maxima returns crazy results when evaluating the limit of an unevaluated derivative: Examples: limit('diff((x+1)/(x^21),x),x,1); limit('diff((x+1),x),x,1); limit('diff((x+n),x),x,1); Not only is the "with respect to" variable in the demoninator of the result wrong, i.e., d/d(x+1), but the limiting value of the variable is wrong. The limit was supposed to as x > 1, but the output shows the limit as x>0  reporter's email: joe.vender AT owensboro.net  >Comment By: Stavros Macrakis (macrakis) Date: 20070920 13:34 Message: Logged In: YES user_id=588346 Originator: NO The original bug is valid. A simple case: limit('diff(y,x),x,1) => 'limit('diff(y,x+1,1),x,0) The followup comment is confused. The syntax (..., ..., ...) in Maxima evaluates each of the elements of the list and returns the last value. This is the correct behavior.  Comment By: Nobody/Anonymous (nobody) Date: 20070918 16:45 Message: Logged In: NO also; limit(('diff(x^n),x),x,1); returns 1. Notice the mismatch of the parentheses. The problem lies in that adding ",x" after 'diff(x^n) and putting parentheses around the whole expression returns whatever is put after the comma instead of (del(x^n),x). Ex. 'diff(x^n) returns del(x^n) ('diff(x^n),x) returns x ('diff(x^n),abc) returns abc which is then evaluated by the limit function. It appears that when entering something like (f(x),f(y)) maxima always outputs f(y)  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1797296&group_id=4933 
From: SourceForge.net <noreply@so...>  20070919 00:43:23

Bugs item #1665657, was opened at 20070221 17:30 Message generated for change (Comment added) made by dgildea You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1665657&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: Robert Dodier (robert_dodier) Assigned to: Nobody/Anonymous (nobody) Summary: limit fails to find easy limit Initial Comment: limit(x/(x1)1/log(x),x,1,plus); => 'limit(x1/log(1/x+1)+1,x,inf) But Maxima can handle this with a little encouragement: tlimit(x/(x1)1/log(x),x,1,plus) => 1/2 limit(ratsimp(x/(x1)1/log(x)),x,1,plus) => 1/2 Reported on mailing list 2007/02/21.  >Comment By: Dan Gildea (dgildea) Date: 20070918 20:43 Message: Logged In: YES user_id=1797506 Originator: NO Changed behavior of limit command in cvs as follows:  tlimswitch true by default  limit uses taylor expansion only after simple limit fails and only if tlimswitch is true as before:  no taylor expansion if tlimswitch is false  tlimit always does taylor expansion This change consists of following diffs: maxima/doc/info Limits.texi,1.11,1.12 maxima/tests rtest16.mac, 1.29, 1.30 testsuite.lisp, 1.59, 1.60 maxima/src csimp.lisp, 1.14, 1.15 limit.lisp, 1.38, 1.39 tlimit.lisp, 1.5, 1.6  Comment By: Stavros Macrakis (macrakis) Date: 20070222 13:40 Message: Logged In: YES user_id=588346 Originator: NO My reporting error. Actually: limit(ratsimp(x/(x1)1/log(x)),x,1,plus) fails though limit(ratsimp(x/(x1)1/log(x)),x,1) => 1/2 Clearly if the twosided limit exists, the onesided limits must be equal to it....  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1665657&group_id=4933 
From: SourceForge.net <noreply@so...>  20070918 20:45:35

Bugs item #1797296, was opened at 20070918 13:00 Message generated for change (Comment added) made by nobody You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1797296&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: Crazy results when doing limit of 'diff Initial Comment: Maxima version: 5.13.0Maxima build date: 15:45 9/16/2007host type: i586pclinuxgnulispimplementationtype: CLISPlispimplementationversion: 2.41 (20061013) (built 3380066971) (memory 3398964343) Maxima returns crazy results when evaluating the limit of an unevaluated derivative: Examples: limit('diff((x+1)/(x^21),x),x,1); limit('diff((x+1),x),x,1); limit('diff((x+n),x),x,1); Not only is the "with respect to" variable in the demoninator of the result wrong, i.e., d/d(x+1), but the limiting value of the variable is wrong. The limit was supposed to as x > 1, but the output shows the limit as x>0  reporter's email: joe.vender AT owensboro.net  Comment By: Nobody/Anonymous (nobody) Date: 20070918 13:45 Message: Logged In: NO also; limit(('diff(x^n),x),x,1); returns 1. Notice the mismatch of the parentheses. The problem lies in that adding ",x" after 'diff(x^n) and putting parentheses around the whole expression returns whatever is put after the comma instead of (del(x^n),x). Ex. 'diff(x^n) returns del(x^n) ('diff(x^n),x) returns x ('diff(x^n),abc) returns abc which is then evaluated by the limit function. It appears that when entering something like (f(x),f(y)) maxima always outputs f(y)  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1797296&group_id=4933 
From: SourceForge.net <noreply@so...>  20070918 20:00:13

Bugs item #1797296, was opened at 20070918 13:00 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1797296&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: Crazy results when doing limit of 'diff Initial Comment: Maxima version: 5.13.0Maxima build date: 15:45 9/16/2007host type: i586pclinuxgnulispimplementationtype: CLISPlispimplementationversion: 2.41 (20061013) (built 3380066971) (memory 3398964343) Maxima returns crazy results when evaluating the limit of an unevaluated derivative: Examples: limit('diff((x+1)/(x^21),x),x,1); limit('diff((x+1),x),x,1); limit('diff((x+n),x),x,1); Not only is the "with respect to" variable in the demoninator of the result wrong, i.e., d/d(x+1), but the limiting value of the variable is wrong. The limit was supposed to as x > 1, but the output shows the limit as x>0  reporter's email: joe.vender AT owensboro.net  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1797296&group_id=4933 
From: SourceForge.net <noreply@so...>  20070917 19:44:31

Bugs item #609466, was opened at 20020914 23:26 Message generated for change (Comment added) made by macrakis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=609466&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  Solving equations Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: Fatal error in solve/algsys Initial Comment: solve( [ a^2+b^2+c^21, c*f+b*d+a*b, c*g+b*f+a*c, c*f+b*d+a*b, b^2+d^2+f^21, f*g+d*f+b*c, c*g+b*f+a*c, f*g+d*f+b*c, g^2+f^2+c^21], [a,b,c,d,f,g]) gives "Caught fatal error".  >Comment By: Stavros Macrakis (macrakis) Date: 20070917 15:44 Message: Logged In: YES user_id=588346 Originator: YES An even simpler fatal error: solve([a*d+b*c,a+d],[a,b,c,d]) => Fatal error solve([a*d+b*c,a+d],[a,b,c,d]), algebraic => OK (in 5.13.0)  Comment By: Barton Willis (willisbl) Date: 20060910 08:21 Message: Logged In: YES user_id=895922 These errors don't happen if algebraic == true. We could locally set algebraic to true in solve / algsys, but I doubt that fix the real bug.  Comment By: Robert Dodier (robert_dodier) Date: 20060626 14:19 Message: Logged In: YES user_id=501686 Observed in 5.9.3.  Comment By: Stavros Macrakis (macrakis) Date: 20020918 00:09 Message: Logged In: YES user_id=588346 A simpler fatal error. solve([a+b+c=0,a^2+b^2+c^2=1],[a,b,c])  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=609466&group_id=4933 
From: SourceForge.net <noreply@so...>  20070917 19:18:18

Bugs item #1770110, was opened at 20070808 11:24 Message generated for change (Comment added) made by macrakis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1770110&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: 3 Private: No Submitted By: Barton Willis (willisbl) Assigned to: Nobody/Anonymous (nobody) Summary: matrix ^ zero Initial Comment: We have (%i1) matrix([0])^0; (%o1) matrix([1]) but (%i2) 0^0; 0^0 has been generated  an error. Similarly, [0]^0 > [1]. (%o1) disagrees with the user documentation for domxexpt. I think the code should be changed to match the documentation  the matrix ^ xxx code in simpexpt should be changed to simply map the power function onto the matrix elements.  >Comment By: Stavros Macrakis (macrakis) Date: 20070917 15:18 Message: Logged In: YES user_id=588346 Originator: NO What about matrix([0])^^0? This currently gives matrix([1]). I'd think that <singular>^^0 would be just as undefined as 0^0. s  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1770110&group_id=4933 
From: SourceForge.net <noreply@so...>  20070917 18:56:43

Bugs item #1780506, was opened at 20070823 15:19 Message generated for change (Comment added) made by macrakis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1780506&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: Invalid Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: problem with the function floor Initial Comment: > float(log(8)/log(2)); > 3.0; > floor(%); > 2; < What?! It's an error! > floor(3.0); > 3;  Maxima version: 5.12.0 Maxima build date: 10:43 5/15/2007 host type: i686pclinuxgnu lispimplementationtype: CLISP lispimplementationversion: 2.41 (20061013) (built 3371985193) (memory 3388207441)   >Comment By: Stavros Macrakis (macrakis) Date: 20070917 14:56 Message: Logged In: YES user_id=588346 Originator: NO I don't know why the original poster was doing float(log(8)/log(2)) in the first place  perhaps because he couldn't get it to simplify otherwise? If we knew who it was, we could suggest s/he try radcan, which does give exactly 3.  Comment By: SourceForge Robot (sfrobot) Date: 20070906 22:20 Message: Logged In: YES user_id=1312539 Originator: NO 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: 20070823 15:38 Message: Logged In: YES user_id=28849 Originator: NO This is really a deficiency with maxima's printer. float(log(8)/log(2)) is 2.9999999999999996. Hence, floor is correct in returning 2. To see this, use ":lisp $%o<n>", assuming your Lisp has an accurate printer. If not, then try :lisp (integerdecodefloat $%o<n>). Compare that with :lisp (integerdecodefloat 3d0). Set to pending.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1780506&group_id=4933 
From: SourceForge.net <noreply@so...>  20070917 18:28:38

Bugs item #1796372, was opened at 20070917 14:28 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1796372&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: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: ssubst infinite recursion Initial Comment: ssubst("ab","a","a") => infinite recursion Presumably it is expanding a => ab => abb => ...  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1796372&group_id=4933 
From: SourceForge.net <noreply@so...>  20070917 12:18:16

Bugs item #1036901, was opened at 20040929 05:53 Message generated for change (Comment added) made by dgildea You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1036901&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: Jaroslaw Piskorski (jaropis) Assigned to: Nobody/Anonymous (nobody) Summary: tlimit(7^(n^2)/8^n,n,inf); wrong result Initial Comment: Maxima returns minf, while it should return inf here.  >Comment By: Dan Gildea (dgildea) Date: 20070917 08:17 Message: Logged In: YES user_id=1797506 Originator: NO fixed in hayat.lisp 1.28. (%i1) tlimit(7^(n^2)/8^n,n,inf); (%o1) inf however: (%i6) tlimit(7^(n^2)/n^2,n,inf); (%o6) 0 (%i7) taylor(7^(n^2)/n^2,n,inf,1); (%o7) +0 (%i8) taylor(7^(n^2)/n^2,n,inf,2); (%o8) +(+1/n^2)/%e^(log(7)*n^2)  Comment By: Raymond Toy (rtoy) Date: 20061108 21:19 Message: Logged In: YES user_id=28849 I think the bug is in taylor, which is called by taylim, via limit. taylor(7^(n^2)/8^n,n,inf,1) > log(8)*n+1 I don't think that that is right.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1036901&group_id=4933 
From: SourceForge.net <noreply@so...>  20070916 21:32:27

Bugs item #1281736, was opened at 20050904 15:26 Message generated for change (Comment added) made by dgildea You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1281736&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: Vadim V. Zhytnikov (vvzhy) Assigned to: Nobody/Anonymous (nobody) Summary: limit((x/log(x))*(x^(1/x)1),x,inf)  wrong result Initial Comment: (%i1) limit((x/log(x))*(x^(1/x)1),x,inf); (%o1) inf Correct result should be 1  >Comment By: Dan Gildea (dgildea) Date: 20070916 17:32 Message: Logged In: YES user_id=1797506 Originator: NO returns inf in maxima 5.13.0. after bug fix in limit.lisp rev 1.28, returns noun form  not ideal, but this limit is hard to do without taylor expansion. tlimit returns 1.  Comment By: Raymond Toy (rtoy) Date: 20061108 20:33 Message: Logged In: YES user_id=28849 Current CVS returns the nounform for the limit. Better than inf, but could be better. tlimit actually returns 1 in this case.  Comment By: Stavros Macrakis (macrakis) Date: 20050928 10:25 Message: Logged In: YES user_id=588346 This is a bug. Even worse, tlimit also doesn't work, and for no good reason: tlimit(...) => nounform but limit ( taylor ( (x/log(x))*(x^(1/x)1) , x, inf, 0 ) ) => 0  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1281736&group_id=4933 