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) /knoppix-home/work/maxima/maxima-5.18.1-clisp/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*x2-1.356103197667722*x1+.8097310690789437,-.7266416629867314*x3+2.044906173976214*x2+.3050130725707205*x1-2.21490043156295\
5,1.373955385382003*x3+0.870470342665541*x2-.1400633135540639*x1-5.72274352792303];
(%o7) [-.3016867735556204*x3+0.72571622462782*x2-1.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 (SP-TYPE-OF-ENTRIES SP-MAT) 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:
INTEGER-LENGTH: 6522146832687777887933823112930132311534275/6522146947750503519933454547573985969900408 is not an integer
Automatically continuing.
To reenable the Lisp debugger set *debugger-hook* to nil.
(%i10) quit();
<comment>Copy the solution into new maxima session and observe bfloat works</comment>
$ maxima-5.18.1-clisp
Maxima 5.18.1 http://maxima.sourceforge.net
Using Lisp CLISP 2.44.1 (2008-02-23)
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.999999823581519b-1, x2 = 1.999999989670074b0,
x3 = 3.000000007887111b0]
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...))