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

_{Feb}

_{Mar}

_{Apr}

_{May}

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

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

_{Mar}

_{Apr}

_{May}

_{Jun}

_{Jul}

_{Aug}

_{Sep}

_{Oct}

_{Nov}

_{Dec}

S  M  T  W  T  F  S 





1

2
(3) 
3

4

5

6

7
(4) 
8
(8) 
9

10
(2) 
11
(3) 
12

13

14
(8) 
15
(9) 
16
(3) 
17
(1) 
18

19

20

21

22

23

24

25

26

27

28

29

30


From: SourceForge.net <noreply@so...>  20121110 02:45:39

Bugs item #3578373, was opened at 20121019 05:39 Message generated for change (Comment added) made by rtoy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3578373&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: Fixed Priority: 5 Private: No Submitted By: Barton Willis (willisbl) Assigned to: Nobody/Anonymous (nobody) Summary: hgfred([1/2,a+1],[a+2],x); Initial Comment: (%i1) hgfred([1/2,a+1],[a+2],x); expt: undefined: 0 to a negative exponent.  >Comment By: Raymond Toy (rtoy) Date: 20121109 18:45 Message: Fixed in git. The formula is not applied if a+1/2 or b+1/2 is zero which would cause a division by zero.  Comment By: Raymond Toy (rtoy) Date: 20121101 23:30 Message: A&S 15.2.16 doesn't help, but A&S 15.2.14 gives an answer because hgfred([a+1,b],[c],z) and hgfred([a,b+1],[c],z) can be expressed in terms of associated Legendre function and an elementary function. Assuming I did things correctly, hgfred([1/2,a+1],[a+2],x) = (2^(a+1)*assoc_legendre_p(a,a1,sqrt(1z))*gamma(a+2)*z^(a/21/2) +(2*a+2)*sqrt(1z)) /(2*a+3) I don't have any algorithm to determine that unfortunately. Perhaps it's best that maxima just returns the 2F1 function itself instead of generating an error.  Comment By: Raymond Toy (rtoy) Date: 20121030 19:37 Message: Maxima is using the A&S 15.2.6 to derive the value from F(1/2, a+1; a+1; x). But that's equal to sqrt(1x) and 15.2.6 is not valid in that case. Perhaps 15.2.16 should have been used instead?  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3578373&group_id=4933 
From: SourceForge.net <noreply@so...>  20121108 23:09:22

Bugs item #3585486, was opened at 20121108 14:36 Message generated for change (Comment added) made by rtoy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3585486&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: 7 Private: No Submitted By: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: radexpand:all/true broken Initial Comment: block([radexpand:all], sqrt(x^2) ) => sqrt(x^2), should be x per doc block([radexpand:true,domain:'real], sqrt(x^2) ) => sqrt(x^2), should be abs(x) per doc Tested in Maxima 5.27.0 20120430 11:59:06 i686appledarwin11.3.0 SBCL 1.0.55.0abb03f9  >Comment By: Raymond Toy (rtoy) Date: 20121108 15:09 Message: Maxima version too old? I get this with the current sources (and cmucl): block([radexpand:all], sqrt(x^2) ) => x block([radexpand:true,domain:'real], sqrt(x^2) ) => abs(x)  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3585486&group_id=4933 
From: SourceForge.net <noreply@so...>  20121108 22:36:31

Bugs item #3585486, was opened at 20121108 14:36 Message generated for change (Tracker Item Submitted) made by macrakis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3585486&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: 7 Private: No Submitted By: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: radexpand:all/true broken Initial Comment: block([radexpand:all], sqrt(x^2) ) => sqrt(x^2), should be x per doc block([radexpand:true,domain:'real], sqrt(x^2) ) => sqrt(x^2), should be abs(x) per doc Tested in Maxima 5.27.0 20120430 11:59:06 i686appledarwin11.3.0 SBCL 1.0.55.0abb03f9  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3585486&group_id=4933 
From: SourceForge.net <noreply@so...>  20121108 17:52:25

Bugs item #3577666, was opened at 20121016 08:03 Message generated for change (Comment added) made by rtoy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3577666&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: Invalid Priority: 5 Private: No Submitted By: JeanYves (jyoberle) Assigned to: Nobody/Anonymous (nobody) Summary: radcan seems to give nonequvalent function Initial Comment: Hi, When doing radcan((2*x)/(sqrt(1(x^21)^2)*sqrt(1asin(x^21)^2))), the result is 2/(sqrt(2x^2)*sqrt(1asin(x^21))*sqrt(asin(x^21)+1)). But these two expressions are not equivalent. For x = 0.4, (2*x)/(sqrt(1(x^21)^2)*sqrt(1asin(x^21)^2)) gives 20.01585798944382 wheras 2/(sqrt(2x^2)*sqrt(1asin(x^21))*sqrt(asin(x^21)+1)) gives 20.01585798944383. (2*x)/(sqrt(1(x^21)^2)*sqrt(1asin(x^21)^2)) is the result of diff(acos(asin(x^21)),x) if this can help. Build info is build_info("5.28.02","20120827 23:16:48","i686pcmingw32","GNU Common Lisp (GCL)","GCL 2.6.8"). Best regards, JeanYves  >Comment By: Raymond Toy (rtoy) Date: 20121108 09:52 Message: First, let's make the expression simpler, removing the part with asin: e: 2*x/sqrt(1(x^21)^2) ratsimp(e) > 2*x/sqrt(x^2x^4) No problem with that. radcan(e) > 2/sqrt(2x^2) This is very different. From the ratsimp result, we can change the expression (manually) to 2*x/abs(x)/sqrt(2x^2). This is basically the same as what radcan has produced, but radcan has "assumed" that x is very large and positive, which makes abs(x) = x. This is what I meant by saying that radcan can do "unexpected" changes. If this is not clear, you should bring this up on the mailing list where Richard Fateman (author of radcan) can explain what's going on. This really needs to be documented better.  Comment By: JeanYves (jyoberle) Date: 20121108 08:38 Message: @rtoy: I'm answering late but I tend to agree with tomasriker. When you look at the limit for x=sqrt(sin(1)+1) which is the largest negative possible value you get: limit(f(x),x,sqrt(1+sin(1)),plus) is inf limit(radcan(f(x)),x,sqrt(1+sin(1)),plus) is minf f(x) being diff(acos(asin(x^21)),x) However, I followed Ivch advice and replaced radcan by factor in my code (with a small trick for integers).  Comment By: David Scherfgen (tomasriker) Date: 20121108 07:55 Message: @rtoy: You missed the minus sign! The one result is negative, the other is positive. So this is definitely a bug!  Comment By: Raymond Toy (rtoy) Date: 20121030 18:21 Message: Although the documentation of radcan isn't very clear on this, radcan is expected to produce results like this. I think the idea is if x is very large, then both expressions are equivalent. I think that's true for your expressions. If this is not what you want, use ratsimp or some other combination of expand and factor. Marking as pending/invalid.  Comment By: Valery Lovchikov (lvch) Date: 20121018 23:19 Message: use function factor %i1 factor(sqrt(x^2u*x^4)); %o1 sqrt(1u*x^2)*abs(x) but %i1 radcan(sqrt(x^2u*x^4)); %o1 x*sqrt(1u*x^2)  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3577666&group_id=4933 
From: SourceForge.net <noreply@so...>  20121108 16:38:11

Bugs item #3577666, was opened at 20121016 08:03 Message generated for change (Comment added) made by jyoberle You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3577666&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: Invalid Priority: 5 Private: No Submitted By: JeanYves (jyoberle) Assigned to: Nobody/Anonymous (nobody) Summary: radcan seems to give nonequvalent function Initial Comment: Hi, When doing radcan((2*x)/(sqrt(1(x^21)^2)*sqrt(1asin(x^21)^2))), the result is 2/(sqrt(2x^2)*sqrt(1asin(x^21))*sqrt(asin(x^21)+1)). But these two expressions are not equivalent. For x = 0.4, (2*x)/(sqrt(1(x^21)^2)*sqrt(1asin(x^21)^2)) gives 20.01585798944382 wheras 2/(sqrt(2x^2)*sqrt(1asin(x^21))*sqrt(asin(x^21)+1)) gives 20.01585798944383. (2*x)/(sqrt(1(x^21)^2)*sqrt(1asin(x^21)^2)) is the result of diff(acos(asin(x^21)),x) if this can help. Build info is build_info("5.28.02","20120827 23:16:48","i686pcmingw32","GNU Common Lisp (GCL)","GCL 2.6.8"). Best regards, JeanYves  >Comment By: JeanYves (jyoberle) Date: 20121108 08:38 Message: @rtoy: I'm answering late but I tend to agree with tomasriker. When you look at the limit for x=sqrt(sin(1)+1) which is the largest negative possible value you get: limit(f(x),x,sqrt(1+sin(1)),plus) is inf limit(radcan(f(x)),x,sqrt(1+sin(1)),plus) is minf f(x) being diff(acos(asin(x^21)),x) However, I followed Ivch advice and replaced radcan by factor in my code (with a small trick for integers).  Comment By: David Scherfgen (tomasriker) Date: 20121108 07:55 Message: @rtoy: You missed the minus sign! The one result is negative, the other is positive. So this is definitely a bug!  Comment By: Raymond Toy (rtoy) Date: 20121030 18:21 Message: Although the documentation of radcan isn't very clear on this, radcan is expected to produce results like this. I think the idea is if x is very large, then both expressions are equivalent. I think that's true for your expressions. If this is not what you want, use ratsimp or some other combination of expand and factor. Marking as pending/invalid.  Comment By: Valery Lovchikov (lvch) Date: 20121018 23:19 Message: use function factor %i1 factor(sqrt(x^2u*x^4)); %o1 sqrt(1u*x^2)*abs(x) but %i1 radcan(sqrt(x^2u*x^4)); %o1 x*sqrt(1u*x^2)  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3577666&group_id=4933 
From: SourceForge.net <noreply@so...>  20121108 16:04:25

Bugs item #3585415, was opened at 20121108 07:45 Message generated for change (Comment added) made by rtoy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3585415&group_id=4933 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Lisp Core  Integration Group: None Status: Open Resolution: None Priority: 7 Private: No Submitted By: David Scherfgen (tomasriker) Assigned to: Nobody/Anonymous (nobody) Summary: integrate loops forever with simple expression Initial Comment: if you calculate this: integrate(x^(1/3)/(x^(2/3)+1), x, 0, 8); Maxima will compute forever and never return. However, the indefinite integral works: integrate(x^(1/3)/(x^(2/3)+1), x); gives you the antiderivative: F(x) := (3*(x^(2/3)+1))/2(3*log(x^(2/3)+1))/2; Now the original definite integral can be computed as F(8)  F(0). This is OK, because F(x) doesn't change sign or shows any other notable behavior between 0 and 8. The question is: why doesn't Maxima do this? Instead it loops forever ...  >Comment By: Raymond Toy (rtoy) Date: 20121108 08:04 Message: Definite integration in maxima often does not compute the indefinite integral first, but in this case it does compute the indefinite integral. Maxima appears to be stuck computing the limits. Don't know why that should be.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3585415&group_id=4933 
From: SourceForge.net <noreply@so...>  20121108 15:55:59

Bugs item #3577666, was opened at 20121016 08:03 Message generated for change (Comment added) made by tomasriker You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3577666&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: Pending Resolution: Invalid Priority: 5 Private: No Submitted By: JeanYves (jyoberle) Assigned to: Nobody/Anonymous (nobody) Summary: radcan seems to give nonequvalent function Initial Comment: Hi, When doing radcan((2*x)/(sqrt(1(x^21)^2)*sqrt(1asin(x^21)^2))), the result is 2/(sqrt(2x^2)*sqrt(1asin(x^21))*sqrt(asin(x^21)+1)). But these two expressions are not equivalent. For x = 0.4, (2*x)/(sqrt(1(x^21)^2)*sqrt(1asin(x^21)^2)) gives 20.01585798944382 wheras 2/(sqrt(2x^2)*sqrt(1asin(x^21))*sqrt(asin(x^21)+1)) gives 20.01585798944383. (2*x)/(sqrt(1(x^21)^2)*sqrt(1asin(x^21)^2)) is the result of diff(acos(asin(x^21)),x) if this can help. Build info is build_info("5.28.02","20120827 23:16:48","i686pcmingw32","GNU Common Lisp (GCL)","GCL 2.6.8"). Best regards, JeanYves  Comment By: David Scherfgen (tomasriker) Date: 20121108 07:55 Message: @rtoy: You missed the minus sign! The one result is negative, the other is positive. So this is definitely a bug!  Comment By: Raymond Toy (rtoy) Date: 20121030 18:21 Message: Although the documentation of radcan isn't very clear on this, radcan is expected to produce results like this. I think the idea is if x is very large, then both expressions are equivalent. I think that's true for your expressions. If this is not what you want, use ratsimp or some other combination of expand and factor. Marking as pending/invalid.  Comment By: Valery Lovchikov (lvch) Date: 20121018 23:19 Message: use function factor %i1 factor(sqrt(x^2u*x^4)); %o1 sqrt(1u*x^2)*abs(x) but %i1 radcan(sqrt(x^2u*x^4)); %o1 x*sqrt(1u*x^2)  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3577666&group_id=4933 
From: SourceForge.net <noreply@so...>  20121108 15:50:36

Bugs item #3585415, was opened at 20121108 07:45 Message generated for change (Settings changed) made by tomasriker You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3585415&group_id=4933 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Lisp Core  Integration Group: None Status: Open Resolution: None >Priority: 7 Private: No Submitted By: David Scherfgen (tomasriker) Assigned to: Nobody/Anonymous (nobody) Summary: integrate loops forever with simple expression Initial Comment: if you calculate this: integrate(x^(1/3)/(x^(2/3)+1), x, 0, 8); Maxima will compute forever and never return. However, the indefinite integral works: integrate(x^(1/3)/(x^(2/3)+1), x); gives you the antiderivative: F(x) := (3*(x^(2/3)+1))/2(3*log(x^(2/3)+1))/2; Now the original definite integral can be computed as F(8)  F(0). This is OK, because F(x) doesn't change sign or shows any other notable behavior between 0 and 8. The question is: why doesn't Maxima do this? Instead it loops forever ...  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3585415&group_id=4933 
From: SourceForge.net <noreply@so...>  20121108 15:45:51

Bugs item #3585415, was opened at 20121108 07:45 Message generated for change (Tracker Item Submitted) made by tomasriker You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3585415&group_id=4933 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Lisp Core  Integration Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: David Scherfgen (tomasriker) Assigned to: Nobody/Anonymous (nobody) Summary: integrate loops forever with simple expression Initial Comment: if you calculate this: integrate(x^(1/3)/(x^(2/3)+1), x, 0, 8); Maxima will compute forever and never return. However, the indefinite integral works: integrate(x^(1/3)/(x^(2/3)+1), x); gives you the antiderivative: F(x) := (3*(x^(2/3)+1))/2(3*log(x^(2/3)+1))/2; Now the original definite integral can be computed as F(8)  F(0). This is OK, because F(x) doesn't change sign or shows any other notable behavior between 0 and 8. The question is: why doesn't Maxima do this? Instead it loops forever ...  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3585415&group_id=4933 
From: SourceForge.net <noreply@so...>  20121107 15:15:14

Bugs item #3585135, was opened at 20121107 04:41 Message generated for change (Comment added) made by tomasriker You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3585135&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: 7 Private: No Submitted By: David Scherfgen (tomasriker) Assigned to: Nobody/Anonymous (nobody) Summary: trigrat loops forever, depending on how you call it Initial Comment: The following works: e : 2*x/(sqrt(y)+x)  (x^2/((sqrt(y)+x)^2)); trigrat(e); trigrat(xthru(e)); Both of the following lines will make the second "trigrat" call take forever (100% CPU utilization, will never return): ( trigrat(e), trigrat(xthru(e)) ); [ trigrat(e), trigrat(xthru(e)) ]; So: evaluating both lines separately works, but evaluating them together or inside a function will cause the "bug". If you switch the expressions, it works fine: ( trigrat(e), trigrat(xthru(e)) ); /* loops forever */ ( trigrat(xthru(e)), trigrat(e) ); /* works */  >Comment By: David Scherfgen (tomasriker) Date: 20121107 07:15 Message: Stavros Macrakis posted another, simpler, example on the mailing list: f: 1/(y+sqrt(y))$ [trigrat(f), trigrat(f)] It doesn't loop forever, but the first result is different from the second!  Comment By: David Scherfgen (tomasriker) Date: 20121107 04:42 Message: Maxima version: "5.28.0" Maxima build date: "20120903 11:36:16" Host type: "x86_64unknownlinuxgnu" Lisp implementation type: "CLISP" Lisp implementation version: "2.42 (20071016) (built 3403443236) (memory 3555653780)"  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3585135&group_id=4933 
From: SourceForge.net <noreply@so...>  20121107 12:43:00

Bugs item #3585135, was opened at 20121107 04:41 Message generated for change (Settings changed) made by tomasriker You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3585135&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: 7 Private: No Submitted By: David Scherfgen (tomasriker) Assigned to: Nobody/Anonymous (nobody) Summary: trigrat loops forever, depending on how you call it Initial Comment: The following works: e : 2*x/(sqrt(y)+x)  (x^2/((sqrt(y)+x)^2)); trigrat(e); trigrat(xthru(e)); Both of the following lines will make the second "trigrat" call take forever (100% CPU utilization, will never return): ( trigrat(e), trigrat(xthru(e)) ); [ trigrat(e), trigrat(xthru(e)) ]; So: evaluating both lines separately works, but evaluating them together or inside a function will cause the "bug". If you switch the expressions, it works fine: ( trigrat(e), trigrat(xthru(e)) ); /* loops forever */ ( trigrat(xthru(e)), trigrat(e) ); /* works */  Comment By: David Scherfgen (tomasriker) Date: 20121107 04:42 Message: Maxima version: "5.28.0" Maxima build date: "20120903 11:36:16" Host type: "x86_64unknownlinuxgnu" Lisp implementation type: "CLISP" Lisp implementation version: "2.42 (20071016) (built 3403443236) (memory 3555653780)"  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3585135&group_id=4933 
From: SourceForge.net <noreply@so...>  20121107 12:42:45

Bugs item #3585135, was opened at 20121107 04:41 Message generated for change (Comment added) made by tomasriker You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3585135&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: David Scherfgen (tomasriker) Assigned to: Nobody/Anonymous (nobody) Summary: trigrat loops forever, depending on how you call it Initial Comment: The following works: e : 2*x/(sqrt(y)+x)  (x^2/((sqrt(y)+x)^2)); trigrat(e); trigrat(xthru(e)); Both of the following lines will make the second "trigrat" call take forever (100% CPU utilization, will never return): ( trigrat(e), trigrat(xthru(e)) ); [ trigrat(e), trigrat(xthru(e)) ]; So: evaluating both lines separately works, but evaluating them together or inside a function will cause the "bug". If you switch the expressions, it works fine: ( trigrat(e), trigrat(xthru(e)) ); /* loops forever */ ( trigrat(xthru(e)), trigrat(e) ); /* works */  >Comment By: David Scherfgen (tomasriker) Date: 20121107 04:42 Message: Maxima version: "5.28.0" Maxima build date: "20120903 11:36:16" Host type: "x86_64unknownlinuxgnu" Lisp implementation type: "CLISP" Lisp implementation version: "2.42 (20071016) (built 3403443236) (memory 3555653780)"  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3585135&group_id=4933 
From: SourceForge.net <noreply@so...>  20121107 12:41:16

Bugs item #3585135, was opened at 20121107 04:41 Message generated for change (Tracker Item Submitted) made by tomasriker You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3585135&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: David Scherfgen (tomasriker) Assigned to: Nobody/Anonymous (nobody) Summary: trigrat loops forever, depending on how you call it Initial Comment: The following works: e : 2*x/(sqrt(y)+x)  (x^2/((sqrt(y)+x)^2)); trigrat(e); trigrat(xthru(e)); Both of the following lines will make the second "trigrat" call take forever (100% CPU utilization, will never return): ( trigrat(e), trigrat(xthru(e)) ); [ trigrat(e), trigrat(xthru(e)) ]; So: evaluating both lines separately works, but evaluating them together or inside a function will cause the "bug". If you switch the expressions, it works fine: ( trigrat(e), trigrat(xthru(e)) ); /* loops forever */ ( trigrat(xthru(e)), trigrat(e) ); /* works */  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3585135&group_id=4933 
From: SourceForge.net <noreply@so...>  20121102 06:32:01

Bugs item #3560390, was opened at 20120821 08:42 Message generated for change (Comment added) made by rtoy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3560390&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: Fixed Priority: 5 Private: No Submitted By: Jerry W. Lewis (statsman) Assigned to: Nobody/Anonymous (nobody) Summary: negative_binomial overly restrictive Initial Comment: The negative binomial distribution need not be restricted to integer values of the argument n; cf. http://en.wikipedia.org/wiki/Negative_binomial_distribution Indeed, the noninteger case as an overdispersed generalization of the Poisson distribution is important in many fields, including ecology, environmental monitoring, epidemiology, industrial safety, insurance, medicine, microbiology, etc. Here are function definitions for the general negative binomial pdf and cdf pdf_negative_binomial2(x,n,p) := pdf_beta(p,n,x+1)*p/(n+x)$ /* negative binomial for real n>0 */ cdf_negative_binomial2(x,n,p) := cdf_beta(p,n,x+1)$ /* negative binomial for real n>0 */ The functions for mean, var, std, skewness, and kurtosis should be fine if you just remove the trap for noninteger n. Assuming that the quantile function numerically inverts the cdf, then it would likely be fine too.  >Comment By: Raymond Toy (rtoy) Date: 20121101 23:32 Message: Actually close the bug.  Comment By: Mario Rodriguez Riotorto (riotorto) Date: 20120822 09:12 Message: Thanks for bringing this to our attention. It's now fixed in git repository. Instead of using pdf_beta, we call beta_incomplete_regularized and the floor function to take into account the discrete nature of the r.v. Also, quantile_negative_binomial needed a bug fix.  Mario  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3560390&group_id=4933 
From: SourceForge.net <noreply@so...>  20121102 06:30:41

Bugs item #3578373, was opened at 20121019 05:39 Message generated for change (Comment added) made by rtoy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3578373&group_id=4933 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Barton Willis (willisbl) Assigned to: Nobody/Anonymous (nobody) Summary: hgfred([1/2,a+1],[a+2],x); Initial Comment: (%i1) hgfred([1/2,a+1],[a+2],x); expt: undefined: 0 to a negative exponent.  >Comment By: Raymond Toy (rtoy) Date: 20121101 23:30 Message: A&S 15.2.16 doesn't help, but A&S 15.2.14 gives an answer because hgfred([a+1,b],[c],z) and hgfred([a,b+1],[c],z) can be expressed in terms of associated Legendre function and an elementary function. Assuming I did things correctly, hgfred([1/2,a+1],[a+2],x) = (2^(a+1)*assoc_legendre_p(a,a1,sqrt(1z))*gamma(a+2)*z^(a/21/2) +(2*a+2)*sqrt(1z)) /(2*a+3) I don't have any algorithm to determine that unfortunately. Perhaps it's best that maxima just returns the 2F1 function itself instead of generating an error.  Comment By: Raymond Toy (rtoy) Date: 20121030 19:37 Message: Maxima is using the A&S 15.2.6 to derive the value from F(1/2, a+1; a+1; x). But that's equal to sqrt(1x) and 15.2.6 is not valid in that case. Perhaps 15.2.16 should have been used instead?  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3578373&group_id=4933 
From: SourceForge.net <noreply@so...>  20121102 00:45:02

Bugs item #3582205, was opened at 20121031 04:28 Message generated for change (Settings changed) made by willisbl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3582205&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: Invalid Priority: 5 Private: No Submitted By: https://www.google.com/accounts () Assigned to: Nobody/Anonymous (nobody) Summary: is(2.0=2) returns false Initial Comment: It appears that the decimal of a number is not evaluated as equal to the number itself. I believe it may have roots in the data type the strings are translated into, but I wish to ask the rationale (so that I can work robustly with it) or if it is a bug. Thanks.  Comment By: https://www.google.com/accounts () Date: 20121031 11:03 Message: This is not a bug. Read the documentation for "=" which mentions that when used with is, this means, essentially, syntactic equality. You want to use is(equal(2.0,2)) which does return true.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3582205&group_id=4933 