On Sep 2, 2009, at 9:03 PM, Stavros Macrakis wrote:
>
> risplit is the general routine for arbitrary symbolic expressions.
>
> There is a much faster routine for deconstructing a complex number:
> complex-number-p in ellipt.lisp. The current version of that
> function doesn't extract the real and imaginary parts, but it could
> easily be modified to do so.
>
> The function complexify in the same file converts a Lisp number
> (real or complex) to a Maxima number. I think it would be
> perfectly legitimate to explicitly construct the simplified Maxima
> expression here, though it does mean that some simplifications
> would be duplicated (implicitly) here and in the general
> simplifier; in particular, pattern-matching simplification would be
> cut out of the logic.
>
> There is probably a more logical place to put complex-number-p and
> complexify than in ellipt.lisp....
>
> -s
>
Thanks for pointing this out. Using a simpler function instead of
risplit, fft is almost 2x faster.
Complexify uses add and mul (with some additional unneeded error
check), so no difference there.
What's I think is important is to ensure fft is compiled on Windows
(with GCL) on load. Lapack uses the 'mk' system, but perhaps we could
have something lighter in Maxima for that purpose. I don't know much
about GCL.. on CMUCL or Clozure CL it would be probably OK to just write
(defun .... )
(compile *)
so the functions are compiled on every 'load', because there is not a
lot of code, but GCL (since it's C based AFAIK) be slow with such ad
hoc compilation... fasls are the best way to go, but using 'mk' is an
overkill for small chunks of code. Again, a Maxima specific tool
perhaps?
Also I would mind moving more things into 'src' (or precompiled image
one way or another), diskspace and memory is cheap these days
(compared to year 2000).
Regards,
Ziga