You can subscribe to this list here.
2002 
_{Jan}

_{Feb}

_{Mar}

_{Apr}

_{May}

_{Jun}
(67) 
_{Jul}
(61) 
_{Aug}
(49) 
_{Sep}
(43) 
_{Oct}
(59) 
_{Nov}
(24) 
_{Dec}
(18) 

2003 
_{Jan}
(34) 
_{Feb}
(35) 
_{Mar}
(72) 
_{Apr}
(42) 
_{May}
(46) 
_{Jun}
(15) 
_{Jul}
(64) 
_{Aug}
(62) 
_{Sep}
(22) 
_{Oct}
(41) 
_{Nov}
(57) 
_{Dec}
(56) 
2004 
_{Jan}
(48) 
_{Feb}
(47) 
_{Mar}
(33) 
_{Apr}
(39) 
_{May}
(6) 
_{Jun}
(17) 
_{Jul}
(19) 
_{Aug}
(10) 
_{Sep}
(14) 
_{Oct}
(74) 
_{Nov}
(80) 
_{Dec}
(22) 
2005 
_{Jan}
(43) 
_{Feb}
(33) 
_{Mar}
(52) 
_{Apr}
(74) 
_{May}
(32) 
_{Jun}
(58) 
_{Jul}
(18) 
_{Aug}
(41) 
_{Sep}
(71) 
_{Oct}
(28) 
_{Nov}
(65) 
_{Dec}
(68) 
2006 
_{Jan}
(54) 
_{Feb}
(37) 
_{Mar}
(82) 
_{Apr}
(211) 
_{May}
(69) 
_{Jun}
(75) 
_{Jul}
(279) 
_{Aug}
(139) 
_{Sep}
(135) 
_{Oct}
(58) 
_{Nov}
(81) 
_{Dec}
(78) 
2007 
_{Jan}
(141) 
_{Feb}
(134) 
_{Mar}
(65) 
_{Apr}
(49) 
_{May}
(61) 
_{Jun}
(90) 
_{Jul}
(72) 
_{Aug}
(53) 
_{Sep}
(86) 
_{Oct}
(61) 
_{Nov}
(62) 
_{Dec}
(101) 
2008 
_{Jan}
(100) 
_{Feb}
(66) 
_{Mar}
(76) 
_{Apr}
(95) 
_{May}
(77) 
_{Jun}
(93) 
_{Jul}
(103) 
_{Aug}
(76) 
_{Sep}
(42) 
_{Oct}
(55) 
_{Nov}
(44) 
_{Dec}
(75) 
2009 
_{Jan}
(103) 
_{Feb}
(105) 
_{Mar}
(121) 
_{Apr}
(59) 
_{May}
(103) 
_{Jun}
(82) 
_{Jul}
(67) 
_{Aug}
(76) 
_{Sep}
(85) 
_{Oct}
(75) 
_{Nov}
(181) 
_{Dec}
(133) 
2010 
_{Jan}
(107) 
_{Feb}
(116) 
_{Mar}
(145) 
_{Apr}
(89) 
_{May}
(138) 
_{Jun}
(85) 
_{Jul}
(82) 
_{Aug}
(111) 
_{Sep}
(70) 
_{Oct}
(83) 
_{Nov}
(60) 
_{Dec}
(16) 
2011 
_{Jan}
(61) 
_{Feb}
(16) 
_{Mar}
(52) 
_{Apr}
(41) 
_{May}
(34) 
_{Jun}
(41) 
_{Jul}
(57) 
_{Aug}
(73) 
_{Sep}
(21) 
_{Oct}
(45) 
_{Nov}
(50) 
_{Dec}
(28) 
2012 
_{Jan}
(70) 
_{Feb}
(36) 
_{Mar}
(71) 
_{Apr}
(29) 
_{May}
(48) 
_{Jun}
(61) 
_{Jul}
(44) 
_{Aug}
(54) 
_{Sep}
(20) 
_{Oct}
(28) 
_{Nov}
(41) 
_{Dec}
(137) 
2013 
_{Jan}
(62) 
_{Feb}
(55) 
_{Mar}
(31) 
_{Apr}
(23) 
_{May}
(54) 
_{Jun}
(54) 
_{Jul}
(90) 
_{Aug}
(46) 
_{Sep}
(38) 
_{Oct}
(60) 
_{Nov}
(92) 
_{Dec}
(17) 
2014 
_{Jan}
(62) 
_{Feb}
(35) 
_{Mar}
(72) 
_{Apr}
(30) 
_{May}
(97) 
_{Jun}
(81) 
_{Jul}
(63) 
_{Aug}
(64) 
_{Sep}
(28) 
_{Oct}
(45) 
_{Nov}
(48) 
_{Dec}
(109) 
2015 
_{Jan}
(106) 
_{Feb}
(36) 
_{Mar}
(65) 
_{Apr}
(63) 
_{May}
(95) 
_{Jun}
(56) 
_{Jul}
(48) 
_{Aug}
(55) 
_{Sep}
(100) 
_{Oct}
(57) 
_{Nov}
(33) 
_{Dec}
(46) 
2016 
_{Jan}
(76) 
_{Feb}
(53) 
_{Mar}
(88) 
_{Apr}
(79) 
_{May}
(62) 
_{Jun}
(65) 
_{Jul}
(37) 
_{Aug}
(23) 
_{Sep}
(108) 
_{Oct}
(68) 
_{Nov}
(66) 
_{Dec}
(47) 
2017 
_{Jan}
(55) 
_{Feb}
(11) 
_{Mar}
(30) 
_{Apr}
(19) 
_{May}
(14) 
_{Jun}
(10) 
_{Jul}

_{Aug}

_{Sep}

_{Oct}

_{Nov}

_{Dec}

S  M  T  W  T  F  S 






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

10
(3) 
11
(1) 
12
(2) 
13
(11) 
14
(1) 
15
(5) 
16

17

18
(2) 
19
(10) 
20
(2) 
21
(2) 
22
(3) 
23
(2) 
24
(6) 
25
(2) 
26
(6) 
27
(2) 
28
(10) 
29
(1) 
30

31
(3) 






From: SourceForge.net <noreply@so...>  20090513 22:48:53

Bugs item #609464, was opened at 20020915 05:18 Message generated for change (Comment added) made by crategus You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=609464&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: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: 1+%e,numer and %e^%e,numer Initial Comment: %e^%e,numer does not evaluate numerically to 15.15... as it should, it simply returns the simplified expression %e^%e.  >Comment By: Dieter Kaiser (crategus) Date: 20090514 00:48 Message: We have the flag %enumer which should prevent the evaluation of %e to its numerical value when the flag $numer is true. The evaluation occurs only when $%enumer is true too. But we have the following code in the function $ev: (if (and (cdr l) (null (cddr l)) (eq (car l) '$%e) (eq (cadr l) '$numer)) (setq l (append l '($%enumer)))) This code is responsible for some of the inconsistent behaviors as reported in this bug report: %e is evaluated because of the above special handling: (%i5) %e,numer; (%o5) 2.718281828459045 Partially evaluation with a multiplication: (%i7) %e*(%e+1)^2,numer; (%o7) 2.7182817*(%e+1)^2 All examples are evaluated with %enumer true: (%i10) %e*(%e+1)^2,numer,%enumer; (%o10) 37.581930949508 We can prevent evaluation: (%i4) %e,numer,noeval; (%o4) %e A further complication is the simplifier. If we have an exponent, simplification and not evaluation causes the numerical evaluation. (%i5) %e^1,numer,noeval; (%o5) 2.718281828459045 First I tried to get this all more consistent by removing the hack in $ev which causes evaluation of %e in certain expressions. But because of the simplifier, as shown in the last example, this does not help completely. So, I think it would be most consistent to cut out the special handling of the flag %enumer in the code of meval1. ((and $numer (setq val (safemget form '$numer)) ;(or (not (eq form '$%e)) $%enumer) ) (return (meval1 val))) There are two further pieces of code we can cut out. With this changes %enumer has no longer a function and we would get: (%i8) %e,numer; (%o8) 2.718281828459045 (%i9) %e+1,numer; (%o9) 3.718281828459045 (%i10) sin(%e),numer; (%o10) .4107812905029088 (%i11) (%e+1)^2,numer; (%o11) 13.82561975584874 When we cut out %enumer, the flag %numer would be more consistent with the results of he flag bfloat and the functions float and bfloat, too. The testsuite and the share_testsuite would have no problem. Is there a reason not to cut out the flag %enumer? Dieter Kaiser  Comment By: Stavros Macrakis (macrakis) Date: 20080127 20:22 Message: Logged In: YES user_id=588346 Originator: YES What is by design is that %e^x,numer does not become 2.718^x (unless %enumer is true). The other cases are because the original coder either didn't care about cases like %e+1 or thought it would be too computationally expensive to handle them differently, since they can't be handled bottomup. After all, all of %e^2, %e^%pi, %e^(2/3) with ,numer *do* evaluate to floats. If we fix %e+1,numer we should also fix sin(%pi+x),numer. Currently, that gives sin(3.14+x); it should give sin(x) (that is, the %pi should not simplify to 3.14; the regular simplifier should take over). There is a special hack so that *at the top level*, %e,numer => 2.718. This is really ugly: %e,numer => 2.7 %e+1,numer => %e+1 [%e],numer => [%e] The correct intuition is this: with numer=true, if simplifying a constant (like %e or %pi or for that matter %i and inf) to a float would cause the expression it is contained in (and not just the constant itself) to become a float/complex float, then do it. Otherwise don't. For the purposes of this definition, consider that a toplevel constant is "contained in" some sort of expression. This design would give numer:true %e^x => %e^x sin(%pi+x) => sin(x) inf => <<IEEE positive infinity>> but of course we don't currently handle that %e^2 => 7.4 2^%e => 6.6 atan(1) => .78 atan(inf) => 1.57 sin(2/3*%pi + x) => sin(x+2.1) %e^%i => .5+.8*%i %i^%i => .27 sin(1+%pi) => 0.84 I don't think we can easily fix all these cases, but we should start. The current behavior is incoherent and not very useful.  Comment By: Robert Dodier (robert_dodier) Date: 20080127 20:01 Message: Logged In: YES user_id=501686 Originator: NO I'm pretty sure we should change the behavior of %e in the presence of numer, whether or not the current behavior is intentional. Reopening this report accordingly. I've been bitten by this inconsistency repeatedly. %e, numer; => 2.718281828459045 %e + 1, numer; => %e + 1 %e^%pi, numer; => 23.14069263277927 %e^%e, numer; => %e^%e Preserving %e in %e^foo, numer when foo is nonnumeric is OK by me. I suppose that's the original intent of %enumer but for whatever reason it is not the sole effect.  Comment By: Dan Gildea (dgildea) Date: 20080127 19:26 Message: Logged In: YES user_id=1797506 Originator: NO This seems to be by design. (%i5) %e^%e,numer,%enumer; (%o5) 15.15426224147926 (%i6) %e^%e,numer; (%o6) %e^%e (%i7) %e+1,numer,%enumer; (%o7) 3.718281828459045 (%i8) %e+1,numer; (%o8) %e+1  Comment By: Robert Dodier (robert_dodier) Date: 20060626 20:17 Message: Logged In: YES user_id=501686 Still present in 5.9.3.  Comment By: Stavros Macrakis (macrakis) Date: 20040323 18:48 Message: Logged In: YES user_id=588346 cf. bug 531466 re float(exp(exp(2)))  Comment By: Stavros Macrakis (macrakis) Date: 20020919 05:12 Message: Logged In: YES user_id=588346 1+%e,numer also fails These examples work with bfloat, e.g. 1+%e,bfloat; %e^%e,bfloat;  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=609464&group_id=4933 
From: SourceForge.net <noreply@so...>  20090513 20:58:52

Bugs item #2791106, was opened at 20090513 12:37 Message generated for change (Comment added) made by hlitzroth You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2791106&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  Assume Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: forget(a : 0) does not work Initial Comment: I did use wxMaxima 0.8.2 with Maxima version: 5.18.1. The interactions with (wx)Maxima given in the attached file ProblemWithforget.wxm show that "forget(a > 0)" after "assume(a > 0)" works well, but "forget(a : 0)" after "assume(a : 0)" does not work, and that in such case we have to use "kill(a)" in order to make Maxima forget about the predicate "a : 0". I do not know if that is a bug, but at first sight it is not very elegant.  Comment By: Harry Litzroth (hlitzroth) Date: 20090513 22:58 Message: Sender of this problem: ilitzroth  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2791106&group_id=4933 
From: SourceForge.net <noreply@so...>  20090513 20:55:03

Bugs item #2789110, was opened at 20090508 18:40 Message generated for change (Comment added) made by hlitzroth You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2789110&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, tan and atan depend on order of variables Initial Comment: solve(tan(x  atan(c1/c2)) = 0, x); returns [x=atan(c1/c2)] corretly, but solve(tan(x  atan(c2/c1)) = 0, x); returns [ ].  Maxima version: 5.18.1 Maxima build date: 14:34 4/18/2009 host type: i686appledarwin8.11.1 lispimplementationtype: CMU Common Lisp lispimplementationversion: 19f (19F)   Comment By: Harry Litzroth (hlitzroth) Date: 20090513 22:55 Message: I use wxMaxima 0.8.2 with Maxima 5.18.1. The same problem exists with vg1 : tan(x  atan(y/z))= 0; solve(vg1, x); giving the solution tan(atan(y/z)x)=0, and vg2 : tan(x  atan(z/y)) = 0; solve(vg2, x); giving no solution at all.  Comment By: Nobody/Anonymous (nobody) Date: 20090512 07:58 Message: Both give the same result: []  Maxima version: 5.18.1 Maxima build date: 20:57 4/19/2009 host type: i686pcmingw32 lispimplementationtype: GNU Common Lisp (GCL) lispimplementationversion: GCL 2.6.8   You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2789110&group_id=4933 
From: SourceForge.net <noreply@so...>  20090513 13:26:26

Bugs item #2787476, was opened at 20090505 21:41 Message generated for change (Comment added) made by zigalenarcic You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2787476&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: Žiga Lenarčič (zigalenarcic) Assigned to: Nobody/Anonymous (nobody) Summary: 'diff() inconsistent Initial Comment: 'diff(x*y,x) gives the correct result (holds form), while 'diff(x,x) gives 1, calculates the differencial.  >Comment By: Žiga Lenarčič (zigalenarcic) Date: 20090513 15:26 Message: Problem is in quoted diff, which should not evaluate, but it does in 'diff(x,x) case: (%i2) 'diff(x*y,x); d (%o2)  (x y) dx (%i3) 'diff(x,x); (%o3) 1 (%i4) 'diff(2*x,x); d (%o4)  (2 x) dx  Comment By: Nobody/Anonymous (nobody) Date: 20090513 13:27 Message: I may be stupid or blind, but I do not see the problem here. Would you like to see diff(x*x,x) resulting in x rather than 2x? May be your remark is more subtle than this.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2787476&group_id=4933 
From: SourceForge.net <noreply@so...>  20090513 11:58:32

Bugs item #2791141, was opened at 20090513 11:58 Message generated for change (Tracker Item Submitted) made by nobody You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2791141&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: Problem with "copy as image" Initial Comment: In wxMaxima 0.8.2, "copy as image" and also "export as HTML" do not work properly when the following expression is entered. The image is trunctated / badly formated H : (R*(k2*rd^2*z^2*R2*k2*rd*z^2*R+k2*z^2*R2*k2*rd^2*z*R+2*k2*rd*z*R+k2*z*R+k2*rd^2*R+k2*rd*z^22*k1*rd*z^2k2*z^2+2*k1*z^22*k2*rd*z+4*k1*rd*z+k2*z2*k1*z+k2*rd2*k1*rd))/(2*(z1)^2*z)  Maxima version: 5.18.1 Maxima build date: 20:57 4/19/2009 host type: i686pcmingw32 lispimplementationtype: GNU Common Lisp (GCL) lispimplementationversion: GCL 2.6.8   You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2791141&group_id=4933 
From: SourceForge.net <noreply@so...>  20090513 11:38:55

Bugs item #2790984, was opened at 20090513 01:55 Message generated for change (Comment added) made by nobody You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2790984&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: Pending Resolution: Invalid Priority: 5 Private: No Submitted By: caprilo (caprilo) Assigned to: Nobody/Anonymous (nobody) Summary: problem with sqrt(abx^2) calculus Initial Comment: The function integrate(sqrt(abx^2), x); returns sqrt(abx^2)*x which is obviously wrong. Worse is that, the differentiation of the wrong integral, diff(sqrt(abx^2)*x, x); returns the integrand!: sqrt(abx^2)  Maxima version: 5.13.0 Maxima build date: 9:20 12/12/2007 host type: i686pclinuxgnu lispimplementationtype: GNU Common Lisp (GCL) lispimplementationversion: GCL 2.6.8   Comment By: Nobody/Anonymous (nobody) Date: 20090513 11:38 Message: Input notation is different from output in mathematical notation as provided by Maxima. rtoy did give the right answer and the worse was for the better, namely that Maxima returned the function when differentiating the integral of the function.  Comment By: Raymond Toy (rtoy) Date: 20090513 03:48 Message: bx^2 is not the same as b*x^2, so you've basically integrated y wrt to x, which is y*x. Same with your differentiation. Marking this as pending/invalid. If this analysis is incorrect, please comment.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2790984&group_id=4933 
From: SourceForge.net <noreply@so...>  20090513 11:28:03

Bugs item #2787476, was opened at 20090505 19:41 Message generated for change (Comment added) made by nobody You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2787476&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: Žiga Lenarčič (zigalenarcic) Assigned to: Nobody/Anonymous (nobody) Summary: 'diff() inconsistent Initial Comment: 'diff(x*y,x) gives the correct result (holds form), while 'diff(x,x) gives 1, calculates the differencial.  Comment By: Nobody/Anonymous (nobody) Date: 20090513 11:27 Message: I may be stupid or blind, but I do not see the problem here. Would you like to see diff(x*x,x) resulting in x rather than 2x? May be your remark is more subtle than this.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2787476&group_id=4933 
From: SourceForge.net <noreply@so...>  20090513 10:37:16

Bugs item #2791106, was opened at 20090513 10:37 Message generated for change (Tracker Item Submitted) made by nobody You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2791106&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  Assume Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: forget(a : 0) does not work Initial Comment: I did use wxMaxima 0.8.2 with Maxima version: 5.18.1. The interactions with (wx)Maxima given in the attached file ProblemWithforget.wxm show that "forget(a > 0)" after "assume(a > 0)" works well, but "forget(a : 0)" after "assume(a : 0)" does not work, and that in such case we have to use "kill(a)" in order to make Maxima forget about the predicate "a : 0". I do not know if that is a bug, but at first sight it is not very elegant.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2791106&group_id=4933 
From: SourceForge.net <noreply@so...>  20090513 04:05:19

Bugs item #2787731, was opened at 20090506 04:45 Message generated for change (Comment added) made by rtoy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2787731&group_id=4933 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Share Libraries Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Leo Butler (l_butler) Assigned to: Nobody/Anonymous (nobody) Summary: bfloat and fast_linsolve Initial Comment: fast_linsolve appears to induce an error in bfloat. In the following example, I have generated a system of 3 equations in 3 unknowns, using random_normal and then copied the equations into a new maxima session. If I generate the equation with rational coefficients, the problem with bfloat does not appear. Leo (%i1) load(affine)$ (%o1) /knoppixhome/work/maxima/maxima5.18.1clisp/share/affine/affine.lisp (%i2) N:3$ (%i3) ratprint : false $ (%i4) display2d : false $ (%i5) vars : [x1,x2,x3,x4,x5,x6,x7,x8,x9]; (%o5) [x1,x2,x3,x4,x5,x6,x7,x8,x9] (%i6) vars : makelist(vars[i],i,1,N); (%o6) [x1,x2,x3] (%i7) eqs : [.3016867735556204*x3+0.72571622462782*x21.356103197667722*x1+.8097310690789437,.7266416629867314*x3+2.044906173976214*x2+.3050130725707205*x12.21490043156295\ 5,1.373955385382003*x3+0.870470342665541*x2.1400633135540639*x15.72274352792303]; (%o7) [.3016867735556204*x3+0.72571622462782*x21.356103197667722*x1 +.8097310690789437, .7266416629867314*x3+2.044906173976214*x2+.3050130725707205*x1 2.214900431562955, 1.373955385382003*x3+0.870470342665541*x2.1400633135540639*x1 5.72274352792303] (%i8) c : fast_linsolve(eqs,vars); Assuming entries of type RATIONAL Starting to solve. There are 3 equations with 3 unknowns occurring. The value of (SPTYPEOFENTRIES SPMAT) is RATIONAL The dimension of the solution space is 0 (%o8) [x1 = 6522146832687777887933823112930132311534275/6522146947750503519933454547573985969900408, x2 = 13114236422380406502546291152660248369888/6557118245057476729155617842735240586361, x3 = 8385617526296745497667567886859621652613375/2795205834750215794257194806103136844243032] (%i9) bfloat(%); Maxima encountered a Lisp error: INTEGERLENGTH: 6522146832687777887933823112930132311534275/6522146947750503519933454547573985969900408 is not an integer Automatically continuing. To reenable the Lisp debugger set *debuggerhook* to nil. (%i10) quit(); <comment>Copy the solution into new maxima session and observe bfloat works</comment> $ maxima5.18.1clisp Maxima 5.18.1 http://maxima.sourceforge.net Using Lisp CLISP 2.44.1 (20080223) 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) [x1 = 6522146832687777887933823112930132311534275/6522146947750503519933454547573985969900408, x2 = 13114236422380406502546291152660248369888/6557118245057476729155617842735240586361, x3 = 8385617526296745497667567886859621652613375/2795205834750215794257194806103136844243032]; 6522146832687777887933823112930132311534275 (%o1) [x1 = , 6522146947750503519933454547573985969900408 13114236422380406502546291152660248369888 x2 = , 6557118245057476729155617842735240586361 8385617526296745497667567886859621652613375 x3 = ] 2795205834750215794257194806103136844243032 (%i2) bfloat(%); (%o2) [x1 = 9.999999823581519b1, x2 = 1.999999989670074b0, x3 = 3.000000007887111b0]  >Comment By: Raymond Toy (rtoy) Date: 20090513 00:05 Message: I can reproduce this issue. It looks like a bug in fast_linsolve. If you examine %o10, you'll see something like ((mequal simp) $X1 6522.../6522...) This should have been ((mequal simp) $x1 ((rat) 6522... 6522...))  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2787731&group_id=4933 
From: SourceForge.net <noreply@so...>  20090513 03:48:41

Bugs item #2790984, was opened at 20090512 21:55 Message generated for change (Comment added) made by rtoy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2790984&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: Pending >Resolution: Invalid Priority: 5 Private: No Submitted By: caprilo (caprilo) Assigned to: Nobody/Anonymous (nobody) Summary: problem with sqrt(abx^2) calculus Initial Comment: The function integrate(sqrt(abx^2), x); returns sqrt(abx^2)*x which is obviously wrong. Worse is that, the differentiation of the wrong integral, diff(sqrt(abx^2)*x, x); returns the integrand!: sqrt(abx^2)  Maxima version: 5.13.0 Maxima build date: 9:20 12/12/2007 host type: i686pclinuxgnu lispimplementationtype: GNU Common Lisp (GCL) lispimplementationversion: GCL 2.6.8   >Comment By: Raymond Toy (rtoy) Date: 20090512 23:48 Message: bx^2 is not the same as b*x^2, so you've basically integrated y wrt to x, which is y*x. Same with your differentiation. Marking this as pending/invalid. If this analysis is incorrect, please comment.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2790984&group_id=4933 
From: SourceForge.net <noreply@so...>  20090513 02:00:52

Bugs item #2790984, was opened at 20090512 20:55 Message generated for change (Tracker Item Submitted) made by caprilo You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2790984&group_id=4933 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Lisp Core  Integration Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: caprilo (caprilo) Assigned to: Nobody/Anonymous (nobody) Summary: problem with sqrt(abx^2) calculus Initial Comment: The function integrate(sqrt(abx^2), x); returns sqrt(abx^2)*x which is obviously wrong. Worse is that, the differentiation of the wrong integral, diff(sqrt(abx^2)*x, x); returns the integrand!: sqrt(abx^2)  Maxima version: 5.13.0 Maxima build date: 9:20 12/12/2007 host type: i686pclinuxgnu lispimplementationtype: GNU Common Lisp (GCL) lispimplementationversion: GCL 2.6.8   You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2790984&group_id=4933 