On Tue, Oct 18, 2011 at 10:32, Panagiotis Papasotiriou <
p.j.papasot at gmail.com> wrote:
> 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.
First of all, "dummy variable" is not a concept in Maxima or Lisp. This may
be a Fortran usage, since Fortran has call-by-reference (assigning to a
parameter in a subroutine changes the value of the *argument* in the
caller). Maxima and Lisp have call-by-object-value, so a function parameter
is really just a local variable initialized to the argument value. You can
mode_declare both parameters and local variables.
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]);
>
Hmm. You seem to be trying to treat mode_declare as an executable
statement, which it is not. The above 'for/mode_declare' construction has no
effect on anything. It simply loops through the elements of z and the body
of the loop consists only of a declaration of the variable el, which is
local to the loop; there are no executable statements.
The trick is to refer to the elements of z ***within*** that loop, as el,
which is declared as a float. That is what my code below does.
-s
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
>>>
>>>
>>
>
> _______________________________________________
> Maxima mailing list
> Maxima at math.utexas.edu
> http://www.math.utexas.edu/mailman/listinfo/maxima
>
>