Stavros Macrakis wrote:
> It would be nice to have Maxima take advantage of CL rationals, but
> what benefit will that provide to the user except slightly faster
> execution?
The code would be clearer, and we might have a conceptually better model
if we used both rational and complex numbers from common lisp, rather
than re-inventing something slightly different for maxima. There is
still a question as to how to represent a+b*%i so that
3+4*%i can be #c(3 4) in lisp vs.
((mplus) $a ((mtimes) $b #c(0 1))) or some such thing.
Inverting a matrix with bigfloats would probably best be done by
entirely different programs than inverting a matrix with rationals.
Probably the best ways today for bigfloats would have some kind of
iterative refinement, modeled on the floating-point programs in lapack.
Or better might be importing wholesale all the methods in MPFR, using
the underlying (free) code from the GMP package. Maxima's bigfloats have
been around for 20+ years, but in that time other people have taken up
the cause and built some good software. Whether we use or not, these
methods are being used by the competition.
Note that the methods for matrix inversion (etc.) with rationals tend to
be quite different algorithms. The keepfloat:true flag is, in some
ways, destructive of the rational function algorithms. The notion of a
GCD becomes quite different, and is not really supported with
keepfloat:true. (It is OK to do polynomial arithmetic with float
coefficients as long as they do not overflow, and you don't care if the
answer has the wrong coefficients and the wrong degree. To do this with
bigfloats is probably not a big deal -- i.e. add and multiply
polynomials. Division and GCD are problematic, again.).
If we are looking at extending rat to bigfloats, there are a few other
domains, e.g. intervals, complex that might be appealing.
Right now polynomials and rational functions work over any number of
variables,
the integers, modular integers, and algebraic extensions (which could
be used for complex numbers). They also work via ratweight and taylor
on truncated polynomial forms. None of these previous extensions was
done 'painlessly'.
>
> If we're going to go through code that tests numberp etc., I'd think
> it would be more valuable to work on things which improve
> functionality more directly. For example, many routines which work
> with floats do not work with bigfloats. In particular, the whole
> rational function package does not accept bigfloat coefficients,
> though it does accept floating coefficients (using keepfloat:true).
> Other packages, such as matrix inversion and solve, depend on the
> rational function package, so one cannot invert matrices of bigfloats.
> True, one can convert them to rationals first, but that often ends up
> with huge denominator blow-up.
>
> And of course any solution that works for bigfloats should be general
> to allow for other number representations.
Yes, like intervals. But it doesn't come out "free" as a result of
proper data abstraction.
RJF
>
>
> -s
>
> _______________________________________________
> Maxima mailing list
> Maxima at math.utexas.edu
> http://www.math.utexas.edu/mailman/listinfo/maxima