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}
(17) 
_{Oct}

_{Nov}

_{Dec}

S  M  T  W  T  F  S 



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

11

12
(9) 
13
(1) 
14
(3) 
15
(4) 
16
(2) 
17
(5) 
18

19

20

21
(1) 
22

23
(3) 
24
(5) 
25

26
(3) 
27

28

29
(2) 
30
(1) 
31



From: SourceForge.net <noreply@so...>  20110330 00:11:41

Bugs item #3258734, was opened at 20110329 19:11 Message generated for change (Tracker Item Submitted) made by willisbl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3258734&group_id=4933 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Share Libraries Group: None Status: Open Resolution: None Priority: 4 Private: No Submitted By: Barton Willis (willisbl) Assigned to: Nobody/Anonymous (nobody) Summary: to_poly_solve  spurious complex solution Initial Comment: (%i347) declare(x,complex)$ (%i348) [conjugate(x)  x = 0, sqrt(x^21)  conjugate(sqrt(x^21))=0]$ Wrongthe solution set is empty (%i349) %solve(%,x); (%o349) %union([x=%c1191]) See also https://groups.google.com/group/sagesupport/browse_thread/thread/a105bcce5be83ee?hl=en  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3258734&group_id=4933 
From: SourceForge.net <noreply@so...>  20110329 09:30:39

Bugs item #3256672, was opened at 20110329 11:30 Message generated for change (Tracker Item Submitted) made by mrverify You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3256672&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: Mikael Samsøe Sørensen (mrverify) Assigned to: Nobody/Anonymous (nobody) Summary: Incorrect integral Initial Comment: integrate(sqrt(1(cos(x))^2),x,0,1); gives Wrong answer. Incorrect sign i think.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3256672&group_id=4933 
From: SourceForge.net <noreply@so...>  20110329 02:41:08

Bugs item #3220118, was opened at 20110317 11:02 Message generated for change (Comment added) made by rtoy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3220118&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: Raymond Toy (rtoy) Assigned to: Nobody/Anonymous (nobody) Summary: erf(1+5*%i) not accurate Initial Comment: erf(1.0+5*%i) returns  2.7837671212125964e+9 %i  1.0786562260474622e+9 But the true answer (as given by Wolfram/Alpha) is  2.7837702922089653e+9 %i  1.0786931161985406e+9 Only about 4 digits are correct.  >Comment By: Raymond Toy (rtoy) Date: 20110328 22:41 Message: Actually, the continued fraction http://functions.wolfram.com/06.06.10.0009.01 appears to converge faster and to be more accurate. The previously mentioned fraction has some issues for points near the negative real axis where the accuracy is not as good as we might expect.  Comment By: Raymond Toy (rtoy) Date: 20110324 18:17 Message: Here is an alternative method of computing gamma_incomplete: http://functions.wolfram.com/06.06.10.0007.01 There appear to be no restrictions on the range of validity of this continued fraction, so it can probably be used for other areas. I've tested this a bit (with oct), and it converges quickly for things on or near the negative real axis. The few tests I've done indicate that accuracy is good.  Comment By: Dieter Kaiser (crategus) Date: 20110324 15:06 Message: Hello Ray, you are right. The problem is the function gamma_incomplete. The continued fraction expansion of the function tends to converge to a wrong value for some ranges of the argument. In the past, I had searched for some hints in the literature to solve this problem more general. But I had not found a simple solution. Therefore, I had done a heuristic approach and checked several ranges for the arguments to achieve a better approximation of the function gamma_incomplete. I have to work again on this problem. Dieter Kaiser  Comment By: Raymond Toy (rtoy) Date: 20110324 09:27 Message: I think the inaccuracy comes from gammaincomplete, which is used to evaluate erf. For this particular argument, gammaincomplete uses the series. I think the test of when to use the series could be relaxed a bit. When I set *gammaimag* to 0.1, the continued fraction is used, which gives  2.7837770292209086e+9 %i  1.0786931161985383e+9 This is better. I've done some experiments using the continued fraction http://functions.wolfram.com/06.06.10.0005.01. This seems to work a bit better.  Comment By: Barton Willis (willisbl) Date: 20110317 22:51 Message: By the way: using a 1F1 representation for erf, the values agree with Wolfram  Alpha. But the hypergeometric code has to switch to bigfloats to do this: (%i11) my_erf(x) := nfloat(2*x*hypergeometric([1/2],[3/2],x^2)/sqrt(%pi),[]); (%o11) my_erf(x):=nfloat((2*x*hypergeometric([1/2],[3/2],x^2))/sqrt(%pi),[]) (%i12) load(hypergeometric)$ (%i14) my_erf(1.0+5*%i); (%o14) 2.783777029220896b9*%i1.078693116198541b9  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3220118&group_id=4933 
From: SourceForge.net <noreply@so...>  20110326 20:20:04

Bugs item #3200565, was opened at 20110305 15:37 Message generated for change (Settings changed) made by sfrobot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3200565&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: Works For Me Priority: 5 Private: No Submitted By: johappy (johappy) Assigned to: Nobody/Anonymous (nobody) Summary: problem with "makelist" Initial Comment: a[i]:=a0*q^i; a0:1;q:1/2; a[9]; ==> 1/512 thats o.k. a[10]; ==> q^10 ???? makelist(a[i],i,1,12); ==> [1/2,1/4,1/8,1/16,1/32,1/64,1/128,1/256,1/512,q^10,1/2048,1/4096] ??? a[10] is not evaluated !!  >Comment By: SourceForge Robot (sfrobot) Date: 20110326 20:20 Message: This Tracker item was closed automatically by the system. It was previously set to a Pending status, and the original submitter did not respond within 14 days (the time period specified by the administrator of this Tracker).  Comment By: Dieter Kaiser (crategus) Date: 20110312 20:11 Message: I do not see the observed problem. I get the following result: (%i1) a[i]:=a0*q^i$ (%i2) a0:1$ q:1/2$ (%i4) makelist(a[i],i,1,12); (%o4) [1/2,1/4,1/8,1/16,1/32,1/64,1/128,1/256,1/512,1/1024, 1/2048,1/4096] I can reproduce the example with the following input: (%i1) a[i]:=a0*q^i$ (%i2) a0:1$ (%i3) a[10]; (%o3) q^10 (%i4) q:1/2$ (%i5) makelist(a[i],i,1,12); (%o5) [1/2,1/4,1/8,1/16,1/32,1/64,1/128,1/256,1/512,q^10,1/2048, 1/4096] Perhaps, in an earlier step a value was assigned to a[10] like in the example from above. Setting the status to pending and the resolution to "works for me". Dieter Kaiser  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3200565&group_id=4933 
From: SourceForge.net <noreply@so...>  20110326 16:38:55

Bugs item #3247367, was opened at 20110326 11:38 Message generated for change (Tracker Item Submitted) made by willisbl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3247367&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: expand returns unsimplified Initial Comment: I thought that expand returned a simplified expression; maybe it does not: (%i241) (1sqrt(5))^34*(1sqrt(5))^2+8; (%o241) (1sqrt(5))^34*(1sqrt(5))^2+8 (%i242) expand(%); (%o242) 5^(3/2)5^(3/2) (%i243) expand(%,0,0); (%o243) 0 Ratexpand crunches this to zero without the additional simplification: (%i244) ratexpand((1sqrt(5))^34*(1sqrt(5))^2+8); (%o244) 0 Dieter also reports the bug (http://www.math.utexas.edu/pipermail/maxima/2011/024700.html) (%i4) sqrt(2)+sqrt(2)+sqrt(2); (%o4) 2^(3/2)+sqrt(2)  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3247367&group_id=4933 
From: SourceForge.net <noreply@so...>  20110326 14:46:45

Bugs item #3247176, was opened at 20110326 09:46 Message generated for change (Tracker Item Submitted) made by willisbl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3247176&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: ratmx and matrix_element_mult Initial Comment: When ratmx is true, a nondefault value for matrix_element_mult does not work correctly; example (%i275) a : matrix([matrix([1,3],[0,2]),matrix([4,4],[1,1])],[matrix([4,0],[3,3]),matrix([3,3],[4,0])]); (%o275) matrix([matrix([1,3],[0,2]),matrix([4,4],[1,1])],[matrix([4,0],[3,3]),matrix([3,3],[4,0])]) (%i276) a.a, ratmx : true, matrix_element_mult : "."; (%o276)/R/ matrix([matrix([1,3],[0,2])^2+matrix([4,0],[3,3])*matrix([4,4],[1,1]),matrix([4,4],[1,1])*matrix([1,3],[0,2])+matrix([3,3],[4,0])*matrix([4,4],[1,1])],[matrix([4,0],[3,3])*matrix([1,3],[0,2])+matrix([3,3],[4,0])*matrix([4,0],[3,3]),matrix([4,0],[3,3])*matrix([4,4],[1,1])+matrix([3,3],[4,0])^2]) See also bug 1911030  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3247176&group_id=4933 
From: SourceForge.net <noreply@so...>  20110324 22:17:34

Bugs item #3220118, was opened at 20110317 11:02 Message generated for change (Comment added) made by rtoy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3220118&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: Raymond Toy (rtoy) Assigned to: Nobody/Anonymous (nobody) Summary: erf(1+5*%i) not accurate Initial Comment: erf(1.0+5*%i) returns  2.7837671212125964e+9 %i  1.0786562260474622e+9 But the true answer (as given by Wolfram/Alpha) is  2.7837702922089653e+9 %i  1.0786931161985406e+9 Only about 4 digits are correct.  >Comment By: Raymond Toy (rtoy) Date: 20110324 18:17 Message: Here is an alternative method of computing gamma_incomplete: http://functions.wolfram.com/06.06.10.0007.01 There appear to be no restrictions on the range of validity of this continued fraction, so it can probably be used for other areas. I've tested this a bit (with oct), and it converges quickly for things on or near the negative real axis. The few tests I've done indicate that accuracy is good.  Comment By: Dieter Kaiser (crategus) Date: 20110324 15:06 Message: Hello Ray, you are right. The problem is the function gamma_incomplete. The continued fraction expansion of the function tends to converge to a wrong value for some ranges of the argument. In the past, I had searched for some hints in the literature to solve this problem more general. But I had not found a simple solution. Therefore, I had done a heuristic approach and checked several ranges for the arguments to achieve a better approximation of the function gamma_incomplete. I have to work again on this problem. Dieter Kaiser  Comment By: Raymond Toy (rtoy) Date: 20110324 09:27 Message: I think the inaccuracy comes from gammaincomplete, which is used to evaluate erf. For this particular argument, gammaincomplete uses the series. I think the test of when to use the series could be relaxed a bit. When I set *gammaimag* to 0.1, the continued fraction is used, which gives  2.7837770292209086e+9 %i  1.0786931161985383e+9 This is better. I've done some experiments using the continued fraction http://functions.wolfram.com/06.06.10.0005.01. This seems to work a bit better.  Comment By: Barton Willis (willisbl) Date: 20110317 22:51 Message: By the way: using a 1F1 representation for erf, the values agree with Wolfram  Alpha. But the hypergeometric code has to switch to bigfloats to do this: (%i11) my_erf(x) := nfloat(2*x*hypergeometric([1/2],[3/2],x^2)/sqrt(%pi),[]); (%o11) my_erf(x):=nfloat((2*x*hypergeometric([1/2],[3/2],x^2))/sqrt(%pi),[]) (%i12) load(hypergeometric)$ (%i14) my_erf(1.0+5*%i); (%o14) 2.783777029220896b9*%i1.078693116198541b9  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3220118&group_id=4933 
From: Mario Rodriguez <biomates@te...>  20110324 19:36:52

> These all appear to be caused by the adaptive plotter. It's getting > stuck because it thinks the curve is not smooth enough, which, I think, > is caused by some roundoff. This can be fixed by changing the threshold > to be a bit bigger. > > Not sure why we need the adaptive plotter if we're plotting explicit > points. Maybe we should also change the adaptiveplot depth to 1 > instead of the default of 5 or so? Hello, This change can be applied with option 'adapt_depth': draw2d(adapt_depth = 1, explicit(321.4567,x,0,1)); In the following simulation, variable 'tempos' stores execution times for 'adapt_depth' equal to 1 thru 7: tempos: [0.528033, 1.012063, 2.128133, 4.592288, 10.476654, 26.369647, 76.280767] $ draw2d(points_joined=true, points(tempos)) $  Mario 
From: SourceForge.net <noreply@so...>  20110324 19:06:28

Bugs item #3220118, was opened at 20110317 16:02 Message generated for change (Comment added) made by crategus You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3220118&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: Raymond Toy (rtoy) Assigned to: Nobody/Anonymous (nobody) Summary: erf(1+5*%i) not accurate Initial Comment: erf(1.0+5*%i) returns  2.7837671212125964e+9 %i  1.0786562260474622e+9 But the true answer (as given by Wolfram/Alpha) is  2.7837702922089653e+9 %i  1.0786931161985406e+9 Only about 4 digits are correct.  >Comment By: Dieter Kaiser (crategus) Date: 20110324 20:06 Message: Hello Ray, you are right. The problem is the function gamma_incomplete. The continued fraction expansion of the function tends to converge to a wrong value for some ranges of the argument. In the past, I had searched for some hints in the literature to solve this problem more general. But I had not found a simple solution. Therefore, I had done a heuristic approach and checked several ranges for the arguments to achieve a better approximation of the function gamma_incomplete. I have to work again on this problem. Dieter Kaiser  Comment By: Raymond Toy (rtoy) Date: 20110324 14:27 Message: I think the inaccuracy comes from gammaincomplete, which is used to evaluate erf. For this particular argument, gammaincomplete uses the series. I think the test of when to use the series could be relaxed a bit. When I set *gammaimag* to 0.1, the continued fraction is used, which gives  2.7837770292209086e+9 %i  1.0786931161985383e+9 This is better. I've done some experiments using the continued fraction http://functions.wolfram.com/06.06.10.0005.01. This seems to work a bit better.  Comment By: Barton Willis (willisbl) Date: 20110318 03:51 Message: By the way: using a 1F1 representation for erf, the values agree with Wolfram  Alpha. But the hypergeometric code has to switch to bigfloats to do this: (%i11) my_erf(x) := nfloat(2*x*hypergeometric([1/2],[3/2],x^2)/sqrt(%pi),[]); (%o11) my_erf(x):=nfloat((2*x*hypergeometric([1/2],[3/2],x^2))/sqrt(%pi),[]) (%i12) load(hypergeometric)$ (%i14) my_erf(1.0+5*%i); (%o14) 2.783777029220896b9*%i1.078693116198541b9  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3220118&group_id=4933 
From: SourceForge.net <noreply@so...>  20110324 13:32:19

Bugs item #3220128, was opened at 20110317 11:06 Message generated for change (Comment added) made by rtoy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3220128&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: Raymond Toy (rtoy) Assigned to: Nobody/Anonymous (nobody) >Summary: gamma_incomplete(1/2, 24+10*%i) not accurate Initial Comment: Maxima says gamma_incomplete(1/2,20+10*%i),float is 4.93408396056858e+9 %i + 1.91200542673871e+9 Wolfram/Alpha says the value is 4.9341163e+9 + 1.911933e+9 Maxima's answer is only accurate to about 5 digits.  >Comment By: Raymond Toy (rtoy) Date: 20110324 09:32 Message: Setting *gammaimag* to .1d0 (so the region where we use the continued fraction is enlarged), improves the result to 4.93411631550489e+9 %i + 1.911933769523828e+9 Wolfram/Alpha gives 4.9341163155048952691479351508925718965852838271239234... × 10^9 i + 1.9119337695238284027493471541730604272204040299891632... × 10^9 Essentially full accuracy.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3220128&group_id=4933 
From: SourceForge.net <noreply@so...>  20110324 13:27:50

Bugs item #3220118, was opened at 20110317 11:02 Message generated for change (Comment added) made by rtoy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3220118&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: Raymond Toy (rtoy) Assigned to: Nobody/Anonymous (nobody) Summary: erf(1+5*%i) not accurate Initial Comment: erf(1.0+5*%i) returns  2.7837671212125964e+9 %i  1.0786562260474622e+9 But the true answer (as given by Wolfram/Alpha) is  2.7837702922089653e+9 %i  1.0786931161985406e+9 Only about 4 digits are correct.  >Comment By: Raymond Toy (rtoy) Date: 20110324 09:27 Message: I think the inaccuracy comes from gammaincomplete, which is used to evaluate erf. For this particular argument, gammaincomplete uses the series. I think the test of when to use the series could be relaxed a bit. When I set *gammaimag* to 0.1, the continued fraction is used, which gives  2.7837770292209086e+9 %i  1.0786931161985383e+9 This is better. I've done some experiments using the continued fraction http://functions.wolfram.com/06.06.10.0005.01. This seems to work a bit better.  Comment By: Barton Willis (willisbl) Date: 20110317 22:51 Message: By the way: using a 1F1 representation for erf, the values agree with Wolfram  Alpha. But the hypergeometric code has to switch to bigfloats to do this: (%i11) my_erf(x) := nfloat(2*x*hypergeometric([1/2],[3/2],x^2)/sqrt(%pi),[]); (%o11) my_erf(x):=nfloat((2*x*hypergeometric([1/2],[3/2],x^2))/sqrt(%pi),[]) (%i12) load(hypergeometric)$ (%i14) my_erf(1.0+5*%i); (%o14) 2.783777029220896b9*%i1.078693116198541b9  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3220118&group_id=4933 
From: Raymond Toy <toy.raymond@gm...>  20110323 22:46:13

On 3/23/11 10:22 AM, Andrzej Brozi wrote: > Hallo > > I have a strange problem with draw2d(explicit(... . > > It took some time but I boiled down the problem to the > following: > > When I issue command similar to the following one: > > wxdraw2d( > explicit(321.4567,x,0,1) > ); > > (it doesn't matter if it's "draw2d" or "wxdraw2d") > > it may produce plot (straight line in this case) or practically hang > Maxima (I mean Maxima uses one processor core fully and when left on > its own for half an hour it doesn't produce plot). > > This behavior depends on the value: > > for 321.4, 321.456, 321.45678 it works fine  producing plot under a > second, > > for 321.45, 321.4567, 321.456789 it 'hangs' Maxima. Interesting! These all appear to be caused by the adaptive plotter. It's getting stuck because it thinks the curve is not smooth enough, which, I think, is caused by some roundoff. This can be fixed by changing the threshold to be a bit bigger. Not sure why we need the adaptive plotter if we're plotting explicit points. Maybe we should also change the adaptiveplot depth to 1 instead of the default of 5 or so? Ray 
From: SourceForge.net <noreply@so...>  20110323 18:53:44

Bugs item #3238314, was opened at 20110323 13:53 Message generated for change (Tracker Item Submitted) made by willisbl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3238314&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  Translator Group: None Status: Open Resolution: None Priority: 4 Private: No Submitted By: Barton Willis (willisbl) Assigned to: Nobody/Anonymous (nobody) Summary: declare in compiled code Initial Comment: (%i14) george() := block([z : gensym()], declare(z,complex), z)$ OK: (%i15) george(); (%o15) g3082 Not OK: (%i16) compile(george)$ ;Compiler warnings : ; In $GEORGE: Undefined function $DECLARE ; In $GEORGE: Undeclared free variable $COMPLEX (%i17) george(); Maxima encountered a Lisp error: Unbound variable: $COMPLEX Automatically continuing. To enable the Lisp debugger set *debuggerhook* to nil.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3238314&group_id=4933 
From: Andrzej Brozi <andrzej.brozi@p.lodz.pl>  20110323 14:22:57

Hallo I have a strange problem with draw2d(explicit(... . It took some time but I boiled down the problem to the following: When I issue command similar to the following one: wxdraw2d( explicit(321.4567,x,0,1) ); (it doesn't matter if it's "draw2d" or "wxdraw2d") it may produce plot (straight line in this case) or practically hang Maxima (I mean Maxima uses one processor core fully and when left on its own for half an hour it doesn't produce plot). This behavior depends on the value: for 321.4, 321.456, 321.45678 it works fine  producing plot under a second, for 321.45, 321.4567, 321.456789 it 'hangs' Maxima. Something similar may be found for other numbers  originally I stumbled on it trying to plot a variable being the righthand side of an equation which happened to be a constant (equal to 399.3). Same situation on two computers, one with Windows XP Pro SP3 and the other one with Windows 7 Professional. I've tested it on Maxima 5.23.2 and 5.22.1  same behavior. I asked someone to try it on a Linux computer (Maxima 5.22.1 with wxMaxima 0.8.7)  again same problem. I've repeated this using XMaxima (on Windows 7 Professional)  again same problem. "wxplot2d" works fine on all cases. It seems to me that it is a (surprising) bug, and it probably concerns the "draw" package. Best regards Andrzej Brozi 
From: SourceForge.net <noreply@so...>  20110321 00:00:07

Bugs item #3211937, was opened at 20110314 16:05 Message generated for change (Comment added) made by dgildea You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3211937&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: https://www.google.com/accounts () Assigned to: Nobody/Anonymous (nobody) Summary: wrong sign for integral of e^(1/x^2) Initial Comment: This function is obviously always positive (except where it's not defined, at x=0). But the outcome is the wrong sign. Maxima 5.23.2 http://maxima.sourceforge.net using Lisp SBCL 1.0.24 Distributed under the GNU Public License. See the file COPYING. Dedicated to the memory of William Schelter. The function bug_report() provides bug reporting information. (%i1) integrate(%e^(1/x^2),x,0,1); STYLEWARNING: redefining SIMPUNITSTEP in DEFUN STYLEWARNING: redefining SIMPPOCHHAMMER in DEFUN 1 gamma_incomplete( , 1) 2 (%o1)   2 (%i2) float(%); (%o2)  .08907385589078087 As we can see, the number is right, it's just the sign that's off: (%i11) quad_qags(%e^(1/x^2),x,0,1); (%o11) [.08907385589078033, 2.454578575984028e13, 105, 0]  >Comment By: Dan Gildea (dgildea) Date: 20110320 20:00 Message: fixed in defint.lisp rev 1.87. in changeofvariable routines, do not reuse original variable of integration, in order to avoid assumptions from original limits of integration.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3211937&group_id=4933 
From: SourceForge.net <noreply@so...>  20110317 15:06:09

Bugs item #3220128, was opened at 20110317 11:06 Message generated for change (Tracker Item Submitted) made by rtoy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3220128&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: Raymond Toy (rtoy) Assigned to: Nobody/Anonymous (nobody) Summary: gamma_incomplete(1/2, 24*10*%i) not accurate Initial Comment: Maxima says gamma_incomplete(1/2,20+10*%i),float is 4.93408396056858e+9 %i + 1.91200542673871e+9 Wolfram/Alpha says the value is 4.9341163e+9 + 1.911933e+9 Maxima's answer is only accurate to about 5 digits.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3220128&group_id=4933 
From: SourceForge.net <noreply@so...>  20110317 15:02:21

Bugs item #3220118, was opened at 20110317 11:02 Message generated for change (Tracker Item Submitted) made by rtoy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3220118&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: Raymond Toy (rtoy) Assigned to: Nobody/Anonymous (nobody) Summary: erf(1+5*%i) not accurate Initial Comment: erf(1.0+5*%i) returns  2.7837671212125964e+9 %i  1.0786562260474622e+9 But the true answer (as given by Wolfram/Alpha) is  2.7837702922089653e+9 %i  1.0786931161985406e+9 Only about 4 digits are correct.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3220118&group_id=4933 
From: SourceForge.net <noreply@so...>  20110317 14:53:54

Bugs item #3220095, was opened at 20110317 10:53 Message generated for change (Tracker Item Submitted) made by rtoy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3220095&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: Raymond Toy (rtoy) Assigned to: Nobody/Anonymous (nobody) Summary: gamma_incomplete_regularized doesn't honor gamma_expand Initial Comment: gamma_incomplete_generalized(a,z1,z2) doesn't honor gamma_expand. The code looks like it does, but nothing happens for gamma_incomplete_generalized(2,1,2); This works, though: gamma_incomplete_generalized(a+2,1,2);  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3220095&group_id=4933 
From: SourceForge.net <noreply@so...>  20110317 14:48:40

Bugs item #3220078, was opened at 20110317 10:48 Message generated for change (Tracker Item Submitted) made by rtoy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3220078&group_id=4933 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Raymond Toy (rtoy) Assigned to: Nobody/Anonymous (nobody) Summary: gamma_expand not documented Initial Comment: gamma_expand should be documented (and mentioned in the docs for gamma_incomplete and friends). A nice feature enhancement would be allow gamma_expand to have a value so that gamma_incomplete(a,z) is expanded if a < gamma_expand.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3220078&group_id=4933 
From: SourceForge.net <noreply@so...>  20110317 14:46:10

Bugs item #3220071, was opened at 20110317 10:46 Message generated for change (Tracker Item Submitted) made by rtoy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3220071&group_id=4933 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Raymond Toy (rtoy) Assigned to: Nobody/Anonymous (nobody) Summary: gamma_incomplete should document gamma_expand Initial Comment: The documentation for gamma_incomplete (and friends) should metnion gamma_expand. (And gamma_expand should be documented, but that's a different bug.)  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3220071&group_id=4933 
From: SourceForge.net <noreply@so...>  20110316 16:09:10

Bugs item #3216684, was opened at 20110316 16:09 Message generated for change (Tracker Item Submitted) made by You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3216684&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: https://www.google.com/accounts () Assigned to: Nobody/Anonymous (nobody) Summary: solution not in domain, and others missed Initial Comment: Maxima 5.23.2 http://maxima.sourceforge.net using Lisp ECL 11.1.1 Distributed under the GNU Public License. See the file COPYING. Dedicated to the memory of William Schelter. The function bug_report() provides bug reporting information. (%i1) solve([(2*x^2/(x^2 + y^2) + log(x^2 + y^2))*(x^2 + y^2)^x,2*x*y*(x^2 + y^2)^(x  1)],[x,y]); (%o1) [[x = 0, y = 0]] This is not in the domain of the first expression. Further, there are four actual solutions which are not found. (%i8) f(x,y):=(2*x^2/(x^2 + y^2) + log(x^2 + y^2))*(x^2 + y^2)^x; 2 2 2 2 x 2 2 x (%o8) f(x, y) := (log(y + x ) + ) (y + x ) 2 2 y + x (%i9) g(x,y):=2*x*y*(x^2 + y^2)^(x  1); 2 2 x  1 (%o9) g(x, y) := 2 x y (y + x ) (%i10) f(0,1); (%o10) 0 (%i11) g(0,1); (%o11) 0 (%i17) f(1/%e,0); (%o17) 0 (%i18) g(1/%e,0); (%o18) 0  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3216684&group_id=4933 
From: SourceForge.net <noreply@so...>  20110316 15:54:59

Bugs item #3216641, was opened at 20110316 11:54 Message generated for change (Tracker Item Submitted) made by macrakis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3216641&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: Open Resolution: None Priority: 7 Private: No Submitted By: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: taylor(rat(...)...) gives incorrect results Initial Comment: taylor(1/x,x,1,2) => 1(x1)+(x1)^2  OK taylor(rat(1/x),x,1,2) => +1/x  NO: not a Taylor series at x=1 Maxima 5.23.2 GCL 2.6.8 Windows 7  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3216641&group_id=4933 
From: SourceForge.net <noreply@so...>  20110315 20:11:52

Bugs item #3211975, was opened at 20110314 16:38 Message generated for change (Settings changed) made by dgildea You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3211975&group_id=4933 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. >Category: Lisp Core  Integration Group: None >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: https://www.google.com/accounts () Assigned to: Nobody/Anonymous (nobody) Summary: Integral shouldn't be zero, but Maxima says it is Initial Comment: The following behavior leads to some weird results. In particular, if one plots cos(w+T)/(1+e*cos(T))^2 for various 0<e<1 and various w, it becomes clear that the answer shouldn't be zero. This is also tracked at http://trac.sagemath.org/sage_trac/ticket/8728 Maxima 5.23.2 http://maxima.sourceforge.net using Lisp SBCL 1.0.24 Distributed under the GNU Public License. See the file COPYING. Dedicated to the memory of William Schelter. The function bug_report() provides bug reporting information. (%i1) assume(1e^2>0); 2 (%o1) [e < 1] (%i3) integrate(cos(w+T)/(1+e*cos(T))^2,T,0,2*%pi); (%o3) 0 (%i4) integrate(cos(w+T)/(1+.5*cos(T))^2,T,0,2*%pi); rat: replaced 0.5 by 1/2 = 0.5 rat: replaced 0.5 by 1/2 = 0.5 rat: replaced 0.5 by 1/2 = 0.5 rat: replaced 0.5 by 1/2 = 0.5 rat: replaced 0.5 by 1/2 = 0.5 rat: replaced 0.0625 by 1/16 = 0.0625 (%o4) 0 (%i5) integrate(cos(.5+T)/(1+.25*cos(T))^2,T,0,2*%pi); rat: replaced 0.25 by 1/4 = 0.25 rat: replaced 0.5 by 1/2 = 0.5 rat: replaced 0.5 by 1/2 = 0.5 rat: replaced 0.25 by 1/4 = 0.25 rat: replaced 0.25 by 1/4 = 0.25 rat: replaced 0.5 by 1/2 = 0.5 rat: replaced 0.25 by 1/4 = 0.25 rat: replaced 0.25 by 1/4 = 0.25 rat: replaced 0.015625 by 1/64 = 0.015625 rat: replaced 0.5 by 1/2 = 0.5 (%o5) 0 (%i6) keepfloat:True; (%o6) True (%i7) integrate(cos(.5+T)/(1+.25*cos(T))^2,T,0,2*%pi); Maxima encountered a Lisp error: The value 0.0625 is not of type FIXNUM. Automatically continuing. To enable the Lisp debugger set *debuggerhook* to nil.  >Comment By: Dan Gildea (dgildea) Date: 20110315 16:11 Message: Fixed in defint.lisp rev 1.86. However, lisp error with keepfloat:true is still present. (%i5) integrate(cos(w+T)/(1+(1/2)*cos(T))^2,T,0,2*%pi); (%o5) 8*%pi*cos(w)/3^(3/2) (%i4) integrate(cos(w+T)/(1+.5*cos(T))^2,T,0,2*%pi); rat: replaced 0.5 by 1/2 = 0.5 rat: replaced 0.5 by 1/2 = 0.5 rat: replaced 0.5 by 1/2 = 0.5 rat: replaced 0.5 by 1/2 = 0.5 rat: replaced 1.0 by 1/1 = 1.0 rat: replaced 0.25 by 1/4 = 0.25 rat: replaced 1.0 by 1/1 = 1.0 rat: replaced 0.25 by 1/4 = 0.25 rat: replaced 1.0 by 1/1 = 1.0 rat: replaced 0.25 by 1/4 = 0.25 rat: replaced 1.0 by 1/1 = 1.0 rat: replaced 0.25 by 1/4 = 0.25 rat: replaced 0.5 by 1/2 = 0.5 rat: replaced 0.0625 by 1/16 = 0.0625 rat: replaced 1.0 by 1/1 = 1.0 rat: replaced 0.25 by 1/4 = 0.25 rat: replaced 1.0 by 1/1 = 1.0 rat: replaced 0.25 by 1/4 = 0.25 rat: replaced 1.0 by 1/1 = 1.0 rat: replaced 0.25 by 1/4 = 0.25 rat: replaced 0.5 by 1/2 = 0.5 rat: replaced 0.0625 by 1/16 = 0.0625 (%o4) 8*%pi*cos(w)/3^(3/2) (%i6) integrate(cos(w+T)/(1+.5*cos(T))^2,T,0,2*%pi),keepfloat:true; Maxima encountered a Lisp error: Typeerror in KERNEL::OBJECTNOTFIXNUMERRORHANDLER: 0.25 is not of type FIXNUM Automatically continuing. To enable the Lisp debugger set *debuggerhook* to nil.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3211975&group_id=4933 
From: SourceForge.net <noreply@so...>  20110315 20:08:04

Bugs item #2989983, was opened at 20100420 12:35 Message generated for change (Comment added) made by dgildea You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2989983&group_id=4933 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Lisp Core  Integration Group: None >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: wrong integration answer Initial Comment: When using sage, and thus Maxima, for the integration of: Cos(T + w) / (1+e cos(T)^2 from 0 to 2*pi, sage (and thus maxima?) gives 0 as answer. There maple gives the answer: 2*pi*e*cos(w)/1e^2)^1.5 the correct commands in sage 4.3.5 are (don't know them in maxima): sage: e = var('e') sage: w = var('w') sage: T = var('T') sage: assume(1e^2>0) sage: integrate(cos(w+T)/(1+e*cos(T))^2, T, 0, 2*pi) 0  >Comment By: Dan Gildea (dgildea) Date: 20110315 16:08 Message: Fixed in defint.lisp rev 1.86. o dintegrate: try trigexpand for cases when arg of trig function is of form x+c. fixes integrate(cos(T+w)/(1+1/2*cos(T))^2, T, 0, 2*%pi) In this integral, the antideriv computed with the generateatan2 flag set to nil for definite integration is incorrect. Expanding before computing the integral works around this problem.  Comment By: Aleksas Domarkas (alex108) Date: 20100420 17:57 Message: Solving with maxima 5.21.0 : (%i1) S: 'integrate(cos(T+w)/(1+e*cos(T))^2, T, 0, 2*%pi)$ (%i2) first(%)$ (%i3) expand(%)$ (%i4) f:trigexpand(%)$ (%i5) F:integrate(f,T)$ "Is "e^21.0" positive or negative?"negative; Antiderivative F is discontinous at T=%pi. For example (%i6) wxplot2d([F], [T,0,2*%pi]),e=1/2,w=1$ plot2d: expression evaluates to nonnumeric value somewhere in plotting range. (%t6) << Graphics >> Then integral is equal (%i7) limit(F,T,%pi,minus)ev(F,T=0)+ev(F,T=2*%pi)limit(F,T,%pi,plus)$ (%i8) sol:ratsimp(%); (%o8) (2*%pi*e*sqrt(1e^2)*cos(w))/(e^42*e^2+1) This is same as Maple answer: (%i9) 2*pi*e*cos(w)/(1e^2)^1.5$  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2989983&group_id=4933 
From: SourceForge.net <noreply@so...>  20110315 17:17:04

Bugs item #3211915, was opened at 20110314 19:53 Message generated for change (Comment added) made by You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3211915&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: None Priority: 5 Private: No Submitted By: https://www.google.com/accounts () Assigned to: Nobody/Anonymous (nobody) Summary: integration of abs(sin(x)) wrong Initial Comment: This definite integral should be 4. Maxima 5.23.2 http://maxima.sourceforge.net using Lisp SBCL 1.0.24 Distributed under the GNU Public License. See the file COPYING. Dedicated to the memory of William Schelter. The function bug_report() provides bug reporting information. (%i1) integrate(abs(sin(x)),x,0,2*%pi); (%o1) 0 One knows this because the following answer is correct, and the multiply by 4: (%i2) integrate(sin(x),x,0,%pi/2); (%o2) 1 See first report at http://trac.sagemath.org/sage_trac/ticket/10914  >Comment By: https://www.google.com/accounts () Date: 20110315 17:17 Message: Apparently this is a duplicate  see https://sourceforge.net/tracker/?func=detail&aid=3165872&group_id=4933&atid=104933, which is closed as fixed.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3211915&group_id=4933 