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}

_{Jun}

_{Jul}

_{Aug}

_{Sep}

_{Oct}

_{Nov}

_{Dec}

S  M  T  W  T  F  S 



1
(6) 
2
(14) 
3
(1) 
4
(1) 
5

6

7
(13) 
8
(6) 
9
(2) 
10
(8) 
11
(4) 
12

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

21
(4) 
22
(7) 
23
(3) 
24

25
(2) 
26
(1) 
27
(1) 
28
(4) 
29
(7) 
30
(3) 
31
(1) 


From: SourceForge.net <noreply@so...>  20091211 09:05:14

Bugs item #2912391, was opened at 20091211 03:01 Message generated for change (Comment added) made by mhs You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2912391&group_id=4933 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Lisp Core  Limit Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Rudolf Vyborny (ynrobyvr) Assigned to: Nobody/Anonymous (nobody) Summary: wrong result Initial Comment: Calculating the limit of x+sqrt(1+x^2) as x goes to  infinity gives the wrong result inf instead of correct answer 0  Comment By: Martin (mhs) Date: 20091211 10:05 Message: I cannot reproduce this on  Maxima version: 5.19.2 Maxima build date: 8:55 8/31/2009 host type: i686pcmingw32 lispimplementationtype: GNU Common Lisp (GCL) lispimplementationversion: GCL 2.6.8  (%i1) expr: x+sqrt(1+x^2); (%o1) sqrt(x^2+1)+x (%i2) limit(expr, x, inf); (%o2) 0 (%i3) limit(expr, x, minf); (%o3) 0  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2912391&group_id=4933 
From: SourceForge.net <noreply@so...>  20091211 09:03:11

Bugs item #2912521, was opened at 20091211 10:03 Message generated for change (Tracker Item Submitted) made by mhs You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2912521&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: Martin (mhs) Assigned to: Nobody/Anonymous (nobody) Summary: taytorat() implementation and documentation Initial Comment: taytorat() produces an internal symbol visible at toplevel (%o2). According to the documentation, taytorat(expr) is equivalent to rat(ratdisrep(expr)), which is not the case here (%o3) (Not sure what rat is trying to do here). (%i1) ft: taylor(f(x,y), [x,y],[a1,a2], [1,1]); taytorat(ft); ratdisrep(ft); rat(%); (%o1) f(a1,a2)+((at('diff(f(x,y),x,1),x=a1))*(xa1)+(at('diff(f(a1,y),y,1),y=a2))*(ya2))+... (%o2) ((at('diff(f(x,y),x,1),x=a1))*(xa1)+(at('diff(f(a1,y),y,1),y=a2))*(ya2))*g36791+f(a1,a2) (%o3) (at('diff(f(a1,y),y,1),y=a2))*(ya2)+(xa1)*(at('diff(f(x,y),x,1),x=a1))+f(a1,a2) (%o4) (at('diff(f(a1,y),y,1),y=a2))*y+(xa1)*(at('diff(f(x,y),x,1),x=a1))(at('diff(f(a1,y),y,1),y=a2))*a2+f(a1,a2) This is with  Maxima version: 5.19.2 Maxima build date: 8:55 8/31/2009 host type: i686pcmingw32 lispimplementationtype: GNU Common Lisp (GCL) lispimplementationversion: GCL 2.6.8   You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2912521&group_id=4933 
From: SourceForge.net <noreply@so...>  20091211 02:01:36

Bugs item #2912391, was opened at 20091211 12:01 Message generated for change (Tracker Item Submitted) made by ynrobyvr You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2912391&group_id=4933 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Lisp Core  Limit Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Rudolf Vyborny (ynrobyvr) Assigned to: Nobody/Anonymous (nobody) Summary: wrong result Initial Comment: Calculating the limit of x+sqrt(1+x^2) as x goes to  infinity gives the wrong result inf instead of correct answer 0  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2912391&group_id=4933 
From: SourceForge.net <noreply@so...>  20091211 00:30:50

Bugs item #2910001, was opened at 20091207 08:16 Message generated for change (Comment added) made by rtoy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2910001&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: Accepted Priority: 5 Private: No Submitted By: Clarphimous (clarphimous) Assigned to: Nobody/Anonymous (nobody) Summary: optimization of bfloat input Initial Comment: When using the input method that goes like 2.53b10, it tends to get very slow with large exponents. This applies for large negative exponents as well. I believe the reason is that it is converting all the digits up to the decimal point into binary, where it really only needs to convert them up to the number of bits of precision. For example: 1b1000000; takes quite a while to perform. Not far above this, Maxima crashes on my system (another bug I was originally investigating, which applies to rational numbers as well). On the other hand, if we do a calculation like x:1b1000; x^40000000; you can get a result in less than a second, although it does have some rounding errors at the end.  >Comment By: Raymond Toy (rtoy) Date: 20091210 19:30 Message: Extra digits are already used, based on the size of the exponent. (Hmm. Should include the exponent and the number in case someone does 12345<many digits>90.123<many more>90 b <bigexp>) And with your example 1.12233445566...b0, maxima computes 11223344556677889900112233/10^25, exactly, and then rounds that (once) to a bfloat with 10 digits. The fast method always rounds at least 3 times, perhaps many more when computing 10b0^n. All of the differences occur with negative exponents. Don't know why that is.  Comment By: Clarphimous (clarphimous) Date: 20091210 17:12 Message: Alrighty. I think what would prevent roundoff errors is if you give it a few extra bits of precision while doing the calculations. In other words, guard digits/bits. If the input is shorter than the number of digits of precision, add some extra zeroes. The calculators I've used usually have 3 guard digits (although they were using binary coded decimal). For example: fpprec: 10; x:1.1223344556677889900112233b0 For this, cut it off 3 digits after the 10th digit. That would be 1.122334455668, with rounding. Then, convert that to binary with some extra bits of precision. Finally, round that answer off to the number of bits you usually have. Another example: a:1.23456789b0; For this I would assume that the actual input is 1.234567890000. Then convert that to binary, and cut off the excess bits when you're done. It might take some experimentation to figure out how how many extra digits and bits you need, but I'm pretty sure this will work. Here is a quick experiment I did where I manually rounded the numbers: fpprec: 10; x:1.1223344556677889900112233b0; x1.122334455b0; y:1.1223344557b0; y1.122334455b0; z:1.12233445567b0; z1.122334455b0; http://www.disillusionary.com/files/exp.png  Comment By: Raymond Toy (rtoy) Date: 20091210 12:40 Message: I've done some work on this, and bfloat input for large inputs is now much faster. 2.53b10 is converted by computing bfloat(253)*10b0^(102). Except the exponent is much larger. Small exponents use the current algorithm. The new algorithm has roundoff issues and about 5% of the time differs from the old algorithm. Perhaps this is acceptable for large exponents.  Comment By: Clarphimous (clarphimous) Date: 20091208 02:22 Message: Okay, I don't know exactly how you'd implement it, as I'm not very knowledgeable about base conversion algorithms (although I do know a little). However, I can tell you that the Sage CAS performs the exact same conversion without taking nearly as long for really large numbers. (On the other hand, the default Sage interface seems to only accept floatingpoint numbers up to around 323,000,000 digits before marking them as "infinity.") First, a 1000 digit bfloat in Maxima: set_display('ascii)$ fpprec:35; x:3.4000000000000000000000000000000001b1000; fpprec:1001; (x+1)1; result: http://www.disillusionary.com/files/maxima_big_a.png Next, the same calculation in Sage. x = 3.4000000000000000000000000000000001e1000 x parent(x) y = ZZ(x) parent(y) y result: http://www.disillusionary.com/files/sage_big_a.png Apparently with this calculation the same number of bits of precision are used. For the next one, though, I had to pad Sage's input with an extra zero to get the same result. In Maxima: fpprec:35; x:3.4000000000000000000000000000000001b5000000; fpprec:1001; x+1b4999000; result: http://www.disillusionary.com/files/maxima_big_b.png And now for Sage x = 3.40000000000000000000000000000000010e5000000 x parent(x) y = ZZ(x) parent(y) y result: http://www.disillusionary.com/files/sage_big_b.png Here is where the results in speed and memory usage come into play. Sage doesn't take any longer than it usually does to store the value of x. So... the point is that there is a way, but I do not know how to do it, myself. I was thinking maybe you could use the same process you use to output the decimal value of the bfloat each time it's displayed... but I don't know if it works both ways.  Comment By: Raymond Toy (rtoy) Date: 20091207 14:48 Message: The algorithm for reading bfloats converts the bfloat to an exact rational. Thus 2.53b10 is 253/100*10^10. This is then converted to a bfloat. So 1b1000000 is converted to the exact rational 10^1000000 and converted to a bfloat. This should incur exactly one rounding operation. I think doing it in any other way will incur additional roundoff errors, and we would very much like that the internal representation be as close as possible to the input number. This is also complicated by the fact that bfloats are internally represented using base 2 exponents, not base 10. Marking as pending/wontfix.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2910001&group_id=4933 