The problem is that I need to declare local variables as lists of floats. In
your example, you define l as a list of floats, but l is a dummy variable,
not a local variable. Nevertheless, I tried to do something similar in my
code. To make things simple, declarations look like in the following simple
example:
f(y):=block([z],mode_declare(z,list),for el in z do
mode_declare(el,float),z:y);
translate(f);
f([1,2,3]);
Here, z is a local variable, and I define each element of z as a float.
However, I still need to declare z itself as a list, otherwise I get errors.
And I am actually not sure if declaring each element of z has any effect in
translation, after declaring z itself. here is why:
I modified the code in rkf45_transformed in a similar way (all local
variables are declared as lists, then each element is declared as float.)
The translated code runs without errors now, but computation time is almost
the same as if I declared each local variable as a list, without defining
their element as floats. It seems to me that, after declaring a local
variable as a list, declaring its elements as floats has no effect. To
confirm that, please run Test.mac and tell me if there is any difference in
execution time between rkf45 and rkf45_translated. In my system, I get the
following output:
(%i7) sol_stiff:rkf45(y^2-y^3,y,d,[x,x_start,x_end],max_iterations=40000)$
Evaluation took 30.7200 seconds (30.7300 elapsed)
(%i10)
sol_stiff:rkf45_translated(odes,y,d,[x,x_start,x_end],max_iterations=40000)$
Evaluation took 30.9600 seconds (31.2300 elapsed)
So, non-translated code needs ~30.7 seconds to solve the problem, while
translated code needs ~31 seconds.
All necessary files to do the test are in:
https://sites.google.com/site/pjpapasot/maxima/temporary
(these are updated versions of previously uploaded files.)
2011/10/18 Stavros Macrakis <macrakis at alum.mit.edu>
> I don't think you can declare something to be a "list of floats". But you
> can handle each element with a float variable, e.g.
>
> f(l,k):= block([s], mode_declare([s],float,[k],integer), for li in l do
> (mode_declare([li],float), s:s+li^k), s);
>
> Do you see how you'd do that in your case?
>
> -s
>
>
> On Tue, Oct 18, 2011 at 08:21, Panagiotis Papasotiriou <
> p.j.papasot at gmail.com> wrote:
>
>> Stavro,
>>
>> k1 is actually a list of one (float) element in this particular example
>> (in the general case, when solving a system of differential equations, k1
>> would have more than one elements.) So the question is, how can I
>> mode_declare a list of floats so that it will work as expected when the code
>> is translated?
>>
>> thank you for helping
>>
>> 2011/10/18 Stavros Macrakis <macrakis at alum.mit.edu>
>>
>>> The error message is showing that k1 is a list containing one number, not
>>> a number. Is that enough information to help you debug?
>>>
>>> Thanks for your work on improving and extending Maxima's numerical
>>> capabilities!
>>>
>>> -s
>>> On Oct 18, 2011 7:54 AM, "Panagiotis Papasotiriou" <
>>> p.j.papasot at gmail.com> wrote:
>>>
>>>> Could you please replace rkf45_translated.mac with that one:
>>>>
>>>>
>>>> https://sites.google.com/site/pjpapasot/maxima/temporary/rkf45_translated.mac?attredirects=0&d=1
>>>>
>>>> and run Test.mac again? In that version of rkf45_translated, most local
>>>> variables are declared as "float" instead of "any" (which is correct.)
>>>> However, in my system that gives the following error when I run Test.mac:
>>>>
>>>> Maxima encountered a Lisp error:
>>>> Error in * [or a callee]: ((MLIST SIMP) 1.9999800000000002E-7) is not
>>>> of type NUMBER.
>>>>
>>>> The error is actually generated at line 113 of the code, which reads:
>>>>
>>>> k2:h*odes(xi+0.25*h,yi+0.25*k1),
>>>>
>>>> here, k1, computed at line 112, is 1.9999800000000002E-7 and, for some
>>>> reason, that value is not accepted as a number, hence the error. I am
>>>> curious to know if you get the same error.
>>>>
>>>> 2011/10/18 Michel Talon <talon at lpthe.jussieu.fr>
>>>>
>>>>> Panagiotis Papasotiriou wrote:
>>>>> > Everything is installed from Debian repositories. Maxima version
>>>>> installed
>>>>> > is 5.24, as this is the "official" latest release yet. SBCL is also
>>>>> > installed from the original Debian package, and it it version 1.0.51.
>>>>> >
>>>>>
>>>>> Sure, but i am not so confident that everything in Debian repositories
>>>>> work
>>>>> OK. For example i have seen severely broken mplayer coming from "quasi
>>>>> official" repositories, and i had to recompile it myself. In the
>>>>> present cases
>>>>> i have doubts about sbcl, since you have already seen two problems.
>>>>> Maybe this
>>>>> 64 bits sbcl doesn't work OK, i don't know.
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Michel Talon
>>>>>
>>>>> _______________________________________________
>>>>> Maxima mailing list
>>>>> Maxima at math.utexas.edu
>>>>> http://www.math.utexas.edu/mailman/listinfo/maxima
>>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> Maxima mailing list
>>>> Maxima at math.utexas.edu
>>>> http://www.math.utexas.edu/mailman/listinfo/maxima
>>>>
>>>>
>>
>> _______________________________________________
>> Maxima mailing list
>> Maxima at math.utexas.edu
>> http://www.math.utexas.edu/mailman/listinfo/maxima
>>
>>
>