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}
(9) 
_{Sep}

_{Oct}

_{Nov}

_{Dec}

S  M  T  W  T  F  S 




1
(3) 
2
(2) 
3
(1) 
4

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

14
(4) 
15

16
(2) 
17

18
(5) 
19
(3) 
20

21
(3) 
22

23
(1) 
24

25

26
(1) 
27

28
(1) 
29
(2) 
30
(4) 
31


From: SourceForge.net <noreply@so...>  20081021 13:05:15

Bugs item #2184396, was opened at 20081021 22:05 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2184396&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: Satoshi Adachi (satoshi_adachi) Assigned to: Nobody/Anonymous (nobody) Summary: Wrong factorization of sqrt() Initial Comment: Dear Developers of Maxima, I found a wrong behavihor of sqrt(). It is a principle that sqrt(X*Y) should not be factorized to sqrt(X)*sqrt(Y) unless X and Y can be judged to be nonnegative. I found a case in which this principle is broken. Here is a program for demonstration:  /* * wrong_factorization_of_sqrt.maxima: * * S.Adachi 2008/10/01 */ display2d:false; /* real for 1 <= x <= 2 */ correct:sqrt((11/x)*(2/x1)); /* real for 2sqrt(2) <= x <= 2+sqrt(2) */ INCORRECT:sqrt((1(2sqrt(2))/x)*((2+sqrt(2))/x1)); INCORRECT_AT_2:at(INCORRECT,[x=2]); SHOULD_BE_POSITIVE:float(INCORRECT_AT_2); /* END */  The result of execution is as follows:  Maxima 5.14.0cvs http://maxima.sourceforge.net Using Lisp GNU Common Lisp (GCL) GCL 2.6.7 (aka GCL) 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) batch(wrong_factorization_of_sqrt.maxima) batching #p/Volumes/HFS+2/home/adachi/work/307/wrong_factorization_of_sqrt.maxima (%i2) display2d : false (%o2) false (%i3) correct:sqrt((11/x)*(2/x1)) (%o3) sqrt((11/x)*(2/x1)) (%i4) INCORRECT:sqrt((1(2sqrt(2))/x)*((sqrt(2)+2)/x1)) (%o4) sqrt((2sqrt(2))/x1)*sqrt(1(sqrt(2)+2)/x) (%i5) INCORRECT_AT_2:at(INCORRECT,[x = 2]) (%o5) sqrt((2sqrt(2))/21)*sqrt(1(sqrt(2)+2)/2) (%i6) SHOULD_BE_POSITIVE:float(INCORRECT_AT_2) (%o6) 0.70710678118655 (%o7) "wrong_factorization_of_sqrt.maxima"  At first, as is seen from (%i2) and (%o2), sqrt(11/x)*(2/x1)) is not factorized to sqrt(...)*sqrt(...) in any automatic way. This is the correct behavihor. Next, as is seen from (%i3) and (%o3), sqrt(1(2sqrt(2))/x)*((2+sqrt(2))/x1)) is factorized to sqrt((2sqrt(2))/x1)*sqrt(1(sqrt(2)+2)/x) in an automatic way. THIS IS AN INCORRECT BEHAVIOR. This expression is nonnegative for 2sqrt(2) <= x <= 2+sqrt(2). However, as is demonstrated by (%i4)(%o5), the calculated expression takes a negative value at x=2. Please stop the incorrect factorization of sqrt(X*Y) to sqrt(X)*sqrt(Y). Sincerely yours, Satoshi Adachi  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2184396&group_id=4933 
From: SourceForge.net <noreply@so...>  20081021 12:52:28

Bugs item #2159499, was opened at 20081011 11:11 Message generated for change (Comment added) made by rtoy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2159499&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: Dieter Kaiser (crategus) Assigned to: Nobody/Anonymous (nobody) Summary: Full bigfloat precision for Gamma after the second call Initial Comment: In a lot of cases (for some not) we get the full bigfloat precison for the Gamma function not in a first call but in a second call to the function: (%i4) fpprintprec:3; (%o4) 3 That is the first call. We get the full precision. If we have a fresh maxima and increase fpprec the first time we always get the full precision. (%i5) fpprec:64; (%o5) 64 (%i6) gamma(bfloat(1/2))bfloat(gamma(1/2)); (%o6) 3.11b62 Increasing fpprec. First call. Missing precision. (%i7) fpprec:128; (%o7) 128 (%i8) gamma(bfloat(1/2))bfloat(gamma(1/2)); (%o8) 1.91b91 Second call. Full precision. (%i9) gamma(bfloat(1/2))bfloat(gamma(1/2)); (%o9) 5.43b126 Increasing fpprec. First call. Missing precision. (%i10) fpprec:256; (%o10) 256 (%i11) gamma(bfloat(1/2))bfloat(gamma(1/2)); (%o11) 1.03b182 Now the second call. (%i12) gamma(bfloat(1/2))bfloat(gamma(1/2)); (%o12) 1.21b253 Increasing fpprec. Now full precsion in the first call. (%i13) fpprec:300; (%o13) 300 (%i14) gamma(bfloat(1/2))bfloat(gamma(1/2)); (%o14) 1.97b297 And again. Increasing fpprec. Missing precesion in the first call. (%i15) fpprec:512; (%o15) 512 (%i16) gamma(bfloat(1/2))bfloat(gamma(1/2)); (%o16) 3.0b365 Dieter Kaiser  >Comment By: Raymond Toy (rtoy) Date: 20081021 08:52 Message: Link to email thread on this topic: http://www.math.utexas.edu/pipermail/maxima/2008/013946.html  Comment By: Dieter Kaiser (crategus) Date: 20081021 06:59 Message: After a bug fix in float.lisp the effect that we do not get the full precision in a first call to gamma has vanished. Log Message of the bug fix in float.lisp: 1. bug fix for fppi1 helper function fprt18231_ (dependence on $fpprec caused wrong results when fpprec was changed by an other function) 2. another version of fprt18231_ added, which was tested to be faster in clisp and sbcl (author: Raymond Toy) Closing this bug report. Dieter Kaiser  Comment By: Dieter Kaiser (crategus) Date: 20081012 18:11 Message: I have studied the effect in more detail and detected that we have the problem only for a negative argument to bffac. That is true for gamma(0.5b0). The reflection formula calculates: bfloat(%pi*z/sin(%pi*z))/bffac(z,fpprec) If we add an additional bfloat to be sure that the argument of the sin function has the correct precision the described effect that we need a second call to get the full precision vanish. The modified line of code is bfloat(%pi*z/sin(bfloat(%pi*z)))/bffac(z,fpprec) I have not really understand the effect, but it seems to me that it works. Perhaps there is a problem with the sin function. Any comment? Dieter Kaiser  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2159499&group_id=4933 
From: SourceForge.net <noreply@so...>  20081021 10:59:50

Bugs item #2159499, was opened at 20081011 17:11 Message generated for change (Comment added) made by crategus You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2159499&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: Dieter Kaiser (crategus) Assigned to: Nobody/Anonymous (nobody) Summary: Full bigfloat precision for Gamma after the second call Initial Comment: In a lot of cases (for some not) we get the full bigfloat precison for the Gamma function not in a first call but in a second call to the function: (%i4) fpprintprec:3; (%o4) 3 That is the first call. We get the full precision. If we have a fresh maxima and increase fpprec the first time we always get the full precision. (%i5) fpprec:64; (%o5) 64 (%i6) gamma(bfloat(1/2))bfloat(gamma(1/2)); (%o6) 3.11b62 Increasing fpprec. First call. Missing precision. (%i7) fpprec:128; (%o7) 128 (%i8) gamma(bfloat(1/2))bfloat(gamma(1/2)); (%o8) 1.91b91 Second call. Full precision. (%i9) gamma(bfloat(1/2))bfloat(gamma(1/2)); (%o9) 5.43b126 Increasing fpprec. First call. Missing precision. (%i10) fpprec:256; (%o10) 256 (%i11) gamma(bfloat(1/2))bfloat(gamma(1/2)); (%o11) 1.03b182 Now the second call. (%i12) gamma(bfloat(1/2))bfloat(gamma(1/2)); (%o12) 1.21b253 Increasing fpprec. Now full precsion in the first call. (%i13) fpprec:300; (%o13) 300 (%i14) gamma(bfloat(1/2))bfloat(gamma(1/2)); (%o14) 1.97b297 And again. Increasing fpprec. Missing precesion in the first call. (%i15) fpprec:512; (%o15) 512 (%i16) gamma(bfloat(1/2))bfloat(gamma(1/2)); (%o16) 3.0b365 Dieter Kaiser  >Comment By: Dieter Kaiser (crategus) Date: 20081021 12:59 Message: After a bug fix in float.lisp the effect that we do not get the full precision in a first call to gamma has vanished. Log Message of the bug fix in float.lisp: 1. bug fix for fppi1 helper function fprt18231_ (dependence on $fpprec caused wrong results when fpprec was changed by an other function) 2. another version of fprt18231_ added, which was tested to be faster in clisp and sbcl (author: Raymond Toy) Closing this bug report. Dieter Kaiser  Comment By: Dieter Kaiser (crategus) Date: 20081013 00:11 Message: I have studied the effect in more detail and detected that we have the problem only for a negative argument to bffac. That is true for gamma(0.5b0). The reflection formula calculates: bfloat(%pi*z/sin(%pi*z))/bffac(z,fpprec) If we add an additional bfloat to be sure that the argument of the sin function has the correct precision the described effect that we need a second call to get the full precision vanish. The modified line of code is bfloat(%pi*z/sin(bfloat(%pi*z)))/bffac(z,fpprec) I have not really understand the effect, but it seems to me that it works. Perhaps there is a problem with the sin function. Any comment? Dieter Kaiser  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2159499&group_id=4933 