It is strange how Stavros gets translation messages completely different
than what I get.
Anyway, both solutions suggested (the trick with mode declarations in lists,
and the use of arrays instead of lists) seem to work. I had quite some
progress by converting everything in array forms as well. However, I
realized that I will need to replace all list operations with loops, which
is something I honestly don't want to do. It reminds me implementing
numerical methods in languages not appropriate for Mathematics, like C/C++,
where the lack of decent matrix algebra support forces the user to use loops
and nested loops for the simplest thing on Earth. Being a Fortran 90+
programmer for several years, I refuse to come back to a programming style
which reminds me "archaic" Fortran 77 or C/C++. Note that all that trouble
could be avoided if Maxima translator had a way to define lists of floats.
Moreover, if translator allowed dynamic declarations of functions within the
block being translated, I could have the same functionality and convenience
as in the non-translated code.
So, I decided to put my priorities in order: I'll return to "pure" Maxima
programming, at least for now, implementing numerical methods that I think
they need to be added in Maxima. The code will run in non-translated form
for now, but well many packages already existing in maxima/share directory
are actually implemented that way. Besides, it is not that slow. Execution
time for rkf45, for example, needs less than one second for simple problems
and really complex problems (such as the Pleiades problem, which is a system
of 28 differential equations) won't need more than a few seconds to be
solved. The testing example Test.mac I posted before needs much more time to
be solved (30 seconds in my system,) but it is actually a well-known very
stiff problem, and rkf45 is an explicit method, not designed for such kind
of problems, although it can solve them.
I will leave translation for later (maybe someone is planning to improve the
translator?) For now, I return to my .mac packages. Expect a "final" version
of rkf45 soon.
By the way, I also managed to implement a simple numerical method in pure
Lisp, but I will leave that for later as well. Lisp programming seems very
exotic to me, and makes me think "why should I do that, while I could do it
much easier in Fortran 90?". It is still a plan for the future though.
Another possibility is to translate Fortran 90 code using f2cl, but I'm not
sure f2cl can handle complex Fortran 90 structures such as modules, data
hiding via public/private declarations, function interfacing etc.
2011/10/19 Stavros Macrakis <macrakis at alum.mit.edu>
> On Tue, Oct 18, 2011 at 20:24, Michel Talon <talon at lpthe.jussieu.fr>wrote:
>
>> ,,,The compilation gives a number of warnings which are interesting and
>> show that
>> many variables remain of type "any" which means that no real compilation
>> is
>> done....
>>
>> warning: variable atol (declared type float) assigned type any.
>> warning: variable save_steps (declared type boolean) assigned type any.
>>
> ...
>
> These warnings aren't too dire. They mean that you are doing an assignment
> like x:y, where x is declared to be a float, and y is of unknown type (any).
> In effect, you are asserting that you promise that y is *actually* a float
> when you do this. Of course, if your code is doing this everywhere, you
> aren't benefiting from compilation, as Michel says.
>
> -s
>
> _______________________________________________
> Maxima mailing list
> Maxima at math.utexas.edu
> http://www.math.utexas.edu/mailman/listinfo/maxima
>
>