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}
(32) 
_{Aug}

_{Sep}

_{Oct}

_{Nov}

_{Dec}

S  M  T  W  T  F  S 

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

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

14

15
(1) 
16
(3) 
17

18
(2) 
19

20
(2) 
21

22
(2) 
23
(5) 
24
(3) 
25
(2) 
26
(2) 
27

28

29
(1) 
30

31
(2) 




From: SourceForge.net <noreply@so...>  20120731 17:04:39

Bugs item #3547652, was opened at 20120723 08:48 Message generated for change (Comment added) made by rtoy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3547652&group_id=4933 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Lisp Core Group: None >Status: Pending >Resolution: Invalid Priority: 5 Private: No Submitted By: https://www.google.com/accounts () Assigned to: Nobody/Anonymous (nobody) Summary: Differentiation of a function yields wrong answer Initial Comment: build_info("5.27.0","20120508 11:27:57","i686pcmingw32","GNU Common Lisp (GCL)","GCL 2.6.8") The differentiation gives erroneous answer kr2(x):=(sin(%pi*x/2)*sin(%pi*x/3))^2; kr2(x):=(sin((%pi*x)/2)*sin((%pi*x)/3))^2 diff(kr2(x),x,1); (2*%pi*cos((%pi*x)/3)*sin((%pi*x)/3)*sin((%pi*x)/2)^2)/3 + %pi*sin((%pi*x)/3)^2*cos((%pi*x)/2)*sin((%pi*x)/2) This is clearly wrong. The right answer is: (%pi*cos((%pi*x)/3)*sin((%pi*x)/3)*sin((%pi*x)/2)^2)/3 + (%pi*sin((%pi*x)/3)^2*cos((%pi*x)/2)*sin((%pi*x)/2))/2  >Comment By: Raymond Toy (rtoy) Date: 20120731 10:04 Message: Marking as pending/invalid.  Comment By: Raymond Toy (rtoy) Date: 20120723 09:11 Message: Can you explain why you think maxima is wrong? From your example, kr2(x) = kr(x)^2 where kr(x) = sin(%pi*x/2)*sin(%pi*x/3). So diff(kr2(x),x) = 2*kr(x)*diff(kr(x),x) which gives maxima's answer, not yours. In fact, maxima's result is exactly 2 times your proposed correct answer.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3547652&group_id=4933 
From: SourceForge.net <noreply@so...>  20120731 17:03:45

Bugs item #3547315, was opened at 20120722 09:34 Message generated for change (Comment added) made by rtoy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3547315&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: Pending >Resolution: Invalid Priority: 5 Private: No Submitted By: christoph reineke (chrisrein) Assigned to: Nobody/Anonymous (nobody) Summary: Problems with bfloat Initial Comment: Enter: (%i2) fpprec:30; (%o2) 30 (%i3) bfloat((45.12*34.78923)^2); (%o3) 2.46392687692829128354787826538b6 2.46392687692829131776b6 is the correct value. build_info("5.27.0","20120508 11:27:57","i686pcmingw32","GNU Common Lisp (GCL)","GCL 2.6.8") Regards Chris  >Comment By: Raymond Toy (rtoy) Date: 20120731 10:03 Message: Marking as pending/invalid.  Comment By: Raymond Toy (rtoy) Date: 20120724 08:52 Message: There's a misunderstanding on how maxima works. Maxima parses 1.23456789123456789123456789123456789 as an IEEE double precision float, essentially independent of how many extra digits you write out. This number is the exact rational (given by rationalize) 5559999494927579/4503599627370496. When this is converted to a bfloat with a given value of fpprec, the ratio is essentially multiplied by a power of two. When it's printed, these extra digits are produced. If you really want a bfloat with the given digits, use 1.2345...b0. Whether maxima should work this way or not is a different question. That would probably be better discussed on the maxima mailing list as a feature request.  Comment By: christoph reineke (chrisrein) Date: 20120723 23:22 Message: Thanks for your comment, but I’m still convinced that there is a bug somewhere. Please take a look at the following numbers: (%i1) bfloat(1.23456789123456789123456789123456789),fpprec:20; (%o1) 1.2345678912345678935b0 (%i2) bfloat(1.23456789123456789123456789123456789),fpprec:30; (%o2) 1.23456789123456789347699213977b0 (%i3) bfloat(1.23456789123456789123456789123456789),fpprec:40; (%o3) 1.23456789123456789347699213976738974452b0 (%i4) bfloat(1.23456789123456789123456789123456789),fpprec:50; (%o4) 1.2345678912345678934769921397673897445201873779297b0 The trouble begins after the second 9 with the sequence …3476…, which should be…1234… As you see, it doesn’t matter if fpprec=20,30,40 or 50, the precision is always the same! That ain’t got nothing to do with our binary system, fpprec doesn’t work properly. Maxima cannot handle long decimals (more than 17/18 places after the decimal point) and that’s a bug. The function fpprec seems to work if you have to compute real numbers like sqrt(2) or log(3). It never works if you enter long decimals.  Comment By: Raymond Toy (rtoy) Date: 20120723 09:04 Message: When you write 45.12, maxima converts that to a floating point number. But 45.12 cannot be represented exactly in floating point. Same for 34.78923. (You can see what the actual value is by using rationalize(45.12), which is close t o 4512/100, but not the same.) So maxima uses floatingpoint arithmetic to compute (45.12*34.78923)^2. Then that floating point number is converted to a bfloat, giving the result that maxima produces. If you want exact results, use exact rational arithmetic: bfloat((4512/100 * 3478923/100000)^2); 2.46392687692829131776b6 Of course, even that is an approximation because the exact result is 240617859075028449/97656250000, and that can't be represented exactly as a bfloat.  Comment By: christoph reineke (chrisrein) Date: 20120723 02:12 Message: Sorry, but I don’t understand you. <Can you explain why you think the value you give is the correct value?> Which value? (45.12*34.78923)^2=2.46392687692829131776b6=the correct value. Since I expect that the correct value has more than 16 digits after the comma, I use bfloat and fpprec=30. I quote from the documentation: “bfloat (expr) Function Converts all numbers and functions of numbers in expr to bigfloat numbers. The number of significant digits in the resulting bigfloats is specified by the global variable fpprec.” …all numbers…!! Now Maxima returns 30 digits, but the result is wrong. That’s all. <Thus, the simplifier has simplified the float expression…> Which simplifier? If a CAS computes a simple multiplication each digit of the displayed floating point number should be correct (apart from the last), no matter how many digits the user wants. Even if I erroneously “simplify” something, Maxima should never display a wrong result. That’s my opinion. How do I get the correct result? Thanks for your help!  Comment By: Raymond Toy (rtoy) Date: 20120722 13:07 Message: Can you explain why you think the value you give is the correct value? Consider this transcript: (%i1) fpprec:30; (%o1) 30 (%i2) trace(bfloat); (%o2) [bfloat] (%i3) bfloat((45.12*34.78923)^2); 1 Enter bfloat [2463926.876928291] 1 Exit bfloat 2.46392687692829128354787826538b6 (%o3) 2.46392687692829128354787826538b6 Thus, the simplifier has simplified the float expression before bfloat gets a chance to look at it.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3547315&group_id=4933 
From: SourceForge.net <noreply@so...>  20120729 13:24:00

Bugs item #3529144, was opened at 20120523 10:33 Message generated for change (Settings changed) made by dgildea You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3529144&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: Michael Orlitzky (mjorlitzky) Assigned to: Nobody/Anonymous (nobody) Summary: Error integrating exp(x)*sinh(sqrt(x)) with domain: complex Initial Comment: This was previously fixed in bug #3292033, and worked for both real and complex domains in Maxima 5.26. But there seems to have been a regression with domain: complex. This became apparent in Sage where we set domain: complex; by default. ;;; Loading #P"/usr/lib64/ecl12.2.1/sbbsdsockets.fas" ;;; Loading #P"/usr/lib64/ecl12.2.1/sockets.fas" ;;; Loading #P"/usr/lib64/ecl12.2.1/defsystem.fas" ;;; Loading #P"/usr/lib64/ecl12.2.1/cmp.fas" Maxima 5.27.0 http://maxima.sourceforge.net using Lisp ECL 12.2.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) display2d:false; (%o1) false (%i2) integrate(exp(x)*sinh(sqrt(x)),x,0,inf); (%o2) %e^(1/4)*sqrt(%pi)/2 (%i3) domain:complex; (%o3) complex (%i4) integrate(exp(x)*sinh(sqrt(x)),x,0,inf); (%o4) 0  >Comment By: Dan Gildea (dgildea) Date: 20120729 06:23 Message: Fixed in git now (%i7) integrate(exp(x)*sinh(sqrt(x)),x,0,inf),domain:complex; (%o7) %e^(1/4)*(2*gamma_incomplete(1,1)gamma_incomplete(1/2,1)+sqrt(%pi)2)/4 %e^(1/4)*(2*gamma_incomplete(1,1)gamma_incomplete(1/2,1)sqrt(%pi)2)/4 (%i8) ratsimp(%); (%o8) %e^(1/4)*sqrt(%pi)/2  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3529144&group_id=4933 
From: SourceForge.net <noreply@so...>  20120726 16:26:17

Bugs item #3549302, was opened at 20120726 09:26 Message generated for change (Tracker Item Submitted) made by rtoy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3549302&group_id=4933 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Lisp Core  Trigonometry Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Raymond Toy (rtoy) Assigned to: Nobody/Anonymous (nobody) Summary: Lisp error from trigreduce Initial Comment: (%i1) display2d:false; (%o1) false (%i2) expand(subst(x=rectform(exp(%i*%pi/8)), x^8+1)); (%o2) sin(%pi/8)^88*%i*cos(%pi/8)*sin(%pi/8)^728*cos(%pi/8)^2*sin(%pi/8)^6 +56*%i*cos(%pi/8)^3*sin(%pi/8)^5 +70*cos(%pi/8)^4*sin(%pi/8)^4 56*%i*cos(%pi/8)^5*sin(%pi/8)^3 28*cos(%pi/8)^6*sin(%pi/8)^2+8*%i*cos(%pi/8)^7*sin(%pi/8) +cos(%pi/8)^8+1 (%i3) trigreduce(%); Argument V is not a INTEGER: NIL. [Condition of type SIMPLETYPEERROR]  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3549302&group_id=4933 
From: SourceForge.net <noreply@so...>  20120726 16:23:22

Bugs item #3548117, was opened at 20120724 19:23 Message generated for change (Comment added) made by rtoy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3548117&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: 5 Private: No Submitted By: Raymond Toy (rtoy) Assigned to: Nobody/Anonymous (nobody) Summary: taylor(1/(x^8+1),x,rectform(exp(%i*%pi/8)),1) incorrect Initial Comment: The expansion of taylor(1/(x^8+1),x,rectform(exp(%i*%pi/8)),1) appears to be incorrect. The expansion only contains powers of (xexp(%i*%pi/8)). However, taylor(1/(x^8+1),x,exp(%i*%pi/8),1) appears to be correct and very different from the first result.  >Comment By: Raymond Toy (rtoy) Date: 20120726 09:23 Message: If you look at the expansion with rectform, the leading term is free of x. If you run trigreduce and expand on it, you'll get a division by 0 error. I'm guessing taylor returns the wrong result because it couldn't determine that the expression has a pole there.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3548117&group_id=4933 
From: SourceForge.net <noreply@so...>  20120725 18:00:17

Bugs item #3541579, was opened at 20120709 05:01 Message generated for change (Comment added) made by rtoy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3541579&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: arrayinfo gives a Lisp error Initial Comment: Too often, arrayinfo gives a Lisp error; for example, (%i2) arrayinfo('a); Maxima encountered a Lisp error:  >Comment By: Raymond Toy (rtoy) Date: 20120725 11:00 Message: A simple fix. In arrayinfoaux (in comm2.lisp) replace the only call to mgetl with safemgetl.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3541579&group_id=4933 
From: SourceForge.net <noreply@so...>  20120725 02:23:40

Bugs item #3548117, was opened at 20120724 19:23 Message generated for change (Tracker Item Submitted) made by rtoy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3548117&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: 5 Private: No Submitted By: Raymond Toy (rtoy) Assigned to: Nobody/Anonymous (nobody) Summary: taylor(1/(x^8+1),x,rectform(exp(%i*%pi/8)),1) incorrect Initial Comment: The expansion of taylor(1/(x^8+1),x,rectform(exp(%i*%pi/8)),1) appears to be incorrect. The expansion only contains powers of (xexp(%i*%pi/8)). However, taylor(1/(x^8+1),x,exp(%i*%pi/8),1) appears to be correct and very different from the first result.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3548117&group_id=4933 
From: SourceForge.net <noreply@so...>  20120724 15:52:14

Bugs item #3547315, was opened at 20120722 09:34 Message generated for change (Comment added) made by rtoy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3547315&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: christoph reineke (chrisrein) Assigned to: Nobody/Anonymous (nobody) Summary: Problems with bfloat Initial Comment: Enter: (%i2) fpprec:30; (%o2) 30 (%i3) bfloat((45.12*34.78923)^2); (%o3) 2.46392687692829128354787826538b6 2.46392687692829131776b6 is the correct value. build_info("5.27.0","20120508 11:27:57","i686pcmingw32","GNU Common Lisp (GCL)","GCL 2.6.8") Regards Chris  >Comment By: Raymond Toy (rtoy) Date: 20120724 08:52 Message: There's a misunderstanding on how maxima works. Maxima parses 1.23456789123456789123456789123456789 as an IEEE double precision float, essentially independent of how many extra digits you write out. This number is the exact rational (given by rationalize) 5559999494927579/4503599627370496. When this is converted to a bfloat with a given value of fpprec, the ratio is essentially multiplied by a power of two. When it's printed, these extra digits are produced. If you really want a bfloat with the given digits, use 1.2345...b0. Whether maxima should work this way or not is a different question. That would probably be better discussed on the maxima mailing list as a feature request.  Comment By: christoph reineke (chrisrein) Date: 20120723 23:22 Message: Thanks for your comment, but I’m still convinced that there is a bug somewhere. Please take a look at the following numbers: (%i1) bfloat(1.23456789123456789123456789123456789),fpprec:20; (%o1) 1.2345678912345678935b0 (%i2) bfloat(1.23456789123456789123456789123456789),fpprec:30; (%o2) 1.23456789123456789347699213977b0 (%i3) bfloat(1.23456789123456789123456789123456789),fpprec:40; (%o3) 1.23456789123456789347699213976738974452b0 (%i4) bfloat(1.23456789123456789123456789123456789),fpprec:50; (%o4) 1.2345678912345678934769921397673897445201873779297b0 The trouble begins after the second 9 with the sequence …3476…, which should be…1234… As you see, it doesn’t matter if fpprec=20,30,40 or 50, the precision is always the same! That ain’t got nothing to do with our binary system, fpprec doesn’t work properly. Maxima cannot handle long decimals (more than 17/18 places after the decimal point) and that’s a bug. The function fpprec seems to work if you have to compute real numbers like sqrt(2) or log(3). It never works if you enter long decimals.  Comment By: Raymond Toy (rtoy) Date: 20120723 09:04 Message: When you write 45.12, maxima converts that to a floating point number. But 45.12 cannot be represented exactly in floating point. Same for 34.78923. (You can see what the actual value is by using rationalize(45.12), which is close t o 4512/100, but not the same.) So maxima uses floatingpoint arithmetic to compute (45.12*34.78923)^2. Then that floating point number is converted to a bfloat, giving the result that maxima produces. If you want exact results, use exact rational arithmetic: bfloat((4512/100 * 3478923/100000)^2); 2.46392687692829131776b6 Of course, even that is an approximation because the exact result is 240617859075028449/97656250000, and that can't be represented exactly as a bfloat.  Comment By: christoph reineke (chrisrein) Date: 20120723 02:12 Message: Sorry, but I don’t understand you. <Can you explain why you think the value you give is the correct value?> Which value? (45.12*34.78923)^2=2.46392687692829131776b6=the correct value. Since I expect that the correct value has more than 16 digits after the comma, I use bfloat and fpprec=30. I quote from the documentation: “bfloat (expr) Function Converts all numbers and functions of numbers in expr to bigfloat numbers. The number of significant digits in the resulting bigfloats is specified by the global variable fpprec.” …all numbers…!! Now Maxima returns 30 digits, but the result is wrong. That’s all. <Thus, the simplifier has simplified the float expression…> Which simplifier? If a CAS computes a simple multiplication each digit of the displayed floating point number should be correct (apart from the last), no matter how many digits the user wants. Even if I erroneously “simplify” something, Maxima should never display a wrong result. That’s my opinion. How do I get the correct result? Thanks for your help!  Comment By: Raymond Toy (rtoy) Date: 20120722 13:07 Message: Can you explain why you think the value you give is the correct value? Consider this transcript: (%i1) fpprec:30; (%o1) 30 (%i2) trace(bfloat); (%o2) [bfloat] (%i3) bfloat((45.12*34.78923)^2); 1 Enter bfloat [2463926.876928291] 1 Exit bfloat 2.46392687692829128354787826538b6 (%o3) 2.46392687692829128354787826538b6 Thus, the simplifier has simplified the float expression before bfloat gets a chance to look at it.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3547315&group_id=4933 
From: SourceForge.net <noreply@so...>  20120724 06:22:14

Bugs item #3547315, was opened at 20120722 09:34 Message generated for change (Comment added) made by chrisrein You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3547315&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: christoph reineke (chrisrein) Assigned to: Nobody/Anonymous (nobody) Summary: Problems with bfloat Initial Comment: Enter: (%i2) fpprec:30; (%o2) 30 (%i3) bfloat((45.12*34.78923)^2); (%o3) 2.46392687692829128354787826538b6 2.46392687692829131776b6 is the correct value. build_info("5.27.0","20120508 11:27:57","i686pcmingw32","GNU Common Lisp (GCL)","GCL 2.6.8") Regards Chris  >Comment By: christoph reineke (chrisrein) Date: 20120723 23:22 Message: Thanks for your comment, but I’m still convinced that there is a bug somewhere. Please take a look at the following numbers: (%i1) bfloat(1.23456789123456789123456789123456789),fpprec:20; (%o1) 1.2345678912345678935b0 (%i2) bfloat(1.23456789123456789123456789123456789),fpprec:30; (%o2) 1.23456789123456789347699213977b0 (%i3) bfloat(1.23456789123456789123456789123456789),fpprec:40; (%o3) 1.23456789123456789347699213976738974452b0 (%i4) bfloat(1.23456789123456789123456789123456789),fpprec:50; (%o4) 1.2345678912345678934769921397673897445201873779297b0 The trouble begins after the second 9 with the sequence …3476…, which should be…1234… As you see, it doesn’t matter if fpprec=20,30,40 or 50, the precision is always the same! That ain’t got nothing to do with our binary system, fpprec doesn’t work properly. Maxima cannot handle long decimals (more than 17/18 places after the decimal point) and that’s a bug. The function fpprec seems to work if you have to compute real numbers like sqrt(2) or log(3). It never works if you enter long decimals.  Comment By: Raymond Toy (rtoy) Date: 20120723 09:04 Message: When you write 45.12, maxima converts that to a floating point number. But 45.12 cannot be represented exactly in floating point. Same for 34.78923. (You can see what the actual value is by using rationalize(45.12), which is close t o 4512/100, but not the same.) So maxima uses floatingpoint arithmetic to compute (45.12*34.78923)^2. Then that floating point number is converted to a bfloat, giving the result that maxima produces. If you want exact results, use exact rational arithmetic: bfloat((4512/100 * 3478923/100000)^2); 2.46392687692829131776b6 Of course, even that is an approximation because the exact result is 240617859075028449/97656250000, and that can't be represented exactly as a bfloat.  Comment By: christoph reineke (chrisrein) Date: 20120723 02:12 Message: Sorry, but I don’t understand you. <Can you explain why you think the value you give is the correct value?> Which value? (45.12*34.78923)^2=2.46392687692829131776b6=the correct value. Since I expect that the correct value has more than 16 digits after the comma, I use bfloat and fpprec=30. I quote from the documentation: “bfloat (expr) Function Converts all numbers and functions of numbers in expr to bigfloat numbers. The number of significant digits in the resulting bigfloats is specified by the global variable fpprec.” …all numbers…!! Now Maxima returns 30 digits, but the result is wrong. That’s all. <Thus, the simplifier has simplified the float expression…> Which simplifier? If a CAS computes a simple multiplication each digit of the displayed floating point number should be correct (apart from the last), no matter how many digits the user wants. Even if I erroneously “simplify” something, Maxima should never display a wrong result. That’s my opinion. How do I get the correct result? Thanks for your help!  Comment By: Raymond Toy (rtoy) Date: 20120722 13:07 Message: Can you explain why you think the value you give is the correct value? Consider this transcript: (%i1) fpprec:30; (%o1) 30 (%i2) trace(bfloat); (%o2) [bfloat] (%i3) bfloat((45.12*34.78923)^2); 1 Enter bfloat [2463926.876928291] 1 Exit bfloat 2.46392687692829128354787826538b6 (%o3) 2.46392687692829128354787826538b6 Thus, the simplifier has simplified the float expression before bfloat gets a chance to look at it.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3547315&group_id=4933 
From: SourceForge.net <noreply@so...>  20120724 03:03:27

Bugs item #3542438, was opened at 20120710 23:37 Message generated for change (Comment added) made by rtoy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3542438&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: Aleksas (aleksasd) Assigned to: Nobody/Anonymous (nobody) Summary: wrong residue Initial Comment: Wrong: (%i1) residue(1/(x^8+1),x,exp(%i*%pi/8)); (%o1) 0 The correct result is: (%i2) exp((7*%i*%pi)/8)/8; (%o2) %e^((7*%i*%pi)/8)/8 (%i3) rectform(%); (%o3) cos((7*%pi)/8)/8(%i*sin((7*%pi)/8))/8 (%i4) float(%), numer; (%o4) 0.047835429045636*%i0.11548494156391 or (%i5) exp(%i*%pi/8)/8; (%o5) %e^((%i*%pi)/8)/8 (%i6) rectform(%); (%o6) (%i*sin(%pi/8))/8cos(%pi/8)/8 (%i7) float(%), numer; (%o7) 0.047835429045636*%i0.11548494156391 build_info("5.27.0","20120424 08:52:03","i686pcmingw32","GNU Common Lisp (GCL)","GCL 2.6.8") Aleksas D  >Comment By: Raymond Toy (rtoy) Date: 20120723 20:03 Message: I'm mistaken. The problem appears to be in taylor. taylor(1/(x^8+1),x,rectform(exp(%i*%pi/8)),1) appears to return an expression that does not have 1/(xrectform(exp(%i*%pi/8)) in it. But taylor(1/(x^8+1),x,exp(%i*%pi/8),1) does have 1/(xexp(%i*%pi/8)).  Comment By: Raymond Toy (rtoy) Date: 20120722 17:00 Message: This appears to be a bug in the function coeff, called from resm1 in src/residu.lisp. AFAICT, the taylor series returns the correct value, but coeff is unable to get the coefficient of 1/(xp). A workaround is the remove the call ($ratsimp ($rectform pole)). This fixes both this bug and bug 3541292, without causing a regression in bug 1504505. But coeff should really be fixed to return the correct value.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3542438&group_id=4933 
From: SourceForge.net <noreply@so...>  20120723 16:11:34

Bugs item #3547652, was opened at 20120723 08:48 Message generated for change (Comment added) made by rtoy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3547652&group_id=4933 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Lisp Core Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: https://www.google.com/accounts () Assigned to: Nobody/Anonymous (nobody) Summary: Differentiation of a function yields wrong answer Initial Comment: build_info("5.27.0","20120508 11:27:57","i686pcmingw32","GNU Common Lisp (GCL)","GCL 2.6.8") The differentiation gives erroneous answer kr2(x):=(sin(%pi*x/2)*sin(%pi*x/3))^2; kr2(x):=(sin((%pi*x)/2)*sin((%pi*x)/3))^2 diff(kr2(x),x,1); (2*%pi*cos((%pi*x)/3)*sin((%pi*x)/3)*sin((%pi*x)/2)^2)/3 + %pi*sin((%pi*x)/3)^2*cos((%pi*x)/2)*sin((%pi*x)/2) This is clearly wrong. The right answer is: (%pi*cos((%pi*x)/3)*sin((%pi*x)/3)*sin((%pi*x)/2)^2)/3 + (%pi*sin((%pi*x)/3)^2*cos((%pi*x)/2)*sin((%pi*x)/2))/2  >Comment By: Raymond Toy (rtoy) Date: 20120723 09:11 Message: Can you explain why you think maxima is wrong? From your example, kr2(x) = kr(x)^2 where kr(x) = sin(%pi*x/2)*sin(%pi*x/3). So diff(kr2(x),x) = 2*kr(x)*diff(kr(x),x) which gives maxima's answer, not yours. In fact, maxima's result is exactly 2 times your proposed correct answer.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3547652&group_id=4933 
From: SourceForge.net <noreply@so...>  20120723 16:04:54

Bugs item #3547315, was opened at 20120722 09:34 Message generated for change (Comment added) made by rtoy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3547315&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: christoph reineke (chrisrein) Assigned to: Nobody/Anonymous (nobody) Summary: Problems with bfloat Initial Comment: Enter: (%i2) fpprec:30; (%o2) 30 (%i3) bfloat((45.12*34.78923)^2); (%o3) 2.46392687692829128354787826538b6 2.46392687692829131776b6 is the correct value. build_info("5.27.0","20120508 11:27:57","i686pcmingw32","GNU Common Lisp (GCL)","GCL 2.6.8") Regards Chris  Comment By: Raymond Toy (rtoy) Date: 20120723 09:04 Message: When you write 45.12, maxima converts that to a floating point number. But 45.12 cannot be represented exactly in floating point. Same for 34.78923. (You can see what the actual value is by using rationalize(45.12), which is close t o 4512/100, but not the same.) So maxima uses floatingpoint arithmetic to compute (45.12*34.78923)^2. Then that floating point number is converted to a bfloat, giving the result that maxima produces. If you want exact results, use exact rational arithmetic: bfloat((4512/100 * 3478923/100000)^2); 2.46392687692829131776b6 Of course, even that is an approximation because the exact result is 240617859075028449/97656250000, and that can't be represented exactly as a bfloat.  Comment By: christoph reineke (chrisrein) Date: 20120723 02:12 Message: Sorry, but I don’t understand you. <Can you explain why you think the value you give is the correct value?> Which value? (45.12*34.78923)^2=2.46392687692829131776b6=the correct value. Since I expect that the correct value has more than 16 digits after the comma, I use bfloat and fpprec=30. I quote from the documentation: “bfloat (expr) Function Converts all numbers and functions of numbers in expr to bigfloat numbers. The number of significant digits in the resulting bigfloats is specified by the global variable fpprec.” …all numbers…!! Now Maxima returns 30 digits, but the result is wrong. That’s all. <Thus, the simplifier has simplified the float expression…> Which simplifier? If a CAS computes a simple multiplication each digit of the displayed floating point number should be correct (apart from the last), no matter how many digits the user wants. Even if I erroneously “simplify” something, Maxima should never display a wrong result. That’s my opinion. How do I get the correct result? Thanks for your help!  Comment By: Raymond Toy (rtoy) Date: 20120722 13:07 Message: Can you explain why you think the value you give is the correct value? Consider this transcript: (%i1) fpprec:30; (%o1) 30 (%i2) trace(bfloat); (%o2) [bfloat] (%i3) bfloat((45.12*34.78923)^2); 1 Enter bfloat [2463926.876928291] 1 Exit bfloat 2.46392687692829128354787826538b6 (%o3) 2.46392687692829128354787826538b6 Thus, the simplifier has simplified the float expression before bfloat gets a chance to look at it.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3547315&group_id=4933 
From: SourceForge.net <noreply@so...>  20120723 15:48:31

Bugs item #3547652, was opened at 20120723 08:48 Message generated for change (Tracker Item Submitted) made by You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3547652&group_id=4933 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Lisp Core Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: https://www.google.com/accounts () Assigned to: Nobody/Anonymous (nobody) Summary: Differentiation of a function yields wrong answer Initial Comment: build_info("5.27.0","20120508 11:27:57","i686pcmingw32","GNU Common Lisp (GCL)","GCL 2.6.8") The differentiation gives erroneous answer kr2(x):=(sin(%pi*x/2)*sin(%pi*x/3))^2; kr2(x):=(sin((%pi*x)/2)*sin((%pi*x)/3))^2 diff(kr2(x),x,1); (2*%pi*cos((%pi*x)/3)*sin((%pi*x)/3)*sin((%pi*x)/2)^2)/3 + %pi*sin((%pi*x)/3)^2*cos((%pi*x)/2)*sin((%pi*x)/2) This is clearly wrong. The right answer is: (%pi*cos((%pi*x)/3)*sin((%pi*x)/3)*sin((%pi*x)/2)^2)/3 + (%pi*sin((%pi*x)/3)^2*cos((%pi*x)/2)*sin((%pi*x)/2))/2  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3547652&group_id=4933 
From: SourceForge.net <noreply@so...>  20120723 09:12:07

Bugs item #3547315, was opened at 20120722 09:34 Message generated for change (Comment added) made by chrisrein You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3547315&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: christoph reineke (chrisrein) Assigned to: Nobody/Anonymous (nobody) Summary: Problems with bfloat Initial Comment: Enter: (%i2) fpprec:30; (%o2) 30 (%i3) bfloat((45.12*34.78923)^2); (%o3) 2.46392687692829128354787826538b6 2.46392687692829131776b6 is the correct value. build_info("5.27.0","20120508 11:27:57","i686pcmingw32","GNU Common Lisp (GCL)","GCL 2.6.8") Regards Chris  >Comment By: christoph reineke (chrisrein) Date: 20120723 02:12 Message: Sorry, but I don’t understand you. <Can you explain why you think the value you give is the correct value?> Which value? (45.12*34.78923)^2=2.46392687692829131776b6=the correct value. Since I expect that the correct value has more than 16 digits after the comma, I use bfloat and fpprec=30. I quote from the documentation: “bfloat (expr) Function Converts all numbers and functions of numbers in expr to bigfloat numbers. The number of significant digits in the resulting bigfloats is specified by the global variable fpprec.” …all numbers…!! Now Maxima returns 30 digits, but the result is wrong. That’s all. <Thus, the simplifier has simplified the float expression…> Which simplifier? If a CAS computes a simple multiplication each digit of the displayed floating point number should be correct (apart from the last), no matter how many digits the user wants. Even if I erroneously “simplify” something, Maxima should never display a wrong result. That’s my opinion. How do I get the correct result? Thanks for your help!  Comment By: Raymond Toy (rtoy) Date: 20120722 13:07 Message: Can you explain why you think the value you give is the correct value? Consider this transcript: (%i1) fpprec:30; (%o1) 30 (%i2) trace(bfloat); (%o2) [bfloat] (%i3) bfloat((45.12*34.78923)^2); 1 Enter bfloat [2463926.876928291] 1 Exit bfloat 2.46392687692829128354787826538b6 (%o3) 2.46392687692829128354787826538b6 Thus, the simplifier has simplified the float expression before bfloat gets a chance to look at it.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3547315&group_id=4933 
From: SourceForge.net <noreply@so...>  20120723 00:00:51

Bugs item #3542438, was opened at 20120710 23:37 Message generated for change (Comment added) made by rtoy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3542438&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: Aleksas (aleksasd) Assigned to: Nobody/Anonymous (nobody) Summary: wrong residue Initial Comment: Wrong: (%i1) residue(1/(x^8+1),x,exp(%i*%pi/8)); (%o1) 0 The correct result is: (%i2) exp((7*%i*%pi)/8)/8; (%o2) %e^((7*%i*%pi)/8)/8 (%i3) rectform(%); (%o3) cos((7*%pi)/8)/8(%i*sin((7*%pi)/8))/8 (%i4) float(%), numer; (%o4) 0.047835429045636*%i0.11548494156391 or (%i5) exp(%i*%pi/8)/8; (%o5) %e^((%i*%pi)/8)/8 (%i6) rectform(%); (%o6) (%i*sin(%pi/8))/8cos(%pi/8)/8 (%i7) float(%), numer; (%o7) 0.047835429045636*%i0.11548494156391 build_info("5.27.0","20120424 08:52:03","i686pcmingw32","GNU Common Lisp (GCL)","GCL 2.6.8") Aleksas D  >Comment By: Raymond Toy (rtoy) Date: 20120722 17:00 Message: This appears to be a bug in the function coeff, called from resm1 in src/residu.lisp. AFAICT, the taylor series returns the correct value, but coeff is unable to get the coefficient of 1/(xp). A workaround is the remove the call ($ratsimp ($rectform pole)). This fixes both this bug and bug 3541292, without causing a regression in bug 1504505. But coeff should really be fixed to return the correct value.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3542438&group_id=4933 
From: SourceForge.net <noreply@so...>  20120722 20:07:06

Bugs item #3547315, was opened at 20120722 09:34 Message generated for change (Comment added) made by rtoy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3547315&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: christoph reineke (chrisrein) Assigned to: Nobody/Anonymous (nobody) Summary: Problems with bfloat Initial Comment: Enter: (%i2) fpprec:30; (%o2) 30 (%i3) bfloat((45.12*34.78923)^2); (%o3) 2.46392687692829128354787826538b6 2.46392687692829131776b6 is the correct value. build_info("5.27.0","20120508 11:27:57","i686pcmingw32","GNU Common Lisp (GCL)","GCL 2.6.8") Regards Chris  >Comment By: Raymond Toy (rtoy) Date: 20120722 13:07 Message: Can you explain why you think the value you give is the correct value? Consider this transcript: (%i1) fpprec:30; (%o1) 30 (%i2) trace(bfloat); (%o2) [bfloat] (%i3) bfloat((45.12*34.78923)^2); 1 Enter bfloat [2463926.876928291] 1 Exit bfloat 2.46392687692829128354787826538b6 (%o3) 2.46392687692829128354787826538b6 Thus, the simplifier has simplified the float expression before bfloat gets a chance to look at it.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3547315&group_id=4933 
From: SourceForge.net <noreply@so...>  20120722 16:34:06

Bugs item #3547315, was opened at 20120722 09:34 Message generated for change (Tracker Item Submitted) made by chrisrein You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3547315&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: christoph reineke (chrisrein) Assigned to: Nobody/Anonymous (nobody) Summary: Problems with bfloat Initial Comment: Enter: (%i2) fpprec:30; (%o2) 30 (%i3) bfloat((45.12*34.78923)^2); (%o3) 2.46392687692829128354787826538b6 2.46392687692829131776b6 is the correct value. build_info("5.27.0","20120508 11:27:57","i686pcmingw32","GNU Common Lisp (GCL)","GCL 2.6.8") Regards Chris  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3547315&group_id=4933 
From: SourceForge.net <noreply@so...>  20120720 19:50:33

Bugs item #3546444, was opened at 20120720 12:50 Message generated for change (Tracker Item Submitted) made by willisbl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3546444&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: polarform of zero returns atan2 Initial Comment: (%i1) polarform(cos(x)^2 + sin(x)^21); (%o1) %e^(%i*atan2(0,sin(x)^2+cos(x)^21))*abs(sin(x)^2+cos(x)^21) (%i2) trigsimp(%); atan2: atan2(0,0) is undefined.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3546444&group_id=4933 
From: SourceForge.net <noreply@so...>  20120720 16:12:47

Bugs item #3546371, was opened at 20120720 09:12 Message generated for change (Tracker Item Submitted) made by rtoy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3546371&group_id=4933 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Lisp Core  Simplification Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Raymond Toy (rtoy) Assigned to: Nobody/Anonymous (nobody) Summary: cabs(expr) fails when expr is 0 Initial Comment: This came up on the mailing list discussion about rtest_trig failures on 20120719. The issue is that commit 5ea6ff3 fixed an issue with polarform but introduces a new issue when the expression is zero, as determined by $sign. Here is an example that causes it. It shows up with cmucl, but not other lisps. I assume with other lisps the expression doesn't evaluate to zero. (%i1) expr: 0.983425555216359*%i/(0.8391395790248311.171945144524351*%i) .8680141428959249*%i +0.834650094344116/(0.8391395790248311.171945144524351*%i)+.2176215618544027$ (%i2) trace(sign)$ (%i3) cabs(expr); 1 Enter ?sign [0.983425555216359*%i/(0.8391395790248311.171945144524351*%i) .8680141428959249*%i +0.834650094344116/(0.8391395790248311.171945144524351*%i) +.2176215618544027] 1 Exit ?sign zero (%o3) 0.983425555216359*%i/(0.8391395790248311.171945144524351*%i) .8680141428959249*%i +0.834650094344116/(0.8391395790248311.171945144524351*%i)+.2176215618544027 (%i4) rectform(expr); (%o4) 0.0  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3546371&group_id=4933 
From: SourceForge.net <noreply@so...>  20120718 18:49:09

Bugs item #3539699, was opened at 20120703 05:46 Message generated for change (Comment added) made by dgildea You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3539699&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: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Aleksas (aleksasd) >Assigned to: Dan Gildea (dgildea) Summary: limit of atan2 Initial Comment: Wrong limit of atan2 I calculate integrate(r,x,1,2), where (%i1) r:(x^43*x^2+6)/(x^65*x^4+5*x^2+4); (%o1) (x^43*x^2+6)/(x^65*x^4+5*x^2+4) see: W.Koepf, Computeralgebra, Eine algorithmisch orientierte Einfuehrung, 2006, page 472. (%i2) gfactor(r); (%o2) (x^43*x^2+6)/((x^3%i*x^23*x+2*%i)*(x^3+%i*x^23*x2*%i)) (%i3) integrate(%,x); (%o3) (%i*log(x^3+%i*x^23*x2*%i))/2(%i*log(x^3%i*x^23*x+2*%i))/2 (%i4) F:logcontract(rectform(%)); (%o4) atan2(x^22,x^33*x) (%i5) wxplot2d([F], [x,1,2])$ (%t5) << Graphics >> Wrong: (%i6) limit(F,x,sqrt(2),minus); rat: replaced 1.0E8 by 1/100000000 = 1.0E8 rat: replaced 1.0E8 by 1/100000000 = 1.0E8 (%o6) %pi Correct: (%i7) limit(F,x,sqrt(2),plus); rat: replaced 1.0E8 by 1/100000000 = 1.0E8 rat: replaced 1.0E8 by 1/100000000 = 1.0E8 (%o7) %pi (%i8) limit(F,x,sqrt(2)); (%o8) und The correct antiderivative: (%i9) F1:atan((x^33*x)/(x^22)); (%o9) atan((x^33*x)/(x^22)) (%i10) wxplot2d([F,F1], [x,1,2])$ (%t10) << Graphics >> (%i11) limit(F1,x,sqrt(2),plus); (%o11) %pi/2 (%i12) limit(F1,x,sqrt(2),minus); (%o12) %pi/2 (%i13) ev(F1,x=2)limit(F1,x,sqrt(2),plus)+limit(F1,x,sqrt(2),minus)ev(F1,x=1); (%o13) (5*%pi)/4atan(2) (%i14) float(%), numer; (%o14) 2.819842099193151 (%i15) quad_qags(r, x, 1, 2); (%o15) [2.819842099193151,1.5788976469667437*10^10,105,0] best Aleksas D  >Comment By: Dan Gildea (dgildea) Date: 20120718 11:49 Message: Fixed in limit.lisp: new routine simplim%atan2  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3539699&group_id=4933 
From: SourceForge.net <noreply@so...>  20120718 17:50:06

Bugs item #3545489, was opened at 20120718 10:50 Message generated for change (Tracker Item Submitted) made by tofol You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3545489&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: Installation Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Tobal (tofol) Assigned to: Nobody/Anonymous (nobody) Summary: Bug compiling maxima 5.27.0 with ecl Initial Comment: I'm trying compile maxima for Mandriva and i obtain during the compile it doesn't find maximapackage.fas file if i compile with ecl option. I need this option because Mandriva repos contains SageMath program. I adjoint the spec file  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3545489&group_id=4933 
From: SourceForge.net <noreply@so...>  20120716 11:18:47

Bugs item #3544572, was opened at 20120716 04:18 Message generated for change (Tracker Item Submitted) made by willisbl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3544572&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: 4 Private: No Submitted By: Barton Willis (willisbl) Assigned to: Nobody/Anonymous (nobody) Summary: user doc for part doesn't mention inflag Initial Comment: The user documentation for part doesn't say that the value of inflag modifies the behavior of part: (%i1) part(x/2,0), inflag : true; (%o1) "*" (%i2) part(x/2,0), inflag : false; (%o2) "/"  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3544572&group_id=4933 
From: SourceForge.net <noreply@so...>  20120716 04:16:26

Bugs item #3544336, was opened at 20120715 04:05 Message generated for change (Comment added) made by macrakis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3544336&group_id=4933 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Lisp Core  Trigonometry Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: https://www.google.com/accounts () Assigned to: Nobody/Anonymous (nobody) Summary: Trigonometric Simplification to SINE function Initial Comment: Hi This is a wish list of easy changes in Trigonometric Simplification to SINE function but they could be extended to other functions as well. 1) The trigonometric simplification should be aware that SIN(3*%PI/7)=SIN(4*%PI/7) or in general SIN(%PI* a/c)=SIN(%PI *b/c) where a+b=c. (a,b,c > 0) 2) The trigonometric simplification should simplify SIN(%PI*494/7) to SIN(%PI*(70+4))=SIN(%PI*4/7)  >Comment By: Stavros Macrakis (macrakis) Date: 20120715 21:16 Message: Thanks for the suggestions  both helpful. As a workaround until this is improved, note that trigrat( sin(4*%pi/7)  sin(3*%pi/7) ) => 0 and trigrat( sin(494*%pi/7)  sin(4*%pi/7) ) => 0  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3544336&group_id=4933 
From: SourceForge.net <noreply@so...>  20120716 04:12:21

Bugs item #3544492, was opened at 20120715 21:12 Message generated for change (Tracker Item Submitted) made by macrakis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3544492&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  Polynomials Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: horner of multivariate taylor gives junk Initial Comment: horner(taylor(x,[x,a],0,1), x) gives a result with gensyms in it. Lisp: ((MTIMES SIMP) $X #:G34765) Maxima: x g34765 Workaround: ratdisrep the argument.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3544492&group_id=4933 
From: SourceForge.net <noreply@so...>  20120715 11:05:53

Bugs item #3544336, was opened at 20120715 04:05 Message generated for change (Tracker Item Submitted) made by You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3544336&group_id=4933 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Lisp Core  Trigonometry Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: https://www.google.com/accounts () Assigned to: Nobody/Anonymous (nobody) Summary: Trigonometric Simplification to SINE function Initial Comment: Hi This is a wish list of easy changes in Trigonometric Simplification to SINE function but they could be extended to other functions as well. 1) The trigonometric simplification should be aware that SIN(3*%PI/7)=SIN(4*%PI/7) or in general SIN(%PI* a/c)=SIN(%PI *b/c) where a+b=c. (a,b,c > 0) 2) The trigonometric simplification should simplify SIN(%PI*494/7) to SIN(%PI*(70+4))=SIN(%PI*4/7)  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3544336&group_id=4933 