Stavro,
looks like it is as I guessed... However, I still can't figure out why the
code is not working if I declare variables in the [atol,xi,...x_tiny] block
as "float". It is translated, with several warning messages complaining
about using variables as "any" while they are declared as "float" (this is
not true, but the translator complains about it.) However, the translated
code is not running as expected. So far I failed to figure out why. Note
that I have tested the non-translated code and it works very well. It gives
accurate results even or really difficult initial-value problems..
Given the problems I encountered translating the code, and the fact
execution time for the translated code (reported by Michel Talon) is not
impressive compared to the non-translated code, I am afraid I will need to
quit trying translation of complex algorithms for now, unless someone can
figure out what is happening.
I am planning to implement more numerical methods in Maxima, so that the
user could easily solve the usual set of numerical problems encountered in
practice, such as initial-value problems, boundary-value problems,
cubic-spline interpolation (including calculation of derivatives) and
others. Yes, maxima already has some packages for those tasks, but they are
either not so easy to use or they don't offer much functionality. For
example, Maxima's package for cubic splines, "interpol", only supports
"natural" cubic splines (which are not natural at all, and should be avoided
in most cases), and the interpolating function returned by interpol cannot
be differentiated.
Maxima's primary use is symbolic computations, but let's face it, numerical
solution are more than necessary in practice. That's why most Computer
Algebra Systems support a large set of numerical algorithms as well. Even
the equation of motion for a simple pendulum cannot be solved analytically
without assumptions "simplifying" the problem.
2011/10/17 Stavros Macrakis <macrakis at alum.mit.edu>
> On Sun, Oct 16, 2011 at 18:05, Panagiotis Papasotiriou <
> p.j.papasot at gmail.com> wrote:
>
>> ...either mode_declaring floats as "any" doesn't help at all...
>
>
> Correct, declaring an object as "any" means that Maxima must handle the
> general case of symbolic arithmetic (see below). To get fast numerical
> arithmetic, you need to operate on floats.
>
> General symbolic arithmetic is much slower than numerical arithmetic. See
> the trace below to see how Maxima simplifies 1+2 => 3
>
> -s
>
> f(x):=(modedeclare(x,any),x+1)$
> translate(f)$
> f(z) => z+1
>
> g(x):=(modedeclare(x,float),x+1)$
> translate(g)$
> g(z) =>
> Maxima encountered a Lisp error:
> Error in + [or a callee]: $%PI is not of type NUMBER.
> ----------------------------
> 1> (SIMPLIFYA ((MPLUS) 1 2) NIL)
> 2> (SIMPLUS ((MPLUS) 1 2) 1 NIL)
> 3> (SIMPLIFYA 1 NIL)
> <3 (SIMPLIFYA 1)
> 3> (PLS 1 NIL)
> 4> (MNUMP 1)
> <4 (MNUMP T)
> <3 (PLS ((MPLUS) 1))
> 3> (SIMPLIFYA 2 NIL)
> <3 (SIMPLIFYA 2)
> 3> (PLS 2 ((MPLUS) 1))
> 4> (MNUMP 2)
> <4 (MNUMP T)
> 4> (MNUMP 1)
> <4 (MNUMP T)
> 4> (ADDK 1 2)
> <4 (ADDK 3)
> <3 (PLS ((MPLUS) 3))
> 3> (TESTP ((MPLUS) 3))
> <3 (TESTP 3)
> 3> (EQTEST 3 ((MPLUS) 1 2))
> <3 (EQTEST 3)
> <2 (SIMPLUS 3)
> <1 (SIMPLIFYA 3)
>