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}
(7) 
_{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...>  20121117 13:07:21

Bugs item #3588159, was opened at 20121117 05:07 Message generated for change (Tracker Item Submitted) made by jdh8 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3588159&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: ChenPang He (jdh8) Assigned to: Nobody/Anonymous (nobody) Summary: y = x^k substitution technique Initial Comment: Maxima fails to integrate((x^5+x^2)/(x^6+x^3+1),x); However, it successes to integrate(x^5/(x^6+x^3+1),x) + integrate(x^2/(x^6+x^3+1),x); I think we can check the gcd of powers of the x's in x*f(x) when integrating f(x)  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3588159&group_id=4933 
From: SourceForge.net <noreply@so...>  20121116 15:50:07

Bugs item #3587932, was opened at 20121116 07:50 Message generated for change (Tracker Item Submitted) made by You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3587932&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: https://www.google.com/accounts () Assigned to: Nobody/Anonymous (nobody) Summary: Incorrect integral Initial Comment: (%i9) quad_qag((2/3)*x^(5/2)*(x+1)^(1/2),x,0,1,3); (%o9) [.2536334149282484,6.748751768357728e11,31,0] Right, because this is a positive function. But: (%i10) integrate((2/3)*x^(5/2)*(x+1)^.5,x,0,1); 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 2.0 by 2/1 = 2.0 rat: replaced 5.0 by 5/1 = 5.0 rat: replaced 5.0 by 5/1 = 5.0 (%o10) 2^(7/2)/9 Whatever this is, it isn't positive. float() gives 1.257078722109418 The following seems to be okay, though the answer is extremely annoying. (%i11) integrate((2/3)*x^(5/2)*(x+1)^(1/2),x,0,1); (%o11) 2*((15*log(sqrt(2)+1)15*log(1sqrt(2))61*2^(3/2))/3845*log(1)/128)/3 (%i14) expand(float(expand(integrate((2/3)*x^(5/2)*(x+1)^(1/2),x,0,1)))); (%o14) 0.2536334149287  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3587932&group_id=4933 
From: SourceForge.net <noreply@so...>  20121116 14:46:01

Bugs item #3539587, was opened at 20120702 16:48 Message generated for change (Comment added) made by pcpa You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3539587&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: Paulo Andrade (pcpa) Assigned to: Nobody/Anonymous (nobody) Summary: disablereadline has no effect in clisp backend Initial Comment: Hi, I just made a bug report for Fedora maxima package where I attached a patch I have been keeping in Mandriva for quite some time. It is required to allow sagemath work properly with maxima using clisp as backend. The fedora bug report is at https://bugzilla.redhat.com/show_bug.cgi?id=837142 But I am afraid the patch is not fully complete (in the sense of maxima's disablereadline option), and I just workaround it differently in my sagemath package for gcl with this patch http://svn.mandriva.com/cgibin/viewvc.cgi/packages/cooker/sagemath/current/SOURCES/sage4.8maxima.patch?view=markup that I will adapt to fedora; note the "":lisp #+gcl (progn (si:readlineoff) (setf *erroroutput* (open "/dev/stderr" :direction :output)..."" in the patch... Thanks  >Comment By: Paulo Andrade (pcpa) Date: 20121116 06:46 Message: Sorry about link. Previous one pointed to "head" commit, but I renamed the file. This should work http://svn.mandriva.com/cgibin/viewvc.cgi/packages/cooker/sagemath/current/SOURCES/sagemaxima.patch?revision=822115&view=markup The patch sets *erroroutput* to stderr because by default it is aliased to *terminalio* (probably due to the pexpect python code allocating a pty where it talks to maxima), and that causes sagemath to dead lock due to failing to parse maxima/gcl output as stdout and stderr are in the same fd. Note that I maintain these patches in my Mandriva, and now my (not yet "official") Fedora sagemath package. Upstream sagemath supports only the ecl maxima backend (that is now built in Fedora maxima since this patch http://pkgs.fedoraproject.org/cgit/maxima.git/commit/?id=ea0b7f2ee66bbc08de07c83217ac44790147c581)  Comment By: Raymond Toy (rtoy) Date: 20121115 08:12 Message: The redhat patch for clisp seems reasonable. The mandriva patch seems to be unreachable. Why are you setting *erroroutput* to stderr for gcl? Why is that needed?  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3539587&group_id=4933 
From: SourceForge.net <noreply@so...>  20121116 04:56:41

Bugs item #3587760, was opened at 20121115 20:56 Message generated for change (Tracker Item Submitted) made by dilijev You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3587760&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: Doug Ilijev (dilijev) Assigned to: Nobody/Anonymous (nobody) Summary: Empty statements should be ignored instead of causing error Initial Comment: Consider an empty statement: ; Or a comment followed by a semicolon to terminate the line: /*...*/; Both situations yield error: (%i15) ; incorrect syntax: Premature termination of input at ;. ;  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3587760&group_id=4933 
From: SourceForge.net <noreply@so...>  20121115 20:45:57

Bugs item #3587583, was opened at 20121115 12:45 Message generated for change (Tracker Item Submitted) made by d4v33 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3587583&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: David Geistert (d4v33) Assigned to: Nobody/Anonymous (nobody) Summary: Can\'t solve some equation with sqrt inside Initial Comment: Cant solve some equation with sqrt inside like: sqrt(2*x+3)+2*(2*x+3) = 55  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3587583&group_id=4933 
From: SourceForge.net <noreply@so...>  20121115 16:12:51

Bugs item #3539587, was opened at 20120702 16:48 Message generated for change (Comment added) made by rtoy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3539587&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: Paulo Andrade (pcpa) Assigned to: Nobody/Anonymous (nobody) Summary: disablereadline has no effect in clisp backend Initial Comment: Hi, I just made a bug report for Fedora maxima package where I attached a patch I have been keeping in Mandriva for quite some time. It is required to allow sagemath work properly with maxima using clisp as backend. The fedora bug report is at https://bugzilla.redhat.com/show_bug.cgi?id=837142 But I am afraid the patch is not fully complete (in the sense of maxima's disablereadline option), and I just workaround it differently in my sagemath package for gcl with this patch http://svn.mandriva.com/cgibin/viewvc.cgi/packages/cooker/sagemath/current/SOURCES/sage4.8maxima.patch?view=markup that I will adapt to fedora; note the "":lisp #+gcl (progn (si:readlineoff) (setf *erroroutput* (open "/dev/stderr" :direction :output)..."" in the patch... Thanks  >Comment By: Raymond Toy (rtoy) Date: 20121115 08:12 Message: The redhat patch for clisp seems reasonable. The mandriva patch seems to be unreachable. Why are you setting *erroroutput* to stderr for gcl? Why is that needed?  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3539587&group_id=4933 
From: SourceForge.net <noreply@so...>  20121115 16:00:17

Bugs item #3587362, was opened at 20121114 20:09 Message generated for change (Comment added) made by rtoy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3587362&group_id=4933 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Lisp Core  Floating point Group: None >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Raymond Toy (rtoy) Assigned to: Nobody/Anonymous (nobody) Summary: inverse_erfc(1d40) wrong Initial Comment: inverse_erf(1d40) > 5.918. But erfc(5.918) > 5.758e17, which isn't even close to 1d40. erfc(9) > 4.13e37.  >Comment By: Raymond Toy (rtoy) Date: 20121115 08:00 Message: Fixed.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3587362&group_id=4933 
From: SourceForge.net <noreply@so...>  20121115 13:53:56

Bugs item #3587514, was opened at 20121115 05:53 Message generated for change (Tracker Item Submitted) made by You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3587514&group_id=4933 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Share Libraries Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: https://www.google.com/accounts () Assigned to: Nobody/Anonymous (nobody) Summary: simplify_sum simplifies incorrectly Initial Comment: Maxima 5.28.0 http://maxima.sourceforge.net using Lisp SBCL 1.0.55.0abb03f9 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) load(simplify_sum); (%o1) /Applications/MathApps/Maxima.app/Contents/Resources/maxima/share/maxima\ /5.28.0/share/solve_rec/simplify_sum.mac (%i2) simplify_sum(sum(1/((2*n1)^2*(2*n+1)^2*(2*n+3)^2), n, 0, inf)); 2 %pi 2   4 %pi 2 (%o2)  +  128 128 But this is not right. The extra 1/32 is spurious. (%i4) float(simplify_sum(sum(1/((2*n1)^2*(2*n+1)^2*(2*n+3)^2), n, 0, 100))); (%o4) .1156594265749686 (%i5) float (simplify_sum(sum(1/((2*n1)^2*(2*n+1)^2*(2*n+3)^2), n, 0, inf))); (%o5) .08440942657526591 (%i6) float(1/32); (%o6) 0.03125 This was first reported at http://trac.sagemath.org/sage_trac/ticket/13712 and http://ask.sagemath.org/question/1985/unexpectedresultforthesumofaseries  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3587514&group_id=4933 
From: SourceForge.net <noreply@so...>  20121115 04:09:27

Bugs item #3587362, was opened at 20121114 20:09 Message generated for change (Tracker Item Submitted) made by rtoy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3587362&group_id=4933 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Lisp Core  Floating point Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Raymond Toy (rtoy) Assigned to: Nobody/Anonymous (nobody) Summary: inverse_erfc(1d40) wrong Initial Comment: inverse_erf(1d40) > 5.918. But erfc(5.918) > 5.758e17, which isn't even close to 1d40. erfc(9) > 4.13e37.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3587362&group_id=4933 
From: SourceForge.net <noreply@so...>  20121115 03:35:51

Bugs item #3587304, was opened at 20121114 15:51 Message generated for change (Settings changed) made by rtoy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3587304&group_id=4933 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. >Category: Lisp Core  Floating point Group: None Status: Closed Resolution: Fixed Priority: 5 Private: No Submitted By: Raymond Toy (rtoy) Assigned to: Nobody/Anonymous (nobody) Summary: erfc(x) for x > 6 is wrong Initial Comment: erfc(6.0) > 0.0. But the asymptotic series for erfc(x) = exp(z^2)/z/sqrt(%pi) so the right answer is close to 2.18e17.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3587304&group_id=4933 
From: SourceForge.net <noreply@so...>  20121115 03:35:35

Bugs item #3587304, was opened at 20121114 15:51 Message generated for change (Settings changed) made by rtoy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3587304&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: Raymond Toy (rtoy) Assigned to: Nobody/Anonymous (nobody) Summary: erfc(x) for x > 6 is wrong Initial Comment: erfc(6.0) > 0.0. But the asymptotic series for erfc(x) = exp(z^2)/z/sqrt(%pi) so the right answer is close to 2.18e17.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3587304&group_id=4933 
From: SourceForge.net <noreply@so...>  20121115 03:35:03

Bugs item #3587191, was opened at 20121114 10:30 Message generated for change (Settings changed) made by rtoy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3587191&group_id=4933 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Lisp Core  Floating point Group: None >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Raymond Toy (rtoy) Assigned to: Nobody/Anonymous (nobody) Summary: erf inaccurate for small bigfloat values Initial Comment: erf(1b20) > 1.387778780781446b17 The correct answer is closer to 1.128379167095513b20. This is caused by bfloaterf computing erf using 1gamma_incomplete(1/2,x^2)/sqrt(%pi). For small x, gamma_incomplete(1/2,x^2) is very close to sqrt(%pi), so we lose lots of precision using this formula. For small x, we should just use the taylor series.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3587191&group_id=4933 
From: SourceForge.net <noreply@so...>  20121115 03:34:19

Bugs item #3587184, was opened at 20121114 10:19 Message generated for change (Comment added) made by rtoy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3587184&group_id=4933 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Lisp Core  Floating point Group: None >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Raymond Toy (rtoy) Assigned to: Nobody/Anonymous (nobody) Summary: erf inaccurate for small float values Initial Comment: erf(1d10) > 1.128e40 But the taylor series says erf(x) = 2*x/sqrt(%pi) so erf(1d10) should be 1.128e20. The error is in slatec:derf which is using the wrong formula when x < sqeps.  >Comment By: Raymond Toy (rtoy) Date: 20121114 19:34 Message: Fixed by modifying derf.f and derf.lisp  Comment By: Raymond Toy (rtoy) Date: 20121114 10:20 Message: Change summary to mention this is just for float values.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3587184&group_id=4933 
From: SourceForge.net <noreply@so...>  20121114 23:51:59

Bugs item #3587304, was opened at 20121114 15:51 Message generated for change (Tracker Item Submitted) made by rtoy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3587304&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: erfc(x) for x > 6 is wrong Initial Comment: erfc(6.0) > 0.0. But the asymptotic series for erfc(x) = exp(z^2)/z/sqrt(%pi) so the right answer is close to 2.18e17.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3587304&group_id=4933 
From: SourceForge.net <noreply@so...>  20121114 23:42:25

Bugs item #3587295, was opened at 20121114 15:38 Message generated for change (Comment added) made by rtoy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3587295&group_id=4933 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Lisp Core  Floating point Group: None >Status: Closed >Resolution: Duplicate Priority: 5 Private: No Submitted By: Raymond Toy (rtoy) Assigned to: Nobody/Anonymous (nobody) Summary: erf inaccurate for small bigfloat values Initial Comment: erf(1b20) > 1.387778780781446b17 The correct answer is closer to 1.128379167095513b20. This is caused by bfloaterf computing erf using 1gamma_incomplete(1/2,x^2)/sqrt(%pi). For small x, gamma_incomplete(1/2,x^2) is very close to sqrt(%pi), so we lose lots of precision using this formula. For small x, we should just use the taylor series.  >Comment By: Raymond Toy (rtoy) Date: 20121114 15:42 Message: Oops. This is duplicate of 3587191.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3587295&group_id=4933 
From: SourceForge.net <noreply@so...>  20121114 23:38:15

Bugs item #3587295, was opened at 20121114 15:38 Message generated for change (Tracker Item Submitted) made by rtoy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3587295&group_id=4933 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Lisp Core  Floating point Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Raymond Toy (rtoy) Assigned to: Nobody/Anonymous (nobody) Summary: erf inaccurate for small bigfloat values Initial Comment: erf(1b20) > 1.387778780781446b17 The correct answer is closer to 1.128379167095513b20. This is caused by bfloaterf computing erf using 1gamma_incomplete(1/2,x^2)/sqrt(%pi). For small x, gamma_incomplete(1/2,x^2) is very close to sqrt(%pi), so we lose lots of precision using this formula. For small x, we should just use the taylor series.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3587295&group_id=4933 
From: SourceForge.net <noreply@so...>  20121114 18:30:30

Bugs item #3587191, was opened at 20121114 10:30 Message generated for change (Tracker Item Submitted) made by rtoy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3587191&group_id=4933 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Lisp Core  Floating point Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Raymond Toy (rtoy) Assigned to: Nobody/Anonymous (nobody) Summary: erf inaccurate for small bigfloat values Initial Comment: erf(1b20) > 1.387778780781446b17 The correct answer is closer to 1.128379167095513b20. This is caused by bfloaterf computing erf using 1gamma_incomplete(1/2,x^2)/sqrt(%pi). For small x, gamma_incomplete(1/2,x^2) is very close to sqrt(%pi), so we lose lots of precision using this formula. For small x, we should just use the taylor series.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3587191&group_id=4933 
From: SourceForge.net <noreply@so...>  20121114 18:20:15

Bugs item #3587184, was opened at 20121114 10:19 Message generated for change (Comment added) made by rtoy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3587184&group_id=4933 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Lisp Core  Floating point Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Raymond Toy (rtoy) Assigned to: Nobody/Anonymous (nobody) >Summary: erf inaccurate for small float values Initial Comment: erf(1d10) > 1.128e40 But the taylor series says erf(x) = 2*x/sqrt(%pi) so erf(1d10) should be 1.128e20. The error is in slatec:derf which is using the wrong formula when x < sqeps.  >Comment By: Raymond Toy (rtoy) Date: 20121114 10:20 Message: Change summary to mention this is just for float values.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3587184&group_id=4933 
From: SourceForge.net <noreply@so...>  20121114 18:19:42

Bugs item #3587184, was opened at 20121114 10:19 Message generated for change (Tracker Item Submitted) made by rtoy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3587184&group_id=4933 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Lisp Core  Floating point Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Raymond Toy (rtoy) Assigned to: Nobody/Anonymous (nobody) Summary: erf inaccurate for small values Initial Comment: erf(1d10) > 1.128e40 But the taylor series says erf(x) = 2*x/sqrt(%pi) so erf(1d10) should be 1.128e20. The error is in slatec:derf which is using the wrong formula when x < sqeps.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3587184&group_id=4933 
From: SourceForge.net <noreply@so...>  20121114 18:09:22

Bugs item #3586225, was opened at 20121111 09:44 Message generated for change (Comment added) made by rtoy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3586225&group_id=4933 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Lisp Core  Floating point Group: None >Status: Closed >Resolution: Invalid Priority: 5 Private: No Submitted By: Raymond Toy (rtoy) Assigned to: Nobody/Anonymous (nobody) Summary: inverse_erf(1d10) fails to converge Initial Comment: inverse_erf(1d10) doesn't converge. But there shouldn't really be a problem since the taylor series converges nicely there.  >Comment By: Raymond Toy (rtoy) Date: 20121114 10:09 Message: Closing.  Comment By: Raymond Toy (rtoy) Date: 20121114 08:13 Message: Interesting. This happens because there's a bug in erf. In particular, slatec::derf is wrong. When x < sqeps (approx 1.49e8), derf uses erf = 2*x*x/sqrt(%pi). But the taylor series for erf is 2*x/sqrt(%pi). When this is fixed, inverse_erf(1d10) converges very quickly.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3586225&group_id=4933 
From: SourceForge.net <noreply@so...>  20121114 16:13:24

Bugs item #3586225, was opened at 20121111 09:44 Message generated for change (Comment added) made by rtoy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3586225&group_id=4933 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Lisp Core  Floating point Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Raymond Toy (rtoy) Assigned to: Nobody/Anonymous (nobody) Summary: inverse_erf(1d10) fails to converge Initial Comment: inverse_erf(1d10) doesn't converge. But there shouldn't really be a problem since the taylor series converges nicely there.  >Comment By: Raymond Toy (rtoy) Date: 20121114 08:13 Message: Interesting. This happens because there's a bug in erf. In particular, slatec::derf is wrong. When x < sqeps (approx 1.49e8), derf uses erf = 2*x*x/sqrt(%pi). But the taylor series for erf is 2*x/sqrt(%pi). When this is fixed, inverse_erf(1d10) converges very quickly.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3586225&group_id=4933 
From: SourceForge.net <noreply@so...>  20121111 17:44:03

Bugs item #3586225, was opened at 20121111 09:44 Message generated for change (Tracker Item Submitted) made by rtoy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3586225&group_id=4933 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Lisp Core  Floating point Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Raymond Toy (rtoy) Assigned to: Nobody/Anonymous (nobody) Summary: inverse_erf(1d10) fails to converge Initial Comment: inverse_erf(1d10) doesn't converge. But there shouldn't really be a problem since the taylor series converges nicely there.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3586225&group_id=4933 
From: SourceForge.net <noreply@so...>  20121111 17:32:04

Bugs item #3536976, was opened at 20120621 11:54 Message generated for change (Comment added) made by rtoy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3536976&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: X.W. (ximingwu) Assigned to: Nobody/Anonymous (nobody) Summary: "inverse_erf" doesn't allow complex arguments Initial Comment: "erf" allows both real and complex arguments. It gives complex results when the arguments are complex. Its inverse, inverse_efc, however, only allows real argument. E.g. inverse_erf(0.5) gives: 0.47693627620447 inverse_erf(0.5*%i) gives: inverse_erf(0.5*%i)  >Comment By: Raymond Toy (rtoy) Date: 20121111 09:32 Message: Fixed in git. inverse_erf(0.5*%i) > 0.417527625591501*%i inverse_erf(10.0) > .5144382945583941  1.900029220045678 * %i inverse_erf(10b0) > 5.144382945583946b1  1.900029220045678b0 * %i inverse_erf(10b0+100b0*%I) > 2.441141526980323b0 * %i + 2.293471655772661b2  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3536976&group_id=4933 
From: SourceForge.net <noreply@so...>  20121111 09:54:08

Bugs item #3586183, was opened at 20121111 01:54 Message generated for change (Tracker Item Submitted) made by tomasriker You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3586183&group_id=4933 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Share Libraries Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: David Scherfgen (tomasriker) Assigned to: Nobody/Anonymous (nobody) Summary: conditional_integrate returns redundant conditions Initial Comment: load(abs_integrate); conditional_integrate(a^x + b^x, x); gives: %if(?%and(a1 # 0,b1 # 0),(log(a)*b^x+a^x*log(b))/(log(a)*log(b)), %if(?%and(a1 # 0,b1 = 0),%if(a1 # 0,(log(a)*x+a^x)/log(a),2*x), %if(?%and(a1 = 0,b1 # 0), %if(b1 # 0,(log(b)*x+b^x)/log(b),2*x),2*x))) The second "%if" in the second line (the one testing for "a1 # 0") is redundant, since "a1 # 0" was already checked for in the surrounding "%if". The same holds true for the first "%if" in the last line.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3586183&group_id=4933 
From: SourceForge.net <noreply@so...>  20121110 17:28:22

Bugs item #3564492, was opened at 20120903 14:17 Message generated for change (Comment added) made by rtoy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3564492&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  Complex Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: carg(1),numer => %pi Initial Comment: carg(1),numer => %pi Should be float 3.14. Similarly for polarform(1),numer  >Comment By: Raymond Toy (rtoy) Date: 20121110 09:28 Message: The carg(1) issue will be fixed soon. But what do you expect for polarform? With the current fix, this will return 1.0*exp(3.14*%i) That seems acceptable.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3564492&group_id=4933 