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}
(2) 
S  M  T  W  T  F  S 






1
(2) 
2
(4) 
3

4
(11) 
5

6

7

8
(4) 
9
(1) 
10
(10) 
11
(3) 
12

13
(1) 
14

15
(1) 
16
(1) 
17

18
(1) 
19
(13) 
20

21
(2) 
22
(4) 
23

24

25

26
(13) 
27
(6) 
28

29

30
(1) 
31







From: SourceForge.net <noreply@so...>  20061204 23:51:01

Bugs item #1562671, was opened at 20060921 03:07 Message generated for change (Comment added) made by macrakis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1562671&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: Elmar Zander (zandere) Assigned to: Nobody/Anonymous (nobody) Summary: Handling of infinities Initial Comment: The handling of inf seems to be like that of a really huge (bigger than everything else) but otherwise specific number. Some examples: infinf => 0 inf/inf => 1 inf*0 => 0 Those should all return "undefined". In the following cases the return value should be directly simplified to inf again inf*inf => inf^2 inf+inf => 2*inf 4*inf => 4*inf Also comparisons like the following should be undefined: is( inf>=inf ) => true if( inf>=2*inf ) => false Furthermore there is no relation between inf and minf: inf => inf minf => minf inf+minf => inf+minf Those should return minf, inf, and und respectively. It would be nice if infinities would be handled like in the IEEE floating point standard which, I think, makes more sense in those cases.  >Comment By: Stavros Macrakis (macrakis) Date: 20061204 18:50 Message: Logged In: YES user_id=588346 Originator: NO Yes, these limitations are known. Basically, the only parts of Maxima that know about inf/minf/und/ind/infinity are the limit and definite integral packages. As far as the rest of Maxima is concerned, INF is just a variable like X. This is silly, of course. The problem is that correcting this in the obvious way means special cases throughout the simplification code, which assumes that if two identifiers are the same identifier, they are equal.... There are other possible solutions (e.g. making each infinity produced unique in some way), but they have their complications, too....  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1562671&group_id=4933 
From: SourceForge.net <noreply@so...>  20061204 23:39:28

Bugs item #1608848, was opened at 20061204 18:36 Message generated for change (Settings changed) made by macrakis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1608848&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  Polynomials Group: None Status: Open Resolution: None >Priority: 3 Private: No Submitted By: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: factor involving sqrt(2) fails, but gfactor works (?!) Initial Comment: fex: sqrt(2)*n  n + sqrt(2)  2 $ Neither one of: factor(fex) factor(fex),algebraic:true factors fex. but both of: gfactor(fex) factor(fex,q^37) // Any polynom will do do factor correctly into (sqrt(2)1)*(nsqrt(2)) This behavior difference is not documented, and is confusing. Of course, the semantics are not entirely clear, and anyway the current code doesn't work for all cases you'd like, e.g. gfactor(expand( (xsqrt(2)+sqrt(3))*(x+sqrt(2)*3+sqrt(3)) )) doesn't factor, though factor(expand( // not even gfactor (x + 7 sqrt(2)) (x  sqrt(3)) )) does. s  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1608848&group_id=4933 
From: SourceForge.net <noreply@so...>  20061204 23:36:04

Bugs item #1608848, was opened at 20061204 18: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=1608848&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: factor involving sqrt(2) fails, but gfactor works (?!) Initial Comment: fex: sqrt(2)*n  n + sqrt(2)  2 $ Neither one of: factor(fex) factor(fex),algebraic:true factors fex. but both of: gfactor(fex) factor(fex,q^37) // Any polynom will do do factor correctly into (sqrt(2)1)*(nsqrt(2)) This behavior difference is not documented, and is confusing. Of course, the semantics are not entirely clear, and anyway the current code doesn't work for all cases you'd like, e.g. gfactor(expand( (xsqrt(2)+sqrt(3))*(x+sqrt(2)*3+sqrt(3)) )) doesn't factor, though factor(expand( // not even gfactor (x + 7 sqrt(2)) (x  sqrt(3)) )) does. s  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1608848&group_id=4933 
From: SourceForge.net <noreply@so...>  20061204 20:45:57

Bugs item #1594977, was opened at 20061112 04:17 Message generated for change (Comment added) made by rtoy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1594977&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: Andrej Vodopivec (andrejv) Assigned to: Nobody/Anonymous (nobody) Summary: limit(n/(n^2+1), n, inf); + FIX Initial Comment: I think limit should change inf to minf before doing the calculation: (%i1) limit(n/(n^2+1), n, inf); (%o1) inf/(inf^2+1) (%i2) limit(n/(n^2+1), n, minf); (%o2) 0 Andrej  >Comment By: Raymond Toy (rtoy) Date: 20061204 15:45 Message: Logged In: YES user_id=28849 Originator: NO The following replacement for simpmin in simp.lisp makes inf return minf. This doesn't fix the issue that 1*inf is still inf. (defun simpmin (x vestigial z) vestigial ;Ignored (oneargcheck x) (cond ((numberp (cadr x)) (minus (cadr x))) ((atom (cadr x)) (if (eq (cadr x) '$inf) ;; New '$minf ;; New (list '(mtimes simp) 1 (cadr x)))) (t (simplifya (list '(mtimes) 1 (simplifya (cadr x) z)) t))))  Comment By: Raymond Toy (rtoy) Date: 20061204 12:38 Message: Logged In: YES user_id=28849 Originator: NO Rather than fixing this just for limit, shouldn't we fix this at a higher level so that inf is always simplified to minf?  Comment By: Robert Dodier (robert_dodier) Date: 20061204 00:26 Message: Logged In: YES user_id=501686 Originator: NO I put FIX in the title to make it easier to find patch.  Comment By: Andrej Vodopivec (andrejv) Date: 20061114 09:11 Message: Logged In: YES user_id=1179910 Attached a patch which does this. Testsuite reports no errors. Andrej  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1594977&group_id=4933 
From: SourceForge.net <noreply@so...>  20061204 17:40:05

Bugs item #1607567, was opened at 20061202 16:49 Message generated for change (Comment added) made by macrakis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1607567&group_id=4933 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Lisp Core  Trigonometry Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: trigreduce([atan(sin(a)/cos(a))]) => [ atan(tan(a)) ] Initial Comment: trigexpand( [ atan(sin(a)/cos(a)) ] ) => atan(tan(a)) (UNSIMPLIFIED!) whereas trigexpand( atan(sin(a)/cos(a)) ) => a and atan(tan(a)) => a Though the simplification atan(tan(a))=> is questionable (it needs to do reduction), it is weird that putting the argument to trigexpand in a list changes the behavior.  >Comment By: Stavros Macrakis (macrakis) Date: 20061204 12:40 Message: Logged In: YES user_id=588346 Originator: YES Other simplifications also don't happen: trigreduce( sin(x)^2 ) => (1 cos(2*x))/2 (OK) trigreduce([sin(x)^2]) => [ (22*cos(2*x))/4 ] (?)  Comment By: Stavros Macrakis (macrakis) Date: 20061204 12:30 Message: Logged In: YES user_id=588346 Originator: YES Sorry, it's trigreduce in Maxima 5.10.0 GCL 2.6.8 Windows2k Athlon trigreduce(atan(sin(a)/cos(a))) => a trigreduce([atan(sin(a)/cos(a))]) => [atan(tan(a))] PS I should always cut and paste rather than retyping....  Comment By: Raymond Toy (rtoy) Date: 20061204 11:49 Message: Logged In: YES user_id=28849 Originator: NO What version? With 5.10.0 and cmucl, trigexpand([atan(sin(a)/cos(a))]) => [atan(sin(a)/cos(a))] Corresponding result if the arg is not a list.  Comment By: Stavros Macrakis (macrakis) Date: 20061202 16:53 Message: Logged In: YES user_id=588346 Originator: YES Oops, it's actually trigexpand( [ atan(sin(a)/cos(a)) ] ) => [ atan(tan(a)) ] (UNSIMPLIFIED!) It doesn't simplify atan of tan, but it does preserve the list...  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1607567&group_id=4933 
From: SourceForge.net <noreply@so...>  20061204 17:38:51

Bugs item #1594977, was opened at 20061112 04:17 Message generated for change (Comment added) made by rtoy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1594977&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: Andrej Vodopivec (andrejv) Assigned to: Nobody/Anonymous (nobody) Summary: limit(n/(n^2+1), n, inf); + FIX Initial Comment: I think limit should change inf to minf before doing the calculation: (%i1) limit(n/(n^2+1), n, inf); (%o1) inf/(inf^2+1) (%i2) limit(n/(n^2+1), n, minf); (%o2) 0 Andrej  >Comment By: Raymond Toy (rtoy) Date: 20061204 12:38 Message: Logged In: YES user_id=28849 Originator: NO Rather than fixing this just for limit, shouldn't we fix this at a higher level so that inf is always simplified to minf?  Comment By: Robert Dodier (robert_dodier) Date: 20061204 00:26 Message: Logged In: YES user_id=501686 Originator: NO I put FIX in the title to make it easier to find patch.  Comment By: Andrej Vodopivec (andrejv) Date: 20061114 09:11 Message: Logged In: YES user_id=1179910 Attached a patch which does this. Testsuite reports no errors. Andrej  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1594977&group_id=4933 
From: SourceForge.net <noreply@so...>  20061204 17:30:25

Bugs item #1607567, was opened at 20061202 16:49 Message generated for change (Comment added) made by macrakis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1607567&group_id=4933 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Lisp Core  Trigonometry Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) >Summary: trigreduce([atan(sin(a)/cos(a))]) => [ atan(tan(a)) ] Initial Comment: trigexpand( [ atan(sin(a)/cos(a)) ] ) => atan(tan(a)) (UNSIMPLIFIED!) whereas trigexpand( atan(sin(a)/cos(a)) ) => a and atan(tan(a)) => a Though the simplification atan(tan(a))=> is questionable (it needs to do reduction), it is weird that putting the argument to trigexpand in a list changes the behavior.  >Comment By: Stavros Macrakis (macrakis) Date: 20061204 12:30 Message: Logged In: YES user_id=588346 Originator: YES Sorry, it's trigreduce in Maxima 5.10.0 GCL 2.6.8 Windows2k Athlon trigreduce(atan(sin(a)/cos(a))) => a trigreduce([atan(sin(a)/cos(a))]) => [atan(tan(a))] PS I should always cut and paste rather than retyping....  Comment By: Raymond Toy (rtoy) Date: 20061204 11:49 Message: Logged In: YES user_id=28849 Originator: NO What version? With 5.10.0 and cmucl, trigexpand([atan(sin(a)/cos(a))]) => [atan(sin(a)/cos(a))] Corresponding result if the arg is not a list.  Comment By: Stavros Macrakis (macrakis) Date: 20061202 16:53 Message: Logged In: YES user_id=588346 Originator: YES Oops, it's actually trigexpand( [ atan(sin(a)/cos(a)) ] ) => [ atan(tan(a)) ] (UNSIMPLIFIED!) It doesn't simplify atan of tan, but it does preserve the list...  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1607567&group_id=4933 
From: SourceForge.net <noreply@so...>  20061204 16:49:32

Bugs item #1607567, was opened at 20061202 16:49 Message generated for change (Comment added) made by rtoy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1607567&group_id=4933 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Lisp Core  Trigonometry Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: trigexpand([atan(sin(a)/cos(a))]) => [ atan(tan(a)) ] Initial Comment: trigexpand( [ atan(sin(a)/cos(a)) ] ) => atan(tan(a)) (UNSIMPLIFIED!) whereas trigexpand( atan(sin(a)/cos(a)) ) => a and atan(tan(a)) => a Though the simplification atan(tan(a))=> is questionable (it needs to do reduction), it is weird that putting the argument to trigexpand in a list changes the behavior.  >Comment By: Raymond Toy (rtoy) Date: 20061204 11:49 Message: Logged In: YES user_id=28849 Originator: NO What version? With 5.10.0 and cmucl, trigexpand([atan(sin(a)/cos(a))]) => [atan(sin(a)/cos(a))] Corresponding result if the arg is not a list.  Comment By: Stavros Macrakis (macrakis) Date: 20061202 16:53 Message: Logged In: YES user_id=588346 Originator: YES Oops, it's actually trigexpand( [ atan(sin(a)/cos(a)) ] ) => [ atan(tan(a)) ] (UNSIMPLIFIED!) It doesn't simplify atan of tan, but it does preserve the list...  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1607567&group_id=4933 
From: SourceForge.net <noreply@so...>  20061204 16:46:48

Bugs item #1604446, was opened at 20061128 07:50 Message generated for change (Comment added) made by rtoy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1604446&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: ilt(s/((s+d)*(s^2+w^2)), s, t) takes forever Initial Comment: Hi, ilt(s/((s+d)*(s^2+w^2)), s, t) takes forever in version 5.10.0 in Linux. However, version 5.10.0b for Windows solves the inverse transform instantly and correctly. Why version 5.10.0b for Linux haven not been released? Best regards, José Antonio joanlofe@...  >Comment By: Raymond Toy (rtoy) Date: 20061204 11:46 Message: Logged In: YES user_id=28849 Originator: NO 5.10.0 on Solaris with cmucl works instantly for me. I don't know what version 5.10.0b is.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1604446&group_id=4933 
From: SourceForge.net <noreply@so...>  20061204 05:36:59

Bugs item #1605159, was opened at 20061129 03:54 Message generated for change (Comment added) made by robert_dodier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1605159&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: Fixed Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Plotting constant functions works only when they're 2^z Initial Comment: Hi Maximateam, I have the problem that I'm unable to insert constant functions into a plot. Maxima will do calculations forever and hangs (using CPU power). I found out that _some_ constant functions are indeed plotted but only those that have the form 2^z. So for example you can plot y=0.5, y=1, y=2 or y=0.03125. Things don't work are y=0.4 or y=0.028 This is in all revisions I tested so far including the recent 5.10. HTH, Phil  >Comment By: Robert Dodier (robert_dodier) Date: 20061203 22:36 Message: Logged In: YES user_id=501686 Originator: NO Not observed in Maxima 5.10.0cvs w/ GCL, SBCL, and Clisp. Marking this report as pending (so it will be closed automatically in 2 weeks, in case Phil comes back) since it seems to be fixed, and it is a duplicate of bug report 1571454: plot2d(0.99,[x,0,5]) is very slow.  Comment By: Raymond Toy (rtoy) Date: 20061129 10:49 Message: Logged In: YES user_id=28849 Originator: NO This was caused by the adaptive plotter. This is fixed in CVS, I think. Can you try that out?  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1605159&group_id=4933 
From: SourceForge.net <noreply@so...>  20061204 05:26:50

Bugs item #1594977, was opened at 20061112 02:17 Message generated for change (Comment added) made by robert_dodier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1594977&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: Andrej Vodopivec (andrejv) Assigned to: Nobody/Anonymous (nobody) >Summary: limit(n/(n^2+1), n, inf); + FIX Initial Comment: I think limit should change inf to minf before doing the calculation: (%i1) limit(n/(n^2+1), n, inf); (%o1) inf/(inf^2+1) (%i2) limit(n/(n^2+1), n, minf); (%o2) 0 Andrej  >Comment By: Robert Dodier (robert_dodier) Date: 20061203 22:26 Message: Logged In: YES user_id=501686 Originator: NO I put FIX in the title to make it easier to find patch.  Comment By: Andrej Vodopivec (andrejv) Date: 20061114 07:11 Message: Logged In: YES user_id=1179910 Attached a patch which does this. Testsuite reports no errors. Andrej  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1594977&group_id=4933 