This seems to be a problem with solve(). There are at least two open
bugs in the Maxima tracker system at SourceForge.net that describe
this problem:
--
752417
KEEPFLOAT:TRUE ignored by SOLVE
The documentation for SOLVE and for tools that use
SOLVE (e.g. EIGENVALUES) doesn't state that floating
point numbers are always converted to rational numbers
and that KEEPFLOAT:TRUE is being ignored.
--
752418
Wish: Floats in SOLVE
It would be nice if SOLVE and related functions (e.g.
EIGENVALUES) could work with floating point numbers
(currently it has to convert them to rational numbers).
--
I can force the bfloat conversion of the fineal result, but this
can't avoid the problem with too big intermediate numbers. Moreover,
when matrix values are integer or rational numbers and the obtained
parameters are little rational numbers, a more exact and nice output
is obtained with no bfloat conversion.
You can increase RATEPSILON (with BFTORAT:FALSE) to reduce the
intermediate rational numbers, but this also reduces the precision of
the results. This can avoid the diagnostic about very big numbers.
An alternative is to provide a GuessList to lsquares() in order to
use mnewton() instead of solve(). You can obtain the guesses by
calling lsquares() first with RATEPSILON:2.0E-2 for example.
Best regards,
Salvador
--
On 25 Nov 2003 at 18:13, Valery Pipin wrote:
> Hello,
>
> Many thanks for this very useful contribution.
> I observe one problem when I tried to find an approximation with lsquares.
> Why the numerics is left unevaluated in the following case?
> (C22)
> lsquares(m6,[o,a,dia],dia=k1+ok2*atan(o)/o+ak2*atan(a)/a+k2*atan(o)*atan(a)/(o*a),
> (C22) [k1,ok2,ak2,k2]);
>
> Determination Coefficient = 0.83294990112697
> (D22) dia = (51446713433530427328677360728845969736736885578*ATAN(a)*ATAN(o)
> -455999762562121434746193650304046751931462692880*a*ATAN(o)
> +(1238808364074986242512306422589519959308270339712*a
> -4057697611201546716146647006983806762760711262080*ATAN(a))
> *o)
> /(91095585936884748220570072249110905420450590459571*a*o)
> (C23) expand(bfloat(rhs(%)));
>
> (D23) 5.647552831942384B-4*ATAN(a)*ATAN(o)/(a*o)
> -5.005728410134595B-3*ATAN(o)/o-4.454329558857998B-2*ATAN(a)/a
> +1.359899441157654B-2
>
> Well I can simplify d22 with c23. However, I have a problem when I give the
> approximation in the more complicated form. I obtain the diagnostic like,
> 5144671343353042732869(many numbers) is not a fixnum kind.
>
> best rgds,
> valery
>
>
>