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...>  20090506 22:47:14

Bugs item #1986726, was opened at 20080606 14:22 Message generated for change (Comment added) made by dgildea You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1986726&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: Closed >Resolution: Fixed Priority: 7 Private: No Submitted By: Nathan Powell (npowell) Assigned to: Nobody/Anonymous (nobody) Summary: Integrating f(x) with limits after resetting throws an error Initial Comment: /*wxMaxima 0.7.5 http://wxmaxima.sourceforge.netMaxima 5.15.0 http://maxima.sourceforge.netUsing Lisp GNU Common Lisp (GCL) GCL 2.6.8 (aka GCL)Distributed under the GNU Public License. See the file COPYING.Dedicated to the memory of William Schelter.The function bug_report() provides bug reporting information. (%i1) integrate(f(x),x,a,b); (%o1) integrate(f(x),x,a,b) (%i2) reset(); (%o1) [lispdisp,linenum,%,current,trunique,rhs,lhs,nobjects,+labs,algdelta,_,__,context] (%i2) integrate(f(x),x,a,b); Maxima encountered a Lisp error: Error in MACSYMATOPLEVEL [or a callee]: NIL is not of type INTEGER.Automatically continuing.To reenable the Lisp debugger set *debuggerhook* to nil. (%i3) This happens if both versions 5.15 and 5.14 The reason this is important to me is that I'm writing a program which needs to call reset() a lot between calculations (so that the calculations don't have the possibility of interferring with each other). Thanks!  >Comment By: Dan Gildea (dgildea) Date: 20090506 18:47 Message: Fixed in db.lisp rev 1.20.  Comment By: Dieter Kaiser (crategus) Date: 20090406 13:41 Message: I think, the error occurs because the database is confused after a reset() (I am using Maxima 5.18post). This is the context and the value of the internal variable +labs after starting Maxima on my system: (%i3) context; (%o3) initial (%i4) :lisp +labs ($BETA) This is the example of this bug report: (%i3) integrate(f(x),x,a,b); (%o3) 'integrate(f(x),x,a,b) (%i4) reset(); (%o1) [+labs, %, algdelta, context, trunique, lispdisp, linenum, rhs, lhs, current, display2d, mopl, *nobjects*, _, __] The context seems to be right, but +labs is reset to NIL: (%i4) context; (%o4) initial (%i5) :lisp +labs NIL A call to kindp now generates the reported error (this call to kindp happens in the first call to $imagpart in the routine defint): (%i5) :lisp (kindp '$a '$complex) Maxima encountered a Lisp error: Error in KINDP [or a callee]: NIL is not of type INTEGER. Automatically continuing. To reenable the Lisp debugger set *debuggerhook* to nil. I think there are a lot of strange things which can happen when we use a reset(). This is a further example which causes no Lisp error but strange effects: We have started a fresh Maxima: (%i4) declare(x,complex)$ (%i5) facts(); (%o5) [kind(x,complex)] (%i6) :lisp (kindp '$x '$complex) T Now we do the reset(): (%i6) reset(); (%o1) [+labs, %, algdelta, context, trunique, lispdisp, linenum, current, display2d, mopl, *nobjects*, _, __] Again +labs is set to NIL: (%i2) context; (%o2) initial (%i4) :lisp +labs NIL If we do a kindp all seems to be okay: (%i4) :lisp (kindp '$x '$complex) NIL But the fact is still present for the user: (%i4) facts(); (%o4) [kind(x,complex)] We try to declare a second variable to be complex, but it is no longer possible to do it. (%i5) declare(y,complex); (%o5) done (%i6) facts(); (%o6) [kind(x,complex)] (%i7) :lisp (kindp '$y '$complex) NIL I have tried some more examples. We get a lot of different behaviors and errors after a reset(). I have not observed problems, when we change the declarations of the database variables to defvar's and perhaps it is the best to do no reset on global variables of the database at all. Changing the category to Lisp Core  Assume, because it is not a problem of the integration routines, but of the assume database. Dieter Kaiser  Comment By: Robert Dodier (robert_dodier) Date: 20080606 20:44 Message: Logged In: YES user_id=501686 Originator: NO Nathan, thanks for letting us know about this bug. I will take a look at it. reset acts on option variables and some other variables to set their values back to what they were originally. If you want to reset some option variables, you can specify those to reset e.g. reset(foo, bar) instead of reset() . (My guess is that some internal variable is being reset which should not be.) However, I wonder if reset is really the function you want. Maybe kill is what you want  kill acts on user variables. See ? kill and ? reset for more info.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1986726&group_id=4933 
From: SourceForge.net <noreply@so...>  20090506 22:46:42

Bugs item #2787047, was opened at 20090505 02:30 Message generated for change (Comment added) made by dgildea You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2787047&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: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Stefano Ferri (stefano_ferri) Assigned to: Nobody/Anonymous (nobody) Summary: Assume has problems after a reset() Initial Comment: In Maxima 5.18.1 (versions <=5.17.1 are not affected) there is a problem using assume after a reset(). Example: (%i1) assume(a>0); (%o1) [a > 0] (%i2) reset(); (%o1) [algdelta, nobjects, +labs, current, context, lispdisp, display2d, trunique, linenum, %, mopl, __, _] (%i2) assume(a>0); Maxima encountered a Lisp error: CAR: $ZERO is not a list Automatically continuing. To reenable the Lisp debugger set *debuggerhook* to nil. This happens only if, after reset(), one makes an assumption aver a variable that was previously in facts database, "a" in this example. Doing assume(b>0) still works.  >Comment By: Dan Gildea (dgildea) Date: 20090506 18:46 Message: Fixed in db.lisp rev 1.20  +labs no longer reset by reset(). (%i1) display2d:false; (%o1) false (%i2) assume(a>0); (%o2) [a > 0] (%i3) sign(a); (%o3) pos (%i4) facts(a); (%o4) [a > 0] (%i5) facts(); (%o5) [a > 0] (%i6) reset(); (%o1) [_, __, mopl, %, linenum, trunique, display2d, lispdisp, context, current, *nobjects*, algdelta] (%i2) sign(a); (%o2) pnz (%i3) facts(a); (%o3) [a > 0] (%i4) facts(); (%o4) [a > 0] (%i5) kill(all); (%o0) done (%i1) sign(a); (%o1) pnz (%i2) facts(a); (%o2) [] (%i3) facts(); (%o3) [] (%i4) assume(a>0); (%o4) [a > 0]  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2787047&group_id=4933 
From: SourceForge.net <noreply@so...>  20090506 21:42:56

Bugs item #1238141, was opened at 20050714 13:35 Message generated for change (Comment added) made by crategus You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1238141&group_id=4933 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Lisp Core  Complex Group: None >Status: Closed >Resolution: Fixed Priority: 7 Private: No Submitted By: Barton Willis (willisbl) Assigned to: Nobody/Anonymous (nobody) Summary: realpart(f(x+%i*y)) Initial Comment: Maxima seems to believe that all unknown functions are realvalued. This holds even when the argument is manifestly complex. (%i1) realpart((x+%i*y)); (%o1) x (%i2) realpart(f(x+%i*y)); (%o2) f(%i*y+x) I think it would be best if Maxima returned a noun form in this case. Simarly, realpart(f(x)) should return a noun form, unless f has somehow been declared realvalued. Barton  >Comment By: Dieter Kaiser (crategus) Date: 20090506 23:42 Message: The standard behavior is changed. Now Maxima gets for an unknown function: (%i22) rectform(f(x)); (%o22) realpart(f(x))+%i*imagpart(f(x)) And for the example above: (%i1) realpart(f(x+%i*y)); (%o1) realpart(f(%i*y+x)) Closing this bug report as fixed. Dieter Kaiser  Comment By: Robert Dodier (robert_dodier) Date: 20060812 18:54 Message: Logged In: YES user_id=501686 Observed in 5.9.3cvs.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1238141&group_id=4933 
From: SourceForge.net <noreply@so...>  20090506 21:38:35

Bugs item #1045531, was opened at 20041012 17:47 Message generated for change (Comment added) made by crategus You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1045531&group_id=4933 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Lisp Core  Complex Group: None >Status: Closed Resolution: Fixed Priority: 6 Private: No Submitted By: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: real/imagpart don't know about conjugate Initial Comment: realpart('conjugate(x)) => 'conjugate(x) imagpart('conjugate(x)) => 0 should be realpart(x) and imagpart(x) What is really going on is that rpart (realpart, imagpart, etc.) don't even know conjugate exists, which is not surprising, since it is in a load package (eigen). Worse, there is no way to extend realpart/imagpart to new functions at the Maxima or the Lisp level. s  >Comment By: Dieter Kaiser (crategus) Date: 20090506 23:38 Message: Change status to closed.  Comment By: Dieter Kaiser (crategus) Date: 20090506 23:37 Message: Suggested extension is commited. Closing this bug report as fixed. Dieter Kaiser  Comment By: Dieter Kaiser (crategus) Date: 20090504 23:42 Message: This would be a small extension to the routine risplit in rpart.lisp which give the expected simplifications for the realpart and imagpart of an expression with conjugate: ((eq (caar l) '$conjugate) (cons (simplify (list '(%realpart) (cadr l))) (mul 1 (simplify (list '(%imagpart) (cadr l)))))) With this extension we get: (%i31) declare(z,complex)$ This is the example of this bug report: (%i32) realpart(conjugate(z)); (%o32) 'realpart(z) (%i33) imagpart(conjugate(z)); (%o33) 'imagpart(z) It would work for complex functions too: (%i38) realpart(conjugate(sin(z))); (%o38) cosh('imagpart(z))*sin('realpart(z)) (%i39) imagpart(conjugate(sin(z))); (%o39) sinh('imagpart(z))*cos('realpart(z)) The testsuite has no problems with this extension. If there is no further comment, I would like to commit this extension. Dieter Kaiser  Comment By: Robert Dodier (robert_dodier) Date: 20060731 06:14 Message: Logged In: YES user_id=501686 Observed in 5.9.3cvs. There has been very recent (last 2 days) work on src/conjugate.lisp, so maybe that stuff just needs some adjustment. (The definition in share/../eigen.mac is superseded by src/conjugate.lisp.)  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1045531&group_id=4933 
From: SourceForge.net <noreply@so...>  20090506 21:37:43

Bugs item #1045531, was opened at 20041012 17:47 Message generated for change (Comment added) made by crategus You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1045531&group_id=4933 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Lisp Core  Complex Group: None Status: Open >Resolution: Fixed Priority: 6 Private: No Submitted By: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: real/imagpart don't know about conjugate Initial Comment: realpart('conjugate(x)) => 'conjugate(x) imagpart('conjugate(x)) => 0 should be realpart(x) and imagpart(x) What is really going on is that rpart (realpart, imagpart, etc.) don't even know conjugate exists, which is not surprising, since it is in a load package (eigen). Worse, there is no way to extend realpart/imagpart to new functions at the Maxima or the Lisp level. s  >Comment By: Dieter Kaiser (crategus) Date: 20090506 23:37 Message: Suggested extension is commited. Closing this bug report as fixed. Dieter Kaiser  Comment By: Dieter Kaiser (crategus) Date: 20090504 23:42 Message: This would be a small extension to the routine risplit in rpart.lisp which give the expected simplifications for the realpart and imagpart of an expression with conjugate: ((eq (caar l) '$conjugate) (cons (simplify (list '(%realpart) (cadr l))) (mul 1 (simplify (list '(%imagpart) (cadr l)))))) With this extension we get: (%i31) declare(z,complex)$ This is the example of this bug report: (%i32) realpart(conjugate(z)); (%o32) 'realpart(z) (%i33) imagpart(conjugate(z)); (%o33) 'imagpart(z) It would work for complex functions too: (%i38) realpart(conjugate(sin(z))); (%o38) cosh('imagpart(z))*sin('realpart(z)) (%i39) imagpart(conjugate(sin(z))); (%o39) sinh('imagpart(z))*cos('realpart(z)) The testsuite has no problems with this extension. If there is no further comment, I would like to commit this extension. Dieter Kaiser  Comment By: Robert Dodier (robert_dodier) Date: 20060731 06:14 Message: Logged In: YES user_id=501686 Observed in 5.9.3cvs. There has been very recent (last 2 days) work on src/conjugate.lisp, so maybe that stuff just needs some adjustment. (The definition in share/../eigen.mac is superseded by src/conjugate.lisp.)  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1045531&group_id=4933 
From: SourceForge.net <noreply@so...>  20090506 09:04:15

Bugs item #2787735, was opened at 20090506 10:04 Message generated for change (Tracker Item Submitted) made by l_butler You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2787735&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: polynomialp in affine and linearalgebra Initial Comment: Both affine and linearalgebra packages define `polynomialp' and these are incompatible. (%i2) load(affine)$ 0 errors, 0 warnings (%i3) ratprint : false $ (%i4) display2d : false $ (%i5) vars : [x1,x2,x3]; (%o5) [x1,x2,x3] (%i6) eqs : [x3/3+x2/2+x13,x3/4+x2/3+x1/223/12,x3/5+x2/4+x1/343/30]; (%o6) [x3/3+x2/2+x13,x3/4+x2/3+x1/223/12,x3/5+x2/4+x1/343/30] (%i7) solve(eqs,vars); (%o7) [[x1 = 1,x2 = 2,x3 = 3]] (%i8) linsolve(eqs,vars); (%o8) [x1 = 1,x2 = 2,x3 = 3] (%i9) 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 (%o9) [x1 = 1,x2 = 2,x3 = 3] <comment>fast_linsolve works fine; now call in a linearalgebra function</comment> (%i10) A : hilbert_matrix(3)$ WARNING: DEFUN/DEFMACRO: redefining function POLYNOMIALP in /knoppixhome/work/maxima/maxima5.18.1clisp/share/linearalgebra/polynomialp.lisp, was defined in /knoppixhome/work/maxima/maxima5.18.1clisp/binary/binaryclisp/share/affine/polybas.fas 0 errors, 0 warnings (%i11) fast_linsolve(eqs,vars); Maxima encountered a Lisp error: EVAL/APPLY: too few arguments given to POLYNOMIALP Automatically continuing. To reenable the Lisp debugger set *debuggerhook* to nil. (%i12) build_info(); Maxima version: 5.18.1 Maxima build date: 12:38 4/26/2009 host type: i686pclinuxgnu lispimplementationtype: CLISP lispimplementationversion: 2.44.1 (20080223) (built 3427349244) (memory 3449734722)  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2787735&group_id=4933 
From: SourceForge.net <noreply@so...>  20090506 08:45:12

Bugs item #2787731, was opened at 20090506 09:45 Message generated for change (Tracker Item Submitted) made by l_butler 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]  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2787731&group_id=4933 