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

_{Sep}

_{Oct}

_{Nov}

_{Dec}

S  M  T  W  T  F  S 







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

10
(5) 
11
(3) 
12

13

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

22
(7) 
23
(1) 
24
(1) 
25
(1) 
26
(2) 
27

28
(1) 
29

30
(1) 






From: SourceForge.net <noreply@so...>  20070908 18:56:14

Bugs item #1786774, was opened at 20070902 17:09 Message generated for change (Comment added) made by dgildea You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1786774&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: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: tlimit((5^x + 3^x)^(1/x), x, inf) => Error Initial Comment: tlimit((5^x + 3^x)^(1/x), x, inf) => Maxima encountered a Lisp error: two equal vars generated limit calculates this one fine: tlimswitch : false; limit((5^x + 3^x)^(1/x),x, inf); => 5  >Comment By: Dan Gildea (dgildea) Date: 20070908 14:56 Message: Logged In: YES user_id=1797506 Originator: NO fixed in hayat.lisp rev 1.27 (%i14) tlimit((5^x + 3^x)^(1/x), x, inf); (%o14) 5  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1786774&group_id=4933 
From: SourceForge.net <noreply@so...>  20070908 18:53:37

Bugs item #1037916, was opened at 20040930 13:44 Message generated for change (Comment added) made by dgildea You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1037916&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: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: taylor 2^n/(7^n+1) n>inf internal error Initial Comment: taylor(2^n/(7^n+1),n,inf,3) => Maxima encountered a Lisp error: two equal vars generated 5.9.0.9beta2 Maxima build date: 10:50 7/27/2004 host type: i686pcmingw32 lispimplementationtype: Kyoto Common Lisp lispimplementationversion: GCL 2.6.3  >Comment By: Dan Gildea (dgildea) Date: 20070908 14:53 Message: Logged In: YES user_id=1797506 Originator: NO fixed in hayat.lisp rev 1.27 (%i13) taylor(2^n/(7^n+1),n,inf,3) ; (%o13) +(%e^(log(7)*n)(%e^(log(7)*n))^2+(%e^(log(7)*n))^3)/%e^(log(2)*n)  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1037916&group_id=4933 
From: SourceForge.net <noreply@so...>  20070908 18:50:09

Bugs item #1603900, was opened at 20061127 12:09 Message generated for change (Comment added) made by dgildea You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1603900&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: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: taylor/tlimit (4^n+1)/2^(2*n) internal error Initial Comment: tlimit((4^n+1)/2^(2*n),n,inf); Maxima encountered a Lisp error (bad arglist to error function): Undefined limit product Error in CONDITIONS:BREAK [or a callee]: Format error: arguments exhausted. V "Undefined limit product ~A * ~A in limtimes lim1 lim2" Fast links are on: do (usefastlinks nil) for debugging Broken at PCL::PRINTSTDINSTANCE. 5.10.0 GCL 2.6.8 Windows  >Comment By: Dan Gildea (dgildea) Date: 20070908 14:50 Message: Logged In: YES user_id=1797506 Originator: NO fixed in hayat.lisp rev 1.27 (%i12) tlimit((4^n+1)/2^(2*n),n,inf); (%o12) 1  Comment By: Raymond Toy (rtoy) Date: 20061129 12:50 Message: Logged In: YES user_id=28849 Originator: NO Not sure what to do about this. Fixig the immediate problem with missing args to the break function just causes more break functions to get called. I tried to continue from these breaks, but I got tired of doing that before I found it where it would lead.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1603900&group_id=4933 
From: SourceForge.net <noreply@so...>  20070908 18:47:16

Bugs item #614203, was opened at 20020925 01:08 Message generated for change (Comment added) made by dgildea You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=614203&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: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: Taylor gives undefined limit error Initial Comment: test: (1x^a)/(1+x^a); taylor(test,a,inf,2); asks sign of x1 If you answer pos, it works fine. If you answer zero, it gives "Break: Undefined limit product" and then "Error: Format error: arguments exhausted" (presumably there's some error in the error reporting...). The result should be zero. If you answer neg, it gives "Invalid call to varexpand". I am not sure what the correct result is, but it shouldn't cause an internal error.  >Comment By: Dan Gildea (dgildea) Date: 20070908 14:47 Message: Logged In: YES user_id=1797506 Originator: NO fixed in hayat.lisp rev 1.27 (%i9) test: (1x^a)/(1+x^a); (%o9) (1x^a)/(x^a+1) (%i10) taylor(test,a,inf,2); Is x1 positive, negative, or zero? zero; (%o10) 12*%e^(a*log(x))+2*(%e^(a*log(x)))^2 (%i11) taylor(sin(x)^a,a,inf,2); Is sin(x)1 positive, negative, or zero? zero; (%o11) +%e^(a*log(sin(x)))  Comment By: Martin Rubey (kratt5) Date: 20030713 12:44 Message: Logged In: YES user_id=651552 The formatting issue is reported in [ 663873 ] taylor / fixes The error remains, unfortunately... Martin  Comment By: Stavros Macrakis (macrakis) Date: 20030711 18:54 Message: Logged In: YES user_id=588346 A simpler case. In this case too, the answer is trivial: since sin(x)1 == 0 , then sin(x)==1 and sin(x)^a == 1 for all a.... taylor(sin(x)^a,a,inf,2); Is SIN(x)  1 positive, negative, or zero? zero; Break: Undefined limit product Error: Format error: arguments exhausted. V "Undefined limit product ~A * ~A in limtimes lim1 lim2" Does the same for f(x) instead of sin(x). The problem appears to be that it doesn't realize that the $zero here is a *constant* zero whereas the $INF is a limiting infinity only. Constant zero * limiting infinity = zero, though of course lmiiting zero * limiting infinity is undefined.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=614203&group_id=4933 
From: SourceForge.net <noreply@so...>  20070908 18:36:10

Bugs item #1787111, was opened at 20070903 10:04 Message generated for change (Comment added) made by rtoy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1787111&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: Problem not in Maxima Group: None Status: Pending Resolution: Wont Fix Priority: 5 Private: No Submitted By: Abel Pascual (abelpascual) Assigned to: Nobody/Anonymous (nobody) Summary: Floating point imprecission Initial Comment: I don't understand why Maxima rounds down the number... I'm currently running Ubuntu 7.04. Maxima 5.13.0 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. This is a development version of Maxima. The function bug_report() provides bug reporting information. (%i1) 4.6*10^8; (%o1) 4.5999999999999994E+8  >Comment By: Raymond Toy (rtoy) Date: 20070908 14:36 Message: Logged In: YES user_id=28849 Originator: NO There is one thing we could do: If fpprintprec is 0, we want to print everything, so in that case ,we might use ~a. If fpprintprec is something else, we use ~e. This will probablly fix the immediate issue. I assume most people leave fpprintprec defaulted.  Comment By: Robert Dodier (robert_dodier) Date: 20070907 20:32 Message: Logged In: YES user_id=501686 Originator: NO Reported the bug (format nil "~ve" 21 46d7) => 4.5999999999999996d+8 as SF bug report # 1790496 for Clisp. http://sourceforge.net/tracker/index.php?func=detail&aid=1790496&group_id=1355&atid=101355 I think we can close this Maxima bug report now since both of problems observed are problems in Lisp implementations. Marking this report as "won't fix" and "pending" (to be closed automatically in 2 weeks) accordingly.  Comment By: Robert Dodier (robert_dodier) Date: 20070907 10:51 Message: Logged In: YES user_id=501686 Originator: NO Ray, I think you are correct on both counts: changing e to a or d shouldn't help, the format indicator should remain e; and the Clisp output in this case (format nil "~ve" 21 46d7) indicates a bug in Clisp. You or I can report the Clisp bug, whoever gets to it first, and then we can close this report, I think.  Comment By: Raymond Toy (rtoy) Date: 20070906 23:22 Message: Logged In: YES user_id=28849 Originator: NO I'm mistaken. Using ~a won't work (which implies ~d won't work either). Consider if fpprintprec is 2. Then (format t "~7a" 1.2345678d9) > 1.2345678d9 But (format t "~7e" 1.2345678d9) > 1.23d8 We need to do something else.  Comment By: Raymond Toy (rtoy) Date: 20070906 22:56 Message: Logged In: YES user_id=28849 Originator: NO We should probably file a bug report for clisp for item 2. Changing ~e to ~d is ok, but ~d is really ~a, so we should just use ~a. There is a difference, however. ~e pads numbers on the left and ~a pads on the right.t. DDoDont' know if that matters or not. In addition, cmucl has a known bug that ~e prints numbers differently from ~a (princ). ~a is more accurate.  Comment By: Robert Dodier (robert_dodier) Date: 20070906 22:06 Message: Logged In: YES user_id=501686 Originator: NO (1) I've reported GCL's failure to parse 4.6e8 correctly to the GCL bug tracker as # 20992. https://savannah.gnu.org/bugs/index.php?20992 So as for this 4.6e8 in Maxima + GCL, we can close it because the problem is not in Maxima. (2) About Clisp printing 46e7 as 4.5999999999999996E+8, it appears that Clisp is interpreting "~ve" to indicate a coercion to singlefloat before formatting it. Changing the "~ve" to "~vd" in EXPLODEN in src/commac.lisp appears to tell Clisp to format 46e7 as 4.6E8. SBCL and GCL are happy with "~vd". Leaving this report open to gather comments on item (2). If nobody is opposed, I'll modify EXPLODEN as described above.  Comment By: Raymond Toy (rtoy) Date: 20070905 10:20 Message: Logged In: YES user_id=28849 Originator: NO Good question. I wasn't sure, so I checked the code. Look at makenumber and readlist in nparse.lisp. If the number is not a bigfloat, readlist is called, which basically calls Lisp readfromstring to read "4.6e8". So the result depends on the underlying Lisp. All Lisps should say (floor 4.6d8) is 46000000 and 0.0d0. Clisp and cmucl do. gcl does not. We could implement our own reader. However, for a bigfloat, maxima sees 4.6, converts it to 46/10 and then multiplies by 10^8 to get a rational number. This is then converted to a bigfloat. I think 21 is because we want upto 16 digits printed, and the 5 is to make sure there's space to print the exponent marker, a sign, and the exponent itself (3 digits). If 16 is used, the number of significant digits would be too small. I think it is a bug in gcl and clisp that it prints something other than 4.6d8.  Comment By: Andrej Vodopivec (andrejv) Date: 20070905 03:27 Message: Logged In: YES user_id=1179910 Originator: NO I don't think 4.6*10^8 is parsed as one number. First 4.6 is parsed, then 10^8, and then they are multiplied. To enter 4.6e8 you should enter it as 4.6e8. OTOH, 4.6e8 is not printed correctly on clisp and gcl. The reason is that floats are printed with (format nil "~ve" 21 4.6e8) I think 21 is arbitrarily chosen  if it was 19, all lisps print it correctly, but then maybe some other example would be printed incorrectly. Why don't we just use (format nil "~ve" 16 4.6e8). Andrej  Comment By: Raymond Toy (rtoy) Date: 20070904 14:47 Message: Logged In: YES user_id=28849 Originator: NO The issues you see with GCL and CLISP are somewhat related, but outside the scope of this bug. If you want to discuss it further, I'd be happy to. Just not here. Please mail me directly or, even better, use the maxima mailing list.  Comment By: Abel Pascual (abelpascual) Date: 20070904 13:50 Message: Logged In: YES user_id=1881850 Originator: YES I don't know if there is any relation, but in GCL I'm having the same issue: >(* 4.6 (expt 10 8)) 4.5999999999999994E8 But otherwise in CLISP this is not happening: [1]> (* 4.6 (expt 10 8)) 4.6E8  Comment By: Raymond Toy (rtoy) Date: 20070904 13:11 Message: Logged In: YES user_id=28849 Originator: NO Actually 4.6e8 is an integer: 460000000. This should be exactly representable as a doublefloat. I think it is an error that maxima prints something else out. Reopening this bug.  Comment By: Abel Pascual (abelpascual) Date: 20070903 17:37 Message: Logged In: YES user_id=1881850 Originator: YES Ok, sorry for my mistake, and thanks for your explanation...  Comment By: Harald Geyer (hgeyer) Date: 20070903 16:12 Message: Logged In: YES user_id=929336 Originator: NO Hi Abel! Thanks for you interest in maxima. The behaviour, that you see is a basic property of fixed precision floating point numbers (maxima acutally is using maschine doubles IIRC): The number 4.6e8 is not representable exactly in base 2 arithmetic, thus maxima rounds the number to the next number that can be represented as double float. If you need higher precision, you can use bfloats: 4.6b8 If you want exact numbers, you can use rational arithmetic. In this case enter the number as: 46*10^7 (that is: without decimal dot) If you still have questions, you might ask on the Mailinglist. I'm closing your bug report now, because this is nothing we can fix in maxima.  Comment By: Abel Pascual (abelpascual) Date: 20070903 10:06 Message: Logged In: YES user_id=1881850 Originator: YES Greetings  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1787111&group_id=4933 
From: SourceForge.net <noreply@so...>  20070908 02:45:33

Bugs item #1790530, was opened at 20070907 19:45 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=1790530&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: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: solve() problem Initial Comment: Trying to solve two polynomial equations in two unknowns fails, but when I add a third trivial equation with a third unknown it works. Maxima 5.13.0 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. This is a development version of Maxima. The function bug_report() provides bug reporting information. (%i1) solve([x^2+x+1=0,x^2*y+1=0]); (%o1) [] (%i2) solve([x^2+x+1=0,x^2*y+1=0,z=0]); sqrt(3) %i + 1 sqrt(3) %i + 1 (%o2) [[z = 0, y = , x =  ], 2 2 sqrt(3) %i  1 sqrt(3) %i  1 [z = 0, y =  , x = ]] 2 2 (%i3) bug_report(); The Maxima bug database is available at http://sourceforge.net/tracker/?atid=104933&group_id=4933&func=browse Submit bug reports by following the 'Submit New' link on that page. Please include the following build information with your bug report:  Maxima version: 5.13.0 Maxima build date: 14:20 8/31/2007 host type: i686pclinuxgnu lispimplementationtype: GNU Common Lisp (GCL) lispimplementationversion: GCL 2.6.7  The above information is also available from the Maxima function build_info().  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1790530&group_id=4933 
From: SourceForge.net <noreply@so...>  20070908 00:32:58

Bugs item #1787111, was opened at 20070903 08:04 Message generated for change (Comment added) made by robert_dodier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1787111&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: Problem not in Maxima Group: None >Status: Pending >Resolution: Wont Fix Priority: 5 Private: No Submitted By: Abel Pascual (abelpascual) Assigned to: Nobody/Anonymous (nobody) Summary: Floating point imprecission Initial Comment: I don't understand why Maxima rounds down the number... I'm currently running Ubuntu 7.04. Maxima 5.13.0 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. This is a development version of Maxima. The function bug_report() provides bug reporting information. (%i1) 4.6*10^8; (%o1) 4.5999999999999994E+8  >Comment By: Robert Dodier (robert_dodier) Date: 20070907 18:32 Message: Logged In: YES user_id=501686 Originator: NO Reported the bug (format nil "~ve" 21 46d7) => 4.5999999999999996d+8 as SF bug report # 1790496 for Clisp. http://sourceforge.net/tracker/index.php?func=detail&aid=1790496&group_id=1355&atid=101355 I think we can close this Maxima bug report now since both of problems observed are problems in Lisp implementations. Marking this report as "won't fix" and "pending" (to be closed automatically in 2 weeks) accordingly.  Comment By: Robert Dodier (robert_dodier) Date: 20070907 08:51 Message: Logged In: YES user_id=501686 Originator: NO Ray, I think you are correct on both counts: changing e to a or d shouldn't help, the format indicator should remain e; and the Clisp output in this case (format nil "~ve" 21 46d7) indicates a bug in Clisp. You or I can report the Clisp bug, whoever gets to it first, and then we can close this report, I think.  Comment By: Raymond Toy (rtoy) Date: 20070906 21:22 Message: Logged In: YES user_id=28849 Originator: NO I'm mistaken. Using ~a won't work (which implies ~d won't work either). Consider if fpprintprec is 2. Then (format t "~7a" 1.2345678d9) > 1.2345678d9 But (format t "~7e" 1.2345678d9) > 1.23d8 We need to do something else.  Comment By: Raymond Toy (rtoy) Date: 20070906 20:56 Message: Logged In: YES user_id=28849 Originator: NO We should probably file a bug report for clisp for item 2. Changing ~e to ~d is ok, but ~d is really ~a, so we should just use ~a. There is a difference, however. ~e pads numbers on the left and ~a pads on the right.t. DDoDont' know if that matters or not. In addition, cmucl has a known bug that ~e prints numbers differently from ~a (princ). ~a is more accurate.  Comment By: Robert Dodier (robert_dodier) Date: 20070906 20:06 Message: Logged In: YES user_id=501686 Originator: NO (1) I've reported GCL's failure to parse 4.6e8 correctly to the GCL bug tracker as # 20992. https://savannah.gnu.org/bugs/index.php?20992 So as for this 4.6e8 in Maxima + GCL, we can close it because the problem is not in Maxima. (2) About Clisp printing 46e7 as 4.5999999999999996E+8, it appears that Clisp is interpreting "~ve" to indicate a coercion to singlefloat before formatting it. Changing the "~ve" to "~vd" in EXPLODEN in src/commac.lisp appears to tell Clisp to format 46e7 as 4.6E8. SBCL and GCL are happy with "~vd". Leaving this report open to gather comments on item (2). If nobody is opposed, I'll modify EXPLODEN as described above.  Comment By: Raymond Toy (rtoy) Date: 20070905 08:20 Message: Logged In: YES user_id=28849 Originator: NO Good question. I wasn't sure, so I checked the code. Look at makenumber and readlist in nparse.lisp. If the number is not a bigfloat, readlist is called, which basically calls Lisp readfromstring to read "4.6e8". So the result depends on the underlying Lisp. All Lisps should say (floor 4.6d8) is 46000000 and 0.0d0. Clisp and cmucl do. gcl does not. We could implement our own reader. However, for a bigfloat, maxima sees 4.6, converts it to 46/10 and then multiplies by 10^8 to get a rational number. This is then converted to a bigfloat. I think 21 is because we want upto 16 digits printed, and the 5 is to make sure there's space to print the exponent marker, a sign, and the exponent itself (3 digits). If 16 is used, the number of significant digits would be too small. I think it is a bug in gcl and clisp that it prints something other than 4.6d8.  Comment By: Andrej Vodopivec (andrejv) Date: 20070905 01:27 Message: Logged In: YES user_id=1179910 Originator: NO I don't think 4.6*10^8 is parsed as one number. First 4.6 is parsed, then 10^8, and then they are multiplied. To enter 4.6e8 you should enter it as 4.6e8. OTOH, 4.6e8 is not printed correctly on clisp and gcl. The reason is that floats are printed with (format nil "~ve" 21 4.6e8) I think 21 is arbitrarily chosen  if it was 19, all lisps print it correctly, but then maybe some other example would be printed incorrectly. Why don't we just use (format nil "~ve" 16 4.6e8). Andrej  Comment By: Raymond Toy (rtoy) Date: 20070904 12:47 Message: Logged In: YES user_id=28849 Originator: NO The issues you see with GCL and CLISP are somewhat related, but outside the scope of this bug. If you want to discuss it further, I'd be happy to. Just not here. Please mail me directly or, even better, use the maxima mailing list.  Comment By: Abel Pascual (abelpascual) Date: 20070904 11:50 Message: Logged In: YES user_id=1881850 Originator: YES I don't know if there is any relation, but in GCL I'm having the same issue: >(* 4.6 (expt 10 8)) 4.5999999999999994E8 But otherwise in CLISP this is not happening: [1]> (* 4.6 (expt 10 8)) 4.6E8  Comment By: Raymond Toy (rtoy) Date: 20070904 11:11 Message: Logged In: YES user_id=28849 Originator: NO Actually 4.6e8 is an integer: 460000000. This should be exactly representable as a doublefloat. I think it is an error that maxima prints something else out. Reopening this bug.  Comment By: Abel Pascual (abelpascual) Date: 20070903 15:37 Message: Logged In: YES user_id=1881850 Originator: YES Ok, sorry for my mistake, and thanks for your explanation...  Comment By: Harald Geyer (hgeyer) Date: 20070903 14:12 Message: Logged In: YES user_id=929336 Originator: NO Hi Abel! Thanks for you interest in maxima. The behaviour, that you see is a basic property of fixed precision floating point numbers (maxima acutally is using maschine doubles IIRC): The number 4.6e8 is not representable exactly in base 2 arithmetic, thus maxima rounds the number to the next number that can be represented as double float. If you need higher precision, you can use bfloats: 4.6b8 If you want exact numbers, you can use rational arithmetic. In this case enter the number as: 46*10^7 (that is: without decimal dot) If you still have questions, you might ask on the Mailinglist. I'm closing your bug report now, because this is nothing we can fix in maxima.  Comment By: Abel Pascual (abelpascual) Date: 20070903 08:06 Message: Logged In: YES user_id=1881850 Originator: YES Greetings  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1787111&group_id=4933 
From: SourceForge.net <noreply@so...>  20070907 14:51:34

Bugs item #1787111, was opened at 20070903 08:04 Message generated for change (Comment added) made by robert_dodier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1787111&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: Abel Pascual (abelpascual) Assigned to: Nobody/Anonymous (nobody) Summary: Floating point imprecission Initial Comment: I don't understand why Maxima rounds down the number... I'm currently running Ubuntu 7.04. Maxima 5.13.0 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. This is a development version of Maxima. The function bug_report() provides bug reporting information. (%i1) 4.6*10^8; (%o1) 4.5999999999999994E+8  >Comment By: Robert Dodier (robert_dodier) Date: 20070907 08:51 Message: Logged In: YES user_id=501686 Originator: NO Ray, I think you are correct on both counts: changing e to a or d shouldn't help, the format indicator should remain e; and the Clisp output in this case (format nil "~ve" 21 46d7) indicates a bug in Clisp. You or I can report the Clisp bug, whoever gets to it first, and then we can close this report, I think.  Comment By: Raymond Toy (rtoy) Date: 20070906 21:22 Message: Logged In: YES user_id=28849 Originator: NO I'm mistaken. Using ~a won't work (which implies ~d won't work either). Consider if fpprintprec is 2. Then (format t "~7a" 1.2345678d9) > 1.2345678d9 But (format t "~7e" 1.2345678d9) > 1.23d8 We need to do something else.  Comment By: Raymond Toy (rtoy) Date: 20070906 20:56 Message: Logged In: YES user_id=28849 Originator: NO We should probably file a bug report for clisp for item 2. Changing ~e to ~d is ok, but ~d is really ~a, so we should just use ~a. There is a difference, however. ~e pads numbers on the left and ~a pads on the right.t. DDoDont' know if that matters or not. In addition, cmucl has a known bug that ~e prints numbers differently from ~a (princ). ~a is more accurate.  Comment By: Robert Dodier (robert_dodier) Date: 20070906 20:06 Message: Logged In: YES user_id=501686 Originator: NO (1) I've reported GCL's failure to parse 4.6e8 correctly to the GCL bug tracker as # 20992. https://savannah.gnu.org/bugs/index.php?20992 So as for this 4.6e8 in Maxima + GCL, we can close it because the problem is not in Maxima. (2) About Clisp printing 46e7 as 4.5999999999999996E+8, it appears that Clisp is interpreting "~ve" to indicate a coercion to singlefloat before formatting it. Changing the "~ve" to "~vd" in EXPLODEN in src/commac.lisp appears to tell Clisp to format 46e7 as 4.6E8. SBCL and GCL are happy with "~vd". Leaving this report open to gather comments on item (2). If nobody is opposed, I'll modify EXPLODEN as described above.  Comment By: Raymond Toy (rtoy) Date: 20070905 08:20 Message: Logged In: YES user_id=28849 Originator: NO Good question. I wasn't sure, so I checked the code. Look at makenumber and readlist in nparse.lisp. If the number is not a bigfloat, readlist is called, which basically calls Lisp readfromstring to read "4.6e8". So the result depends on the underlying Lisp. All Lisps should say (floor 4.6d8) is 46000000 and 0.0d0. Clisp and cmucl do. gcl does not. We could implement our own reader. However, for a bigfloat, maxima sees 4.6, converts it to 46/10 and then multiplies by 10^8 to get a rational number. This is then converted to a bigfloat. I think 21 is because we want upto 16 digits printed, and the 5 is to make sure there's space to print the exponent marker, a sign, and the exponent itself (3 digits). If 16 is used, the number of significant digits would be too small. I think it is a bug in gcl and clisp that it prints something other than 4.6d8.  Comment By: Andrej Vodopivec (andrejv) Date: 20070905 01:27 Message: Logged In: YES user_id=1179910 Originator: NO I don't think 4.6*10^8 is parsed as one number. First 4.6 is parsed, then 10^8, and then they are multiplied. To enter 4.6e8 you should enter it as 4.6e8. OTOH, 4.6e8 is not printed correctly on clisp and gcl. The reason is that floats are printed with (format nil "~ve" 21 4.6e8) I think 21 is arbitrarily chosen  if it was 19, all lisps print it correctly, but then maybe some other example would be printed incorrectly. Why don't we just use (format nil "~ve" 16 4.6e8). Andrej  Comment By: Raymond Toy (rtoy) Date: 20070904 12:47 Message: Logged In: YES user_id=28849 Originator: NO The issues you see with GCL and CLISP are somewhat related, but outside the scope of this bug. If you want to discuss it further, I'd be happy to. Just not here. Please mail me directly or, even better, use the maxima mailing list.  Comment By: Abel Pascual (abelpascual) Date: 20070904 11:50 Message: Logged In: YES user_id=1881850 Originator: YES I don't know if there is any relation, but in GCL I'm having the same issue: >(* 4.6 (expt 10 8)) 4.5999999999999994E8 But otherwise in CLISP this is not happening: [1]> (* 4.6 (expt 10 8)) 4.6E8  Comment By: Raymond Toy (rtoy) Date: 20070904 11:11 Message: Logged In: YES user_id=28849 Originator: NO Actually 4.6e8 is an integer: 460000000. This should be exactly representable as a doublefloat. I think it is an error that maxima prints something else out. Reopening this bug.  Comment By: Abel Pascual (abelpascual) Date: 20070903 15:37 Message: Logged In: YES user_id=1881850 Originator: YES Ok, sorry for my mistake, and thanks for your explanation...  Comment By: Harald Geyer (hgeyer) Date: 20070903 14:12 Message: Logged In: YES user_id=929336 Originator: NO Hi Abel! Thanks for you interest in maxima. The behaviour, that you see is a basic property of fixed precision floating point numbers (maxima acutally is using maschine doubles IIRC): The number 4.6e8 is not representable exactly in base 2 arithmetic, thus maxima rounds the number to the next number that can be represented as double float. If you need higher precision, you can use bfloats: 4.6b8 If you want exact numbers, you can use rational arithmetic. In this case enter the number as: 46*10^7 (that is: without decimal dot) If you still have questions, you might ask on the Mailinglist. I'm closing your bug report now, because this is nothing we can fix in maxima.  Comment By: Abel Pascual (abelpascual) Date: 20070903 08:06 Message: Logged In: YES user_id=1881850 Originator: YES Greetings  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1787111&group_id=4933 
From: SourceForge.net <noreply@so...>  20070907 03:22:32

Bugs item #1787111, was opened at 20070903 10:04 Message generated for change (Comment added) made by rtoy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1787111&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: Abel Pascual (abelpascual) Assigned to: Nobody/Anonymous (nobody) Summary: Floating point imprecission Initial Comment: I don't understand why Maxima rounds down the number... I'm currently running Ubuntu 7.04. Maxima 5.13.0 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. This is a development version of Maxima. The function bug_report() provides bug reporting information. (%i1) 4.6*10^8; (%o1) 4.5999999999999994E+8  >Comment By: Raymond Toy (rtoy) Date: 20070906 23:22 Message: Logged In: YES user_id=28849 Originator: NO I'm mistaken. Using ~a won't work (which implies ~d won't work either). Consider if fpprintprec is 2. Then (format t "~7a" 1.2345678d9) > 1.2345678d9 But (format t "~7e" 1.2345678d9) > 1.23d8 We need to do something else.  Comment By: Raymond Toy (rtoy) Date: 20070906 22:56 Message: Logged In: YES user_id=28849 Originator: NO We should probably file a bug report for clisp for item 2. Changing ~e to ~d is ok, but ~d is really ~a, so we should just use ~a. There is a difference, however. ~e pads numbers on the left and ~a pads on the right.t. DDoDont' know if that matters or not. In addition, cmucl has a known bug that ~e prints numbers differently from ~a (princ). ~a is more accurate.  Comment By: Robert Dodier (robert_dodier) Date: 20070906 22:06 Message: Logged In: YES user_id=501686 Originator: NO (1) I've reported GCL's failure to parse 4.6e8 correctly to the GCL bug tracker as # 20992. https://savannah.gnu.org/bugs/index.php?20992 So as for this 4.6e8 in Maxima + GCL, we can close it because the problem is not in Maxima. (2) About Clisp printing 46e7 as 4.5999999999999996E+8, it appears that Clisp is interpreting "~ve" to indicate a coercion to singlefloat before formatting it. Changing the "~ve" to "~vd" in EXPLODEN in src/commac.lisp appears to tell Clisp to format 46e7 as 4.6E8. SBCL and GCL are happy with "~vd". Leaving this report open to gather comments on item (2). If nobody is opposed, I'll modify EXPLODEN as described above.  Comment By: Raymond Toy (rtoy) Date: 20070905 10:20 Message: Logged In: YES user_id=28849 Originator: NO Good question. I wasn't sure, so I checked the code. Look at makenumber and readlist in nparse.lisp. If the number is not a bigfloat, readlist is called, which basically calls Lisp readfromstring to read "4.6e8". So the result depends on the underlying Lisp. All Lisps should say (floor 4.6d8) is 46000000 and 0.0d0. Clisp and cmucl do. gcl does not. We could implement our own reader. However, for a bigfloat, maxima sees 4.6, converts it to 46/10 and then multiplies by 10^8 to get a rational number. This is then converted to a bigfloat. I think 21 is because we want upto 16 digits printed, and the 5 is to make sure there's space to print the exponent marker, a sign, and the exponent itself (3 digits). If 16 is used, the number of significant digits would be too small. I think it is a bug in gcl and clisp that it prints something other than 4.6d8.  Comment By: Andrej Vodopivec (andrejv) Date: 20070905 03:27 Message: Logged In: YES user_id=1179910 Originator: NO I don't think 4.6*10^8 is parsed as one number. First 4.6 is parsed, then 10^8, and then they are multiplied. To enter 4.6e8 you should enter it as 4.6e8. OTOH, 4.6e8 is not printed correctly on clisp and gcl. The reason is that floats are printed with (format nil "~ve" 21 4.6e8) I think 21 is arbitrarily chosen  if it was 19, all lisps print it correctly, but then maybe some other example would be printed incorrectly. Why don't we just use (format nil "~ve" 16 4.6e8). Andrej  Comment By: Raymond Toy (rtoy) Date: 20070904 14:47 Message: Logged In: YES user_id=28849 Originator: NO The issues you see with GCL and CLISP are somewhat related, but outside the scope of this bug. If you want to discuss it further, I'd be happy to. Just not here. Please mail me directly or, even better, use the maxima mailing list.  Comment By: Abel Pascual (abelpascual) Date: 20070904 13:50 Message: Logged In: YES user_id=1881850 Originator: YES I don't know if there is any relation, but in GCL I'm having the same issue: >(* 4.6 (expt 10 8)) 4.5999999999999994E8 But otherwise in CLISP this is not happening: [1]> (* 4.6 (expt 10 8)) 4.6E8  Comment By: Raymond Toy (rtoy) Date: 20070904 13:11 Message: Logged In: YES user_id=28849 Originator: NO Actually 4.6e8 is an integer: 460000000. This should be exactly representable as a doublefloat. I think it is an error that maxima prints something else out. Reopening this bug.  Comment By: Abel Pascual (abelpascual) Date: 20070903 17:37 Message: Logged In: YES user_id=1881850 Originator: YES Ok, sorry for my mistake, and thanks for your explanation...  Comment By: Harald Geyer (hgeyer) Date: 20070903 16:12 Message: Logged In: YES user_id=929336 Originator: NO Hi Abel! Thanks for you interest in maxima. The behaviour, that you see is a basic property of fixed precision floating point numbers (maxima acutally is using maschine doubles IIRC): The number 4.6e8 is not representable exactly in base 2 arithmetic, thus maxima rounds the number to the next number that can be represented as double float. If you need higher precision, you can use bfloats: 4.6b8 If you want exact numbers, you can use rational arithmetic. In this case enter the number as: 46*10^7 (that is: without decimal dot) If you still have questions, you might ask on the Mailinglist. I'm closing your bug report now, because this is nothing we can fix in maxima.  Comment By: Abel Pascual (abelpascual) Date: 20070903 10:06 Message: Logged In: YES user_id=1881850 Originator: YES Greetings  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1787111&group_id=4933 
From: SourceForge.net <noreply@so...>  20070907 02:56:47

Bugs item #1787111, was opened at 20070903 10:04 Message generated for change (Comment added) made by rtoy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1787111&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: Abel Pascual (abelpascual) Assigned to: Nobody/Anonymous (nobody) Summary: Floating point imprecission Initial Comment: I don't understand why Maxima rounds down the number... I'm currently running Ubuntu 7.04. Maxima 5.13.0 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. This is a development version of Maxima. The function bug_report() provides bug reporting information. (%i1) 4.6*10^8; (%o1) 4.5999999999999994E+8  >Comment By: Raymond Toy (rtoy) Date: 20070906 22:56 Message: Logged In: YES user_id=28849 Originator: NO We should probably file a bug report for clisp for item 2. Changing ~e to ~d is ok, but ~d is really ~a, so we should just use ~a. There is a difference, however. ~e pads numbers on the left and ~a pads on the right.t. DDoDont' know if that matters or not. In addition, cmucl has a known bug that ~e prints numbers differently from ~a (princ). ~a is more accurate.  Comment By: Robert Dodier (robert_dodier) Date: 20070906 22:06 Message: Logged In: YES user_id=501686 Originator: NO (1) I've reported GCL's failure to parse 4.6e8 correctly to the GCL bug tracker as # 20992. https://savannah.gnu.org/bugs/index.php?20992 So as for this 4.6e8 in Maxima + GCL, we can close it because the problem is not in Maxima. (2) About Clisp printing 46e7 as 4.5999999999999996E+8, it appears that Clisp is interpreting "~ve" to indicate a coercion to singlefloat before formatting it. Changing the "~ve" to "~vd" in EXPLODEN in src/commac.lisp appears to tell Clisp to format 46e7 as 4.6E8. SBCL and GCL are happy with "~vd". Leaving this report open to gather comments on item (2). If nobody is opposed, I'll modify EXPLODEN as described above.  Comment By: Raymond Toy (rtoy) Date: 20070905 10:20 Message: Logged In: YES user_id=28849 Originator: NO Good question. I wasn't sure, so I checked the code. Look at makenumber and readlist in nparse.lisp. If the number is not a bigfloat, readlist is called, which basically calls Lisp readfromstring to read "4.6e8". So the result depends on the underlying Lisp. All Lisps should say (floor 4.6d8) is 46000000 and 0.0d0. Clisp and cmucl do. gcl does not. We could implement our own reader. However, for a bigfloat, maxima sees 4.6, converts it to 46/10 and then multiplies by 10^8 to get a rational number. This is then converted to a bigfloat. I think 21 is because we want upto 16 digits printed, and the 5 is to make sure there's space to print the exponent marker, a sign, and the exponent itself (3 digits). If 16 is used, the number of significant digits would be too small. I think it is a bug in gcl and clisp that it prints something other than 4.6d8.  Comment By: Andrej Vodopivec (andrejv) Date: 20070905 03:27 Message: Logged In: YES user_id=1179910 Originator: NO I don't think 4.6*10^8 is parsed as one number. First 4.6 is parsed, then 10^8, and then they are multiplied. To enter 4.6e8 you should enter it as 4.6e8. OTOH, 4.6e8 is not printed correctly on clisp and gcl. The reason is that floats are printed with (format nil "~ve" 21 4.6e8) I think 21 is arbitrarily chosen  if it was 19, all lisps print it correctly, but then maybe some other example would be printed incorrectly. Why don't we just use (format nil "~ve" 16 4.6e8). Andrej  Comment By: Raymond Toy (rtoy) Date: 20070904 14:47 Message: Logged In: YES user_id=28849 Originator: NO The issues you see with GCL and CLISP are somewhat related, but outside the scope of this bug. If you want to discuss it further, I'd be happy to. Just not here. Please mail me directly or, even better, use the maxima mailing list.  Comment By: Abel Pascual (abelpascual) Date: 20070904 13:50 Message: Logged In: YES user_id=1881850 Originator: YES I don't know if there is any relation, but in GCL I'm having the same issue: >(* 4.6 (expt 10 8)) 4.5999999999999994E8 But otherwise in CLISP this is not happening: [1]> (* 4.6 (expt 10 8)) 4.6E8  Comment By: Raymond Toy (rtoy) Date: 20070904 13:11 Message: Logged In: YES user_id=28849 Originator: NO Actually 4.6e8 is an integer: 460000000. This should be exactly representable as a doublefloat. I think it is an error that maxima prints something else out. Reopening this bug.  Comment By: Abel Pascual (abelpascual) Date: 20070903 17:37 Message: Logged In: YES user_id=1881850 Originator: YES Ok, sorry for my mistake, and thanks for your explanation...  Comment By: Harald Geyer (hgeyer) Date: 20070903 16:12 Message: Logged In: YES user_id=929336 Originator: NO Hi Abel! Thanks for you interest in maxima. The behaviour, that you see is a basic property of fixed precision floating point numbers (maxima acutally is using maschine doubles IIRC): The number 4.6e8 is not representable exactly in base 2 arithmetic, thus maxima rounds the number to the next number that can be represented as double float. If you need higher precision, you can use bfloats: 4.6b8 If you want exact numbers, you can use rational arithmetic. In this case enter the number as: 46*10^7 (that is: without decimal dot) If you still have questions, you might ask on the Mailinglist. I'm closing your bug report now, because this is nothing we can fix in maxima.  Comment By: Abel Pascual (abelpascual) Date: 20070903 10:06 Message: Logged In: YES user_id=1881850 Originator: YES Greetings  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1787111&group_id=4933 
From: SourceForge.net <noreply@so...>  20070907 02:20:13

Bugs item #1780506, was opened at 20070823 12:19 Message generated for change (Comment added) made by sfrobot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1780506&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: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: problem with the function floor Initial Comment: > float(log(8)/log(2)); > 3.0; > floor(%); > 2; < What?! It's an error! > floor(3.0); > 3;  Maxima version: 5.12.0 Maxima build date: 10:43 5/15/2007 host type: i686pclinuxgnu lispimplementationtype: CLISP lispimplementationversion: 2.41 (20061013) (built 3371985193) (memory 3388207441)   >Comment By: SourceForge Robot (sfrobot) Date: 20070906 19:20 Message: Logged In: YES user_id=1312539 Originator: NO This Tracker item was closed automatically by the system. It was previously set to a Pending status, and the original submitter did not respond within 14 days (the time period specified by the administrator of this Tracker).  Comment By: Raymond Toy (rtoy) Date: 20070823 12:38 Message: Logged In: YES user_id=28849 Originator: NO This is really a deficiency with maxima's printer. float(log(8)/log(2)) is 2.9999999999999996. Hence, floor is correct in returning 2. To see this, use ":lisp $%o<n>", assuming your Lisp has an accurate printer. If not, then try :lisp (integerdecodefloat $%o<n>). Compare that with :lisp (integerdecodefloat 3d0). Set to pending.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1780506&group_id=4933 
From: SourceForge.net <noreply@so...>  20070907 02:06:26

Bugs item #1787111, was opened at 20070903 08:04 Message generated for change (Comment added) made by robert_dodier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1787111&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: Abel Pascual (abelpascual) Assigned to: Nobody/Anonymous (nobody) Summary: Floating point imprecission Initial Comment: I don't understand why Maxima rounds down the number... I'm currently running Ubuntu 7.04. Maxima 5.13.0 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. This is a development version of Maxima. The function bug_report() provides bug reporting information. (%i1) 4.6*10^8; (%o1) 4.5999999999999994E+8  >Comment By: Robert Dodier (robert_dodier) Date: 20070906 20:06 Message: Logged In: YES user_id=501686 Originator: NO (1) I've reported GCL's failure to parse 4.6e8 correctly to the GCL bug tracker as # 20992. https://savannah.gnu.org/bugs/index.php?20992 So as for this 4.6e8 in Maxima + GCL, we can close it because the problem is not in Maxima. (2) About Clisp printing 46e7 as 4.5999999999999996E+8, it appears that Clisp is interpreting "~ve" to indicate a coercion to singlefloat before formatting it. Changing the "~ve" to "~vd" in EXPLODEN in src/commac.lisp appears to tell Clisp to format 46e7 as 4.6E8. SBCL and GCL are happy with "~vd". Leaving this report open to gather comments on item (2). If nobody is opposed, I'll modify EXPLODEN as described above.  Comment By: Raymond Toy (rtoy) Date: 20070905 08:20 Message: Logged In: YES user_id=28849 Originator: NO Good question. I wasn't sure, so I checked the code. Look at makenumber and readlist in nparse.lisp. If the number is not a bigfloat, readlist is called, which basically calls Lisp readfromstring to read "4.6e8". So the result depends on the underlying Lisp. All Lisps should say (floor 4.6d8) is 46000000 and 0.0d0. Clisp and cmucl do. gcl does not. We could implement our own reader. However, for a bigfloat, maxima sees 4.6, converts it to 46/10 and then multiplies by 10^8 to get a rational number. This is then converted to a bigfloat. I think 21 is because we want upto 16 digits printed, and the 5 is to make sure there's space to print the exponent marker, a sign, and the exponent itself (3 digits). If 16 is used, the number of significant digits would be too small. I think it is a bug in gcl and clisp that it prints something other than 4.6d8.  Comment By: Andrej Vodopivec (andrejv) Date: 20070905 01:27 Message: Logged In: YES user_id=1179910 Originator: NO I don't think 4.6*10^8 is parsed as one number. First 4.6 is parsed, then 10^8, and then they are multiplied. To enter 4.6e8 you should enter it as 4.6e8. OTOH, 4.6e8 is not printed correctly on clisp and gcl. The reason is that floats are printed with (format nil "~ve" 21 4.6e8) I think 21 is arbitrarily chosen  if it was 19, all lisps print it correctly, but then maybe some other example would be printed incorrectly. Why don't we just use (format nil "~ve" 16 4.6e8). Andrej  Comment By: Raymond Toy (rtoy) Date: 20070904 12:47 Message: Logged In: YES user_id=28849 Originator: NO The issues you see with GCL and CLISP are somewhat related, but outside the scope of this bug. If you want to discuss it further, I'd be happy to. Just not here. Please mail me directly or, even better, use the maxima mailing list.  Comment By: Abel Pascual (abelpascual) Date: 20070904 11:50 Message: Logged In: YES user_id=1881850 Originator: YES I don't know if there is any relation, but in GCL I'm having the same issue: >(* 4.6 (expt 10 8)) 4.5999999999999994E8 But otherwise in CLISP this is not happening: [1]> (* 4.6 (expt 10 8)) 4.6E8  Comment By: Raymond Toy (rtoy) Date: 20070904 11:11 Message: Logged In: YES user_id=28849 Originator: NO Actually 4.6e8 is an integer: 460000000. This should be exactly representable as a doublefloat. I think it is an error that maxima prints something else out. Reopening this bug.  Comment By: Abel Pascual (abelpascual) Date: 20070903 15:37 Message: Logged In: YES user_id=1881850 Originator: YES Ok, sorry for my mistake, and thanks for your explanation...  Comment By: Harald Geyer (hgeyer) Date: 20070903 14:12 Message: Logged In: YES user_id=929336 Originator: NO Hi Abel! Thanks for you interest in maxima. The behaviour, that you see is a basic property of fixed precision floating point numbers (maxima acutally is using maschine doubles IIRC): The number 4.6e8 is not representable exactly in base 2 arithmetic, thus maxima rounds the number to the next number that can be represented as double float. If you need higher precision, you can use bfloats: 4.6b8 If you want exact numbers, you can use rational arithmetic. In this case enter the number as: 46*10^7 (that is: without decimal dot) If you still have questions, you might ask on the Mailinglist. I'm closing your bug report now, because this is nothing we can fix in maxima.  Comment By: Abel Pascual (abelpascual) Date: 20070903 08:06 Message: Logged In: YES user_id=1881850 Originator: YES Greetings  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1787111&group_id=4933 
From: SourceForge.net <noreply@so...>  20070906 08:48:30

Bugs item #1789213, was opened at 20070906 01:48 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=1789213&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: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: ic1 for solution containing indefinite integral Initial Comment: It seems that ic1(s, x, y) fails to produce a meaningful result when s involves an indefinite integral. Example: (%i2) sol: ode2(kappa(p) = 'diff(V, p) / V, V, p); / [  I kappa(p) dp ] / (%o2) V = %c %e (%i3) ic1(sol, p = p0, V = V0); / / [ [ I kappa(p0) dp0  I kappa(p) dp ] ] / / (%o3) V = %e V0 (%i4) ic1(sol, V = V0, p = p0); / / [ [ I kappa(p0) dp0  I kappa(p) dp ] ] / / (%o4) V = %e V0 As the two integrals in %o3 and %o4 differ only by the integration variable, it is difficult to see in what sense the solution is correct. The expected solution is, of course, something like V = V0 * exp('integrate(kappa(p1), p1, p0, p)). Even worse are the substitutions when the values for the integration variables are nonatomic: (%i6) ic1(sol, V = V0, p = p0 + p1); / / [ [ I kappa(p1 + p0) dp1 + p0  I kappa(p) dp ] ] / / (%o6) V = %e V0 At least the printer should be modified to give d(p1+p0), or even dp1 + dp0, for a nonatomic integration variable. I have not tested whether ic2 misbehaves in an analogous manner. A. Reiner, <areiner@...>.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1789213&group_id=4933 
From: SourceForge.net <noreply@so...>  20070905 14:20:09

Bugs item #1787111, was opened at 20070903 10:04 Message generated for change (Comment added) made by rtoy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1787111&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: Abel Pascual (abelpascual) Assigned to: Nobody/Anonymous (nobody) Summary: Floating point imprecission Initial Comment: I don't understand why Maxima rounds down the number... I'm currently running Ubuntu 7.04. Maxima 5.13.0 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. This is a development version of Maxima. The function bug_report() provides bug reporting information. (%i1) 4.6*10^8; (%o1) 4.5999999999999994E+8  >Comment By: Raymond Toy (rtoy) Date: 20070905 10:20 Message: Logged In: YES user_id=28849 Originator: NO Good question. I wasn't sure, so I checked the code. Look at makenumber and readlist in nparse.lisp. If the number is not a bigfloat, readlist is called, which basically calls Lisp readfromstring to read "4.6e8". So the result depends on the underlying Lisp. All Lisps should say (floor 4.6d8) is 46000000 and 0.0d0. Clisp and cmucl do. gcl does not. We could implement our own reader. However, for a bigfloat, maxima sees 4.6, converts it to 46/10 and then multiplies by 10^8 to get a rational number. This is then converted to a bigfloat. I think 21 is because we want upto 16 digits printed, and the 5 is to make sure there's space to print the exponent marker, a sign, and the exponent itself (3 digits). If 16 is used, the number of significant digits would be too small. I think it is a bug in gcl and clisp that it prints something other than 4.6d8.  Comment By: Andrej Vodopivec (andrejv) Date: 20070905 03:27 Message: Logged In: YES user_id=1179910 Originator: NO I don't think 4.6*10^8 is parsed as one number. First 4.6 is parsed, then 10^8, and then they are multiplied. To enter 4.6e8 you should enter it as 4.6e8. OTOH, 4.6e8 is not printed correctly on clisp and gcl. The reason is that floats are printed with (format nil "~ve" 21 4.6e8) I think 21 is arbitrarily chosen  if it was 19, all lisps print it correctly, but then maybe some other example would be printed incorrectly. Why don't we just use (format nil "~ve" 16 4.6e8). Andrej  Comment By: Raymond Toy (rtoy) Date: 20070904 14:47 Message: Logged In: YES user_id=28849 Originator: NO The issues you see with GCL and CLISP are somewhat related, but outside the scope of this bug. If you want to discuss it further, I'd be happy to. Just not here. Please mail me directly or, even better, use the maxima mailing list.  Comment By: Abel Pascual (abelpascual) Date: 20070904 13:50 Message: Logged In: YES user_id=1881850 Originator: YES I don't know if there is any relation, but in GCL I'm having the same issue: >(* 4.6 (expt 10 8)) 4.5999999999999994E8 But otherwise in CLISP this is not happening: [1]> (* 4.6 (expt 10 8)) 4.6E8  Comment By: Raymond Toy (rtoy) Date: 20070904 13:11 Message: Logged In: YES user_id=28849 Originator: NO Actually 4.6e8 is an integer: 460000000. This should be exactly representable as a doublefloat. I think it is an error that maxima prints something else out. Reopening this bug.  Comment By: Abel Pascual (abelpascual) Date: 20070903 17:37 Message: Logged In: YES user_id=1881850 Originator: YES Ok, sorry for my mistake, and thanks for your explanation...  Comment By: Harald Geyer (hgeyer) Date: 20070903 16:12 Message: Logged In: YES user_id=929336 Originator: NO Hi Abel! Thanks for you interest in maxima. The behaviour, that you see is a basic property of fixed precision floating point numbers (maxima acutally is using maschine doubles IIRC): The number 4.6e8 is not representable exactly in base 2 arithmetic, thus maxima rounds the number to the next number that can be represented as double float. If you need higher precision, you can use bfloats: 4.6b8 If you want exact numbers, you can use rational arithmetic. In this case enter the number as: 46*10^7 (that is: without decimal dot) If you still have questions, you might ask on the Mailinglist. I'm closing your bug report now, because this is nothing we can fix in maxima.  Comment By: Abel Pascual (abelpascual) Date: 20070903 10:06 Message: Logged In: YES user_id=1881850 Originator: YES Greetings  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1787111&group_id=4933 
From: SourceForge.net <noreply@so...>  20070905 07:27:17

Bugs item #1787111, was opened at 20070903 16:04 Message generated for change (Comment added) made by andrejv You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1787111&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: Abel Pascual (abelpascual) Assigned to: Nobody/Anonymous (nobody) Summary: Floating point imprecission Initial Comment: I don't understand why Maxima rounds down the number... I'm currently running Ubuntu 7.04. Maxima 5.13.0 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. This is a development version of Maxima. The function bug_report() provides bug reporting information. (%i1) 4.6*10^8; (%o1) 4.5999999999999994E+8  >Comment By: Andrej Vodopivec (andrejv) Date: 20070905 09:27 Message: Logged In: YES user_id=1179910 Originator: NO I don't think 4.6*10^8 is parsed as one number. First 4.6 is parsed, then 10^8, and then they are multiplied. To enter 4.6e8 you should enter it as 4.6e8. OTOH, 4.6e8 is not printed correctly on clisp and gcl. The reason is that floats are printed with (format nil "~ve" 21 4.6e8) I think 21 is arbitrarily chosen  if it was 19, all lisps print it correctly, but then maybe some other example would be printed incorrectly. Why don't we just use (format nil "~ve" 16 4.6e8). Andrej  Comment By: Raymond Toy (rtoy) Date: 20070904 20:47 Message: Logged In: YES user_id=28849 Originator: NO The issues you see with GCL and CLISP are somewhat related, but outside the scope of this bug. If you want to discuss it further, I'd be happy to. Just not here. Please mail me directly or, even better, use the maxima mailing list.  Comment By: Abel Pascual (abelpascual) Date: 20070904 19:50 Message: Logged In: YES user_id=1881850 Originator: YES I don't know if there is any relation, but in GCL I'm having the same issue: >(* 4.6 (expt 10 8)) 4.5999999999999994E8 But otherwise in CLISP this is not happening: [1]> (* 4.6 (expt 10 8)) 4.6E8  Comment By: Raymond Toy (rtoy) Date: 20070904 19:11 Message: Logged In: YES user_id=28849 Originator: NO Actually 4.6e8 is an integer: 460000000. This should be exactly representable as a doublefloat. I think it is an error that maxima prints something else out. Reopening this bug.  Comment By: Abel Pascual (abelpascual) Date: 20070903 23:37 Message: Logged In: YES user_id=1881850 Originator: YES Ok, sorry for my mistake, and thanks for your explanation...  Comment By: Harald Geyer (hgeyer) Date: 20070903 22:12 Message: Logged In: YES user_id=929336 Originator: NO Hi Abel! Thanks for you interest in maxima. The behaviour, that you see is a basic property of fixed precision floating point numbers (maxima acutally is using maschine doubles IIRC): The number 4.6e8 is not representable exactly in base 2 arithmetic, thus maxima rounds the number to the next number that can be represented as double float. If you need higher precision, you can use bfloats: 4.6b8 If you want exact numbers, you can use rational arithmetic. In this case enter the number as: 46*10^7 (that is: without decimal dot) If you still have questions, you might ask on the Mailinglist. I'm closing your bug report now, because this is nothing we can fix in maxima.  Comment By: Abel Pascual (abelpascual) Date: 20070903 16:06 Message: Logged In: YES user_id=1881850 Originator: YES Greetings  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1787111&group_id=4933 
From: SourceForge.net <noreply@so...>  20070904 18:47:28

Bugs item #1787111, was opened at 20070903 10:04 Message generated for change (Comment added) made by rtoy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1787111&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: Abel Pascual (abelpascual) Assigned to: Nobody/Anonymous (nobody) Summary: Floating point imprecission Initial Comment: I don't understand why Maxima rounds down the number... I'm currently running Ubuntu 7.04. Maxima 5.13.0 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. This is a development version of Maxima. The function bug_report() provides bug reporting information. (%i1) 4.6*10^8; (%o1) 4.5999999999999994E+8  >Comment By: Raymond Toy (rtoy) Date: 20070904 14:47 Message: Logged In: YES user_id=28849 Originator: NO The issues you see with GCL and CLISP are somewhat related, but outside the scope of this bug. If you want to discuss it further, I'd be happy to. Just not here. Please mail me directly or, even better, use the maxima mailing list.  Comment By: Abel Pascual (abelpascual) Date: 20070904 13:50 Message: Logged In: YES user_id=1881850 Originator: YES I don't know if there is any relation, but in GCL I'm having the same issue: >(* 4.6 (expt 10 8)) 4.5999999999999994E8 But otherwise in CLISP this is not happening: [1]> (* 4.6 (expt 10 8)) 4.6E8  Comment By: Raymond Toy (rtoy) Date: 20070904 13:11 Message: Logged In: YES user_id=28849 Originator: NO Actually 4.6e8 is an integer: 460000000. This should be exactly representable as a doublefloat. I think it is an error that maxima prints something else out. Reopening this bug.  Comment By: Abel Pascual (abelpascual) Date: 20070903 17:37 Message: Logged In: YES user_id=1881850 Originator: YES Ok, sorry for my mistake, and thanks for your explanation...  Comment By: Harald Geyer (hgeyer) Date: 20070903 16:12 Message: Logged In: YES user_id=929336 Originator: NO Hi Abel! Thanks for you interest in maxima. The behaviour, that you see is a basic property of fixed precision floating point numbers (maxima acutally is using maschine doubles IIRC): The number 4.6e8 is not representable exactly in base 2 arithmetic, thus maxima rounds the number to the next number that can be represented as double float. If you need higher precision, you can use bfloats: 4.6b8 If you want exact numbers, you can use rational arithmetic. In this case enter the number as: 46*10^7 (that is: without decimal dot) If you still have questions, you might ask on the Mailinglist. I'm closing your bug report now, because this is nothing we can fix in maxima.  Comment By: Abel Pascual (abelpascual) Date: 20070903 10:06 Message: Logged In: YES user_id=1881850 Originator: YES Greetings  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1787111&group_id=4933 
From: SourceForge.net <noreply@so...>  20070904 17:50:29

Bugs item #1787111, was opened at 20070903 16:04 Message generated for change (Comment added) made by abelpascual You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1787111&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: Abel Pascual (abelpascual) Assigned to: Nobody/Anonymous (nobody) Summary: Floating point imprecission Initial Comment: I don't understand why Maxima rounds down the number... I'm currently running Ubuntu 7.04. Maxima 5.13.0 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. This is a development version of Maxima. The function bug_report() provides bug reporting information. (%i1) 4.6*10^8; (%o1) 4.5999999999999994E+8  >Comment By: Abel Pascual (abelpascual) Date: 20070904 19:50 Message: Logged In: YES user_id=1881850 Originator: YES I don't know if there is any relation, but in GCL I'm having the same issue: >(* 4.6 (expt 10 8)) 4.5999999999999994E8 But otherwise in CLISP this is not happening: [1]> (* 4.6 (expt 10 8)) 4.6E8  Comment By: Raymond Toy (rtoy) Date: 20070904 19:11 Message: Logged In: YES user_id=28849 Originator: NO Actually 4.6e8 is an integer: 460000000. This should be exactly representable as a doublefloat. I think it is an error that maxima prints something else out. Reopening this bug.  Comment By: Abel Pascual (abelpascual) Date: 20070903 23:37 Message: Logged In: YES user_id=1881850 Originator: YES Ok, sorry for my mistake, and thanks for your explanation...  Comment By: Harald Geyer (hgeyer) Date: 20070903 22:12 Message: Logged In: YES user_id=929336 Originator: NO Hi Abel! Thanks for you interest in maxima. The behaviour, that you see is a basic property of fixed precision floating point numbers (maxima acutally is using maschine doubles IIRC): The number 4.6e8 is not representable exactly in base 2 arithmetic, thus maxima rounds the number to the next number that can be represented as double float. If you need higher precision, you can use bfloats: 4.6b8 If you want exact numbers, you can use rational arithmetic. In this case enter the number as: 46*10^7 (that is: without decimal dot) If you still have questions, you might ask on the Mailinglist. I'm closing your bug report now, because this is nothing we can fix in maxima.  Comment By: Abel Pascual (abelpascual) Date: 20070903 16:06 Message: Logged In: YES user_id=1881850 Originator: YES Greetings  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1787111&group_id=4933 
From: SourceForge.net <noreply@so...>  20070904 17:11:22

Bugs item #1787111, was opened at 20070903 10:04 Message generated for change (Comment added) made by rtoy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1787111&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: Abel Pascual (abelpascual) Assigned to: Nobody/Anonymous (nobody) Summary: Floating point imprecission Initial Comment: I don't understand why Maxima rounds down the number... I'm currently running Ubuntu 7.04. Maxima 5.13.0 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. This is a development version of Maxima. The function bug_report() provides bug reporting information. (%i1) 4.6*10^8; (%o1) 4.5999999999999994E+8  >Comment By: Raymond Toy (rtoy) Date: 20070904 13:11 Message: Logged In: YES user_id=28849 Originator: NO Actually 4.6e8 is an integer: 460000000. This should be exactly representable as a doublefloat. I think it is an error that maxima prints something else out. Reopening this bug.  Comment By: Abel Pascual (abelpascual) Date: 20070903 17:37 Message: Logged In: YES user_id=1881850 Originator: YES Ok, sorry for my mistake, and thanks for your explanation...  Comment By: Harald Geyer (hgeyer) Date: 20070903 16:12 Message: Logged In: YES user_id=929336 Originator: NO Hi Abel! Thanks for you interest in maxima. The behaviour, that you see is a basic property of fixed precision floating point numbers (maxima acutally is using maschine doubles IIRC): The number 4.6e8 is not representable exactly in base 2 arithmetic, thus maxima rounds the number to the next number that can be represented as double float. If you need higher precision, you can use bfloats: 4.6b8 If you want exact numbers, you can use rational arithmetic. In this case enter the number as: 46*10^7 (that is: without decimal dot) If you still have questions, you might ask on the Mailinglist. I'm closing your bug report now, because this is nothing we can fix in maxima.  Comment By: Abel Pascual (abelpascual) Date: 20070903 10:06 Message: Logged In: YES user_id=1881850 Originator: YES Greetings  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1787111&group_id=4933 
From: SourceForge.net <noreply@so...>  20070903 21:37:51

Bugs item #1787111, was opened at 20070903 16:04 Message generated for change (Comment added) made by abelpascual You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1787111&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: Abel Pascual (abelpascual) Assigned to: Nobody/Anonymous (nobody) Summary: Floating point imprecission Initial Comment: I don't understand why Maxima rounds down the number... I'm currently running Ubuntu 7.04. Maxima 5.13.0 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. This is a development version of Maxima. The function bug_report() provides bug reporting information. (%i1) 4.6*10^8; (%o1) 4.5999999999999994E+8  >Comment By: Abel Pascual (abelpascual) Date: 20070903 23:37 Message: Logged In: YES user_id=1881850 Originator: YES Ok, sorry for my mistake, and thanks for your explanation...  Comment By: Harald Geyer (hgeyer) Date: 20070903 22:12 Message: Logged In: YES user_id=929336 Originator: NO Hi Abel! Thanks for you interest in maxima. The behaviour, that you see is a basic property of fixed precision floating point numbers (maxima acutally is using maschine doubles IIRC): The number 4.6e8 is not representable exactly in base 2 arithmetic, thus maxima rounds the number to the next number that can be represented as double float. If you need higher precision, you can use bfloats: 4.6b8 If you want exact numbers, you can use rational arithmetic. In this case enter the number as: 46*10^7 (that is: without decimal dot) If you still have questions, you might ask on the Mailinglist. I'm closing your bug report now, because this is nothing we can fix in maxima.  Comment By: Abel Pascual (abelpascual) Date: 20070903 16:06 Message: Logged In: YES user_id=1881850 Originator: YES Greetings  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1787111&group_id=4933 
From: SourceForge.net <noreply@so...>  20070903 20:12:12

Bugs item #1787111, was opened at 20070903 16:04 Message generated for change (Comment added) made by hgeyer You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1787111&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: Abel Pascual (abelpascual) Assigned to: Nobody/Anonymous (nobody) Summary: Floating point imprecission Initial Comment: I don't understand why Maxima rounds down the number... I'm currently running Ubuntu 7.04. Maxima 5.13.0 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. This is a development version of Maxima. The function bug_report() provides bug reporting information. (%i1) 4.6*10^8; (%o1) 4.5999999999999994E+8  >Comment By: Harald Geyer (hgeyer) Date: 20070903 22:12 Message: Logged In: YES user_id=929336 Originator: NO Hi Abel! Thanks for you interest in maxima. The behaviour, that you see is a basic property of fixed precision floating point numbers (maxima acutally is using maschine doubles IIRC): The number 4.6e8 is not representable exactly in base 2 arithmetic, thus maxima rounds the number to the next number that can be represented as double float. If you need higher precision, you can use bfloats: 4.6b8 If you want exact numbers, you can use rational arithmetic. In this case enter the number as: 46*10^7 (that is: without decimal dot) If you still have questions, you might ask on the Mailinglist. I'm closing your bug report now, because this is nothing we can fix in maxima.  Comment By: Abel Pascual (abelpascual) Date: 20070903 16:06 Message: Logged In: YES user_id=1881850 Originator: YES Greetings  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1787111&group_id=4933 
From: SourceForge.net <noreply@so...>  20070903 14:06:57

Bugs item #1787111, was opened at 20070903 16:04 Message generated for change (Comment added) made by abelpascual You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1787111&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: Abel Pascual (abelpascual) Assigned to: Nobody/Anonymous (nobody) Summary: Floating point imprecission Initial Comment: I don't understand why Maxima rounds down the number... I'm currently running Ubuntu 7.04. Maxima 5.13.0 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. This is a development version of Maxima. The function bug_report() provides bug reporting information. (%i1) 4.6*10^8; (%o1) 4.5999999999999994E+8  >Comment By: Abel Pascual (abelpascual) Date: 20070903 16:06 Message: Logged In: YES user_id=1881850 Originator: YES Greetings  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1787111&group_id=4933 
From: SourceForge.net <noreply@so...>  20070903 14:04:39

Bugs item #1787111, was opened at 20070903 16:04 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=1787111&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: Abel Pascual (abelpascual) Assigned to: Nobody/Anonymous (nobody) Summary: Floating point imprecission Initial Comment: I don't understand why Maxima rounds down the number... I'm currently running Ubuntu 7.04. Maxima 5.13.0 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. This is a development version of Maxima. The function bug_report() provides bug reporting information. (%i1) 4.6*10^8; (%o1) 4.5999999999999994E+8  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1787111&group_id=4933 
From: SourceForge.net <noreply@so...>  20070902 22:58:47

Bugs item #826627, was opened at 20031020 00:49 Message generated for change (Settings changed) made by dgildea You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=826627&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: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: integrate quotient (gcd?) problems Initial Comment: integrate( x*%E^(a*x/2)*SIN(SQRT(ba^2)*x) , x) => Quotient by a polynomial of higher degree Another similar problem: integrate( x*%E^(a*x)*SIN(SQRT(ba^2)*x/2) , x) => quotient is not exact Usually, this sort of problem is solved by changing GCD algorithm (setting the GCD variable), but in this case, all the GCD routines have the same problem. (Problem originally found by Jared Alem in assume (4*b>a^2)$ 'diff(y,x,2) + a*'diff(y,x) + b*y = c*x;) Maxima 5.9.0 gcl 2.5.0 mingw32 W2k Athlon  Comment By: Dan Gildea (dgildea) Date: 20070902 17:34 Message: Logged In: YES user_id=1797506 Originator: NO fixed by 1606731. (%i12) integrate( x*%e^(a*x/2)*sin(sqrt(ba^2)*x) , x),gcd:subres; (%o12) (((6*a^38*a*b)*x16*b+20*a^2)*%e^(a*x/2)*sin(sqrt(ba^2)*x) +sqrt(ba^2)*((16*b12*a^2)*x16*a)*%e^(a*x/2)*cos(sqrt(ba^2)*x)) /(16*b^224*a^2*b+9*a^4) (%i13) ratsimp(diff(%,x)); (%o13) x*%e^(a*x/2)*sin(sqrt(ba^2)*x) (%i14) integrate( x*%e^(a*x/2)*sin(sqrt(ba^2)*x) , x),gcd:spmod; (%o14) (((6*a^38*a*b)*x16*b+20*a^2)*%e^(a*x/2)*sin(sqrt(ba^2)*x) +sqrt(ba^2)*((16*b12*a^2)*x16*a)*%e^(a*x/2)*cos(sqrt(ba^2)*x)) /(16*b^224*a^2*b+9*a^4) (%i15) ratsimp(diff(%,x)); (%o15) x*%e^(a*x/2)*sin(sqrt(ba^2)*x) (%i16) integrate( x*%e^(a*x)*sin(sqrt(ba^2)*x/2) , x),gcd:subres; (%o16) (((4*a*b12*a^3)*x4*b+20*a^2)*%e^(a*x)*sin(sqrt(ba^2)*x/2) +sqrt(ba^2)*((2*b+6*a^2)*x16*a)*%e^(a*x)*cos(sqrt(ba^2)*x/2)) /(b^2+6*a^2*b+9*a^4) (%i17) ratsimp(diff(%,x)); (%o17) x*%e^(a*x)*sin(sqrt(ba^2)*x/2)  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=826627&group_id=4933 
From: SourceForge.net <noreply@so...>  20070902 22:19:44

Bugs item #593449, was opened at 20020810 11:35 Message generated for change (Comment added) made by dgildea You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=593449&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: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: Taylor internal error Initial Comment: taylor(log(sqrt(y^e*y+1)+y),e,0,2) gives Quotient by a polynomial of higher degree (The Solve quadratic patch is loaded.)  >Comment By: Dan Gildea (dgildea) Date: 20070902 18:19 Message: Logged In: YES user_id=1797506 Originator: NO fixed by 1606731 (%i26) taylor(log(sqrt(y^e*y+1)+y),e,0,2); (%o26) log(sqrt(y+1)+y)+sqrt(y+1)*log(y)*y*e /(2*y^2+(2*sqrt(y+1)+2)*y+2*sqrt(y+1)) +((sqrt(y+1)+1)*log(y)^2*y^4 +(2*sqrt(y+1)+5)*log(y)^2*y^3 +(2*sqrt(y+1)+4)*log(y)^2*y^2+2*sqrt(y+1)*log(y)^2*y) *e^2 /(8*y^5+(24*sqrt(y+1)+40)*y^4+(56*sqrt(y+1)+80)*y^3 +(48*sqrt(y+1)+72)*y^2+(24*sqrt(y+1)+24)*y +8*sqrt(y+1)) (%i27) gcd; (%o27) spmod (%i28) taylor(log(sqrt(y^e*y+1)+y),e,0,2),gcd:subres; (%o28) log(sqrt(y+1)+y)+sqrt(y+1)*log(y)*y*e /(2*y^2+(2*sqrt(y+1)+2)*y+2*sqrt(y+1)) +((sqrt(y+1)+1)*log(y)^2*y^5 +(3*sqrt(y+1)+6)*log(y)^2*y^4 +(4*sqrt(y+1)+9)*log(y)^2*y^3 +(4*sqrt(y+1)+4)*log(y)^2*y^2+2*sqrt(y+1)*log(y)^2*y) *e^2 /(8*y^6+(24*sqrt(y+1)+48)*y^5+(80*sqrt(y+1)+120)*y^4 +(104*sqrt(y+1)+152)*y^3+(72*sqrt(y+1)+96)*y^2 +(32*sqrt(y+1)+24)*y+8*sqrt(y+1)) (%i29) is(equal(%o26,%o28)); (%o29) true  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=593449&group_id=4933 
From: SourceForge.net <noreply@so...>  20070902 22:14:02

Bugs item #629539, was opened at 20021027 15:40 Message generated for change (Comment added) made by dgildea You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=629539&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: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Barton Willis (willisb) Assigned to: Nobody/Anonymous (nobody) Summary: taylor(x + sqrt(1+x^2),x,a,2) Initial Comment: (C1) display2d : false; (D1) FALSE (C2) p : x + sqrt(1+x^2); (D2) SQRT(x^2+1)+x With ratfac true, Maxima finds the Taylor polynomial of p centered at a with no problem (C3) ratfac : true; (D3) TRUE (C4) taylor(p,x,a,2); (D4) SQRT(a^2+1)+a+(a^2+SQRT(a^2+1)*a+1)*(xa)/(a^2+1) +(xa)^2/(2*SQRT(a^2+1)*(a^2+1)) But setting ratfac to false, we get an error (C5) ratfac : false; (D5) FALSE (C6) taylor(p,x,a,2); Quotient by a polynomial of higher degree  an error. Quitting. To debug this try DEBUGMODE(TRUE);) (C7) This same bug may be responsible for the bug (C11) taylor(asin(x),x,a,2), ratfac : false; Quotient by a polynomial of higher degree  an error. Quitting. To debug this try DEBUGMODE(TRUE);) (C12) taylor(asin(x),x,a,2), ratfac : true; Is (a1)*(a+1) positive, negative, or zero? neg; (D12) ATAN2(a,SQRT(1a^2))(a^2+SQRT(a^21)*a1)*%I*(xa) /((a+SQRT(a^21))*(a^21)) +(2*a^3+2*SQRT(a^21)*a^22*aSQRT(a^21))*%I*a *(xa)^2 /(2*(a+SQRT(a^21))^2*(a^21)^2) (C13)  >Comment By: Dan Gildea (dgildea) Date: 20070902 18:14 Message: Logged In: YES user_id=1797506 Originator: NO Fixed by 1606731 (%i22) p : x + sqrt(1+x^2); (%o22) sqrt(x^2+1)+x (%i23) taylor(p,x,a,2),ratfac:false,gcd:subres; (%o23) sqrt(a^2+1)+a+(a^2+sqrt(a^2+1)*a+1)*(xa)/(a^2+1) +sqrt(a^2+1)*(xa)^2/(2*a^4+4*a^2+2) (%i24) taylor(p,x,a,2),ratfac:true,gcd:spmod; (%o24) sqrt(a^2+1)+a+(a^2+sqrt(a^2+1)*a+1)*(xa)/(a^2+1) +(xa)^2/(2*sqrt(a^2+1)*(a^2+1)) (%i25) %o22%o23; (%o25) +0  Comment By: Barton Willis (willisbl) Date: 20070121 15:23 Message: Logged In: YES user_id=895922 Originator: NO setting gcd : spmod "fixes" this bug.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=629539&group_id=4933 