The Maxima computer algebra system

Dennis Darland | 22 Jul 2012 23:32

On Ruby program to generate maxima or maple code to solve differential eq's

I will be testing larger step sizes (again) when I am reasonably sure I have the rest all working correctly. I
have made some improvements (which I think will improve both speed and accuracy), but these must be tested
systematically. I know of some problems I haven't got to yet. I had not implemented them (the
improvements) before as I needed to get the general design working correctly first - which I think I have
done. I still need to retest there also - especially systems of equations. There is also work to do on
estimating poles and making adjustments for them. But you must put the horse before the cart. There is no
rush. I want to be systematic and thorough. I have no deadline. Also I am more interested in the asymptotic
upper bound of the algorithm than how a particular implementation performs.

Though, I suppose, would like a big following, it is not a big deal. One of Bertrand Russell's favorite
quotations from the Bible had to do with not following a multitude to do evil. I don't think traditional
computational scientists are evil, but I still have no reason to follow them, or worry that they are not
following me. I am trying to make whatever I accomplish available through sourceforge. This is just
something I am interested in.

Dennis J. Darland
dennis.darland <at> yahoo.com
http://dennisdarland.com/
http://dennisdarland.com/dennisdaze/
http://dennisdarland.com/philosophy/
http://sode.sourceforge.net/
"According to the World Health Organization, the warming of the planet caused an additional 140,000
deaths in 2004, as compared with the number of deaths there would have been had average global
temperatures remained as they were during the period 1961 to 1990. This means that climate change is
already causing, every week, as many deaths as occurred in the terrorist attacks on September 11, 2001"
-- Peter Singer _Practical Ethics, Third Edition_, p. 216.

--- On Sun, 7/22/12, Richard Fateman <fateman <at> eecs.berkeley.edu> wrote:

> From: Richard Fateman <fateman <at> eecs.berkeley.edu>

(Continue reading)

headers

Robert Dodier | 23 Jul 2012 08:10

Re: On Ruby program to generate maxima or maple code to solve differential eq's

On 2012-07-22, Dennis Darland <dennis.darland <at> yahoo.com> wrote:

> One of Bertrand Russell's favorite quotations from the Bible had to do
> with not following a multitude to do evil.

Not to split hairs or anything, but I seem to recall that Russell was
reporting James Mill's advice to his son (John Stuart Mill). Was that in
Russell's essay on the difference between Catholic and Protestant
atheists? I seem to recall Russell gave JS Mill as an example of
a typically Protestant atheist -- earnest, moral, and inclined to invent
his own philosophy. On the other hand, the Catholic church's claim to be
the be-all and end-all of religion causes those who reject it to reject
all moral systems; Catholic atheists, he says, are more often cynical
and detached. He gives Voltaire as a typical example.

I'll leave it to others to verify the accuracy of Russell's assessment.

Philosophically yours,

Robert Dodier

headers

Dennis Darland | 9 Aug 2012 13:34

Timing comparison for diffeq program in c++, Maple and Maxima

I ran a timing test comparison for c++, Maple and Maxima.
All three programs generated by omnisode - a set of Ruby programs.
Set time limit to 1 minute.
Maximum iteration was sufficient to solve entire problem.
Problem was sin.ode for all three.
Output was redirected to file only - none to screen
Results:
c++ solved entire problem in 23 seconds (140001 iterations)
Maple performed 11542 iterations in 60 seconds
Maxima performed 372 iterations in 60 seconds
That amounts to:
c++ 6,087 iterations/second
Maple 192 iterations/second
Maxima 6.2 iterations/second
c++ is almost 32 times faster than Maple which is almost 31 times faster than Maxima.
So c++ is almost 982 times faster than Maxima.

More info on omnisode at:
http://sode.sourceforge.net/

Dennis J. Darland
dennis.darland <at> yahoo.com
http://dennisdarland.com/
http://dennisdarland.com/dennisdaze/
http://dennisdarland.com/philosophy/
http://sode.sourceforge.net/
"According to the World Health Organization, the warming of the planet caused an additional 140,000
deaths in 2004, as compared with the number of deaths there would have been had average global
temperatures remained as they were during the period 1961 to 1990. This means that climate change is
already causing, every week, as many deaths as occurred in the terrorist attacks on September 11, 2001"

(Continue reading)

headers

Rupert Swarbrick | 9 Aug 2012 14:32

Re: Timing comparison for diffeq program in c++, Maple and Maxima

Dennis Darland <dennis.darland <at> yahoo.com> writes:
> I ran a timing test comparison for c++, Maple and Maxima.
> All three programs generated by omnisode - a set of Ruby programs.
> Set time limit to 1 minute.
> Maximum iteration was sufficient to solve entire problem.
> Problem was sin.ode for all three.
> Output was redirected to file only - none to screen
> Results:
> c++ solved entire problem in 23 seconds (140001 iterations)
> Maple performed 11542 iterations in 60 seconds
> Maxima performed 372 iterations in 60 seconds
> That amounts to:
> c++ 6,087 iterations/second
> Maple 192 iterations/second
> Maxima 6.2 iterations/second
> c++ is almost 32 times faster than Maple which is almost 31 times faster than Maxima.
> So c++ is almost 982 times faster than Maxima.
>
> More info on omnisode at:
> http://sode.sourceforge.net/

Right, I just tried to look up the Maxima code you're generating and
found things like [1]. Since I'm clearly not going to read through that
carefully, and I presume no-one else is either, can you explain exactly
what you're measuring?

Your code looks to me like a C/FORTRAN program translated to
Maxima. Unsurprisingly, it runs very slowly. What are you actually
trying to do? What capabilities of Maple or Maxima are you using other
than basic arithmetic?

(Continue reading)

headers

Richard Fateman | 9 Aug 2012 16:09

Re: Timing comparison for diffeq program in c++, Maple and Maxima

On 8/9/2012 5:32 AM, Rupert Swarbrick wrote:

Dennis Darland <dennis.darland <at> yahoo.com> writes:
I ran a timing test comparison for c++, Maple and Maxima. All three programs generated by omnisode - a set of Ruby programs. Set time limit to 1 minute. Maximum iteration was sufficient to solve entire problem. Problem was sin.ode for all three. Output was redirected to file only - none to screen Results: c++ solved entire problem in 23 seconds (140001 iterations) Maple performed 11542 iterations in 60 seconds Maxima performed 372 iterations in 60 seconds That amounts to: c++ 6,087 iterations/second Maple 192 iterations/second Maxima 6.2 iterations/second c++ is almost 32 times faster than Maple which is almost 31 times faster than Maxima. So c++ is almost 982 times faster than Maxima. More info on omnisode at: http://sode.sourceforge.net/
Right, I just tried to look up the Maxima code you're generating and found things like [1]. Since I'm clearly not going to read through that carefully, and I presume no-one else is either, can you explain exactly what you're measuring? Your code looks to me like a C/FORTRAN program translated to Maxima. Unsurprisingly, it runs very slowly. What are you actually trying to do? What capabilities of Maple or Maxima are you using other than basic arithmetic? Or should we interpret your message as "Writing bare-metal calculations in Maple and running them is marginally less slow that writing them in Maxima and running them. But it would have been easier to do it in C anyway" ?

I spent 1 minute looking at the code in [1] ... It seems to me that if you are computing Taylor
series you should use the Taylor series command and not write something in what looks
like C. Etc. So you are using these enormously powerful programs to simulate very
low level operations, as Rubert says. So you should use C. And if you want it to run
faster, consider generating assembler.

(You can make Maxima run faster by adding declarations and compiling, but that will
probably make it no more than about 100X faster.)

Rupert [1] http://sode.sourceforge.net/omniresults/special_cases_007/diffeq.tan_sqrt_lin.mxt.txt

_______________________________________________ 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

headers

Dennis Darland | 9 Aug 2012 17:07

Re: Timing comparison for diffeq program in c++, Maple and Maxima

How, given the diffeq below, do you generate a Taylor series in
Maxima?

diff ( y , x , 1 ) = tan(sqrt(2.0*x + 3.0));or better, the system:
diff (x2,t,2) = 3.0 * diff(x2,t,1) - 2.0 * x2 - diff(x1,t,2) - diff (x1,t,1) + x1; diff (x1,t,1) = 4.0 * x2 - 2.0 * diff (x2,t ,1) - 2.0 * x1; Dennis J. Darland
dennis.darland <at> yahoo.com
http://dennisdarland.com/
http://dennisdarland.com/dennisdaze/
http://dennisdarland.com/philosophy/
http://sode.sourceforge.net/
"According to the World Health Organization, the warming of the planet caused an additional 140,000 deaths in 2004, as compared with the number of deaths there would have been had average global temperatures remained as they were during the period 1961 to 1990. This means that climate change is already causing, every week, as many deaths as occurred in the terrorist attacks on September 11, 2001"
-- Peter Singer _Practical Ethics, Third Edition_, p. 216.

--- On Thu, 8/9/12, Richard Fateman <fateman <at> eecs.berkeley.edu> wrote:

From: Richard Fateman <fateman <at> eecs.berkeley.edu>
Subject: Re: [Maxima] Timing comparison for diffeq program in c++, Maple and Maxima
To: maxima <at> math.utexas.edu
Cc: "Rupert Swarbrick" <rswarbrick <at> gmail.com>
Date: Thursday, August 9, 2012, 9:09 AM

On 8/9/2012 5:32 AM, Rupert Swarbrick wrote:

Dennis Darland <dennis.darland <at> yahoo.com> writes:
I ran a timing test comparison for c++, Maple and Maxima. All three programs generated by omnisode - a set of Ruby programs. Set time limit to 1 minute. Maximum iteration was sufficient to solve entire problem. Problem was sin.ode for all three. Output was redirected to file only - none to screen Results: c++ solved entire problem in 23 seconds (140001 iterations) Maple performed 11542 iterations in 60 seconds Maxima performed 372 iterations in 60 seconds That amounts to: c++ 6,087 iterations/second Maple 192 iterations/second Maxima 6.2 iterations/second c++ is almost 32 times faster than Maple which is almost 31 times faster than Maxima. So c++ is almost 982 times faster than Maxima. More info on omnisode at: http://sode.sourceforge.net/
Right, I just tried to look up the Maxima code you're generating and found things like [1]. Since I'm clearly not going to read through that carefully, and I presume no-one else is either, can you explain exactly what you're measuring? Your code looks to me like a C/FORTRAN program translated to Maxima. Unsurprisingly, it runs very slowly. What are you actually trying to do? What capabilities of Maple or Maxima are you using other than basic arithmetic? Or should we interpret your message as "Writing bare-metal calculations in Maple and running them is marginally less slow that writing them in Maxima and running them. But it would have been easier to do it in C anyway" ?

I spent 1 minute looking at the code in [1] ... It seems to me that if you are computing Taylor
series you should use the Taylor series command and not write something in what looks
like C. Etc. So you are using these enormously powerful programs to simulate very
low level operations, as Rubert says. So you should use C. And if you want it to run
faster, consider generating assembler.

(You can make Maxima run faster by adding declarations and compiling, but that will
probably make it no more than about 100X faster.)
Rupert [1] http://sode.sourceforge.net/omniresults/special_cases_007/diffeq.tan_sqrt_lin.mxt.txt

_______________________________________________ Maxima mailing list Maxima <at> math.utexas.edu http://www.math.utexas.edu/mailman/listinfo/maxima

-----Inline Attachment Follows-----

_______________________________________________
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

headers

John Lapeyre | 9 Aug 2012 18:04

Re: Timing comparison for diffeq program in c++, Maple and Maxima

> c++ is almost 32 times faster than Maple which is almost
> 31 times faster than Maxima So c++ is almost 982 times
> faster than Maxima.

Well, I can prove that maxima is three times faster than
Mathematica.

These were done on the same machine:

Mathematica 8.0:

In[9]:= Timing[FactorInteger[8478652817085319534251064469689222730894091034507427331241538883820818894545883959]]

Out[9]= {2434.64, {{75582488424179347083438319, 1},

> {112177476474470525577861298937835338545723093134076373561, 1}}}

maxima 5.20.1 , gcl 2.6.7

(%i3) factor(8478652817085319534251064469689222730894091034507427331241538883820818894545883959);
Evaluation took 783.2400 seconds (783.9600 elapsed)
(%o3) 75582488424179347083438319
112177476474470525577861298937835338545723093134076373561

John

_______________________________________________
Maxima mailing list
Maxima <at> math.utexas.edu
http://www.math.utexas.edu/mailman/listinfo/maxima

headers

Rupert Swarbrick | 9 Aug 2012 17:50

Re: Timing comparison for diffeq program in c++, Maple and Maxima

Dennis Darland <dennis.darland <at> yahoo.com> writes:
> How, given the diffeq below, do you generate a Taylor series in 
> Maxima?
>
> diff ( y , x , 1 ) = tan(sqrt(2.0*x + 3.0));

Well a 1d example like this is easy. Don't forget what a Taylor series
is:

  y(x) = y(c) + (x-c)*y'(c) + (x-c)^2/2*y''(c) + ...

You're saying that you have a formula for y'(x). In which case a
(forward-Euler style) Taylor series is easy enough:

(%i1) rhs: tan(sqrt(2*x+3));
(%o1)                         tan(sqrt(2 x + 3))
(%i2) assume(x>c);
(%o2)                               [x > c]
(%i3) taylor ('integrate(rhs, x, c, x), x, c, 2);
(%o3)/T/ tan(sqrt(2 c + 3)) (x - c)
                               2                                      2
                           (sec (sqrt(2 c + 3)) sqrt(2 c + 3)) (x - c)
                         + -------------------------------------------- + . . .
                                             4 c + 6

(You need to quote integrate, otherwise Maxima tries to do the
integration)

> or better, the system:
> diff (x2,t,2) = 3.0 * diff(x2,t,1) - 2.0 * x2 - diff(x1,t,2) - diff (x1,t,1) + x1;
> diff (x1,t,1) = 4.0 * x2 -  2.0 * diff (x2,t ,1) - 2.0 * x1;

Well, if you look at the documentation for Taylor, you'll see that it
can do multivariate Taylor series. You have a weird mixture of a second
order and first order equation here. Presumably you want something that
works for "any" equation you give it, so there's no point in trying to
spot some structure in the example you've posted. As such, what you
should probably do is transform this into a collection of coupled
first-order ODEs.

Let

  u1 = x1
  u2 = x2
  u3 = dx1/dt
  u4 = dx2/dt

Then you end up with

(%i1) eqs: ['diff(x2,t,2)=3*'diff(x2,t)-2*x2-'diff(x1,t,2)-'diff(x1,t)+x1,
            'diff(x1,t)  =4*x2 - 2*'diff(x2,t)-2*x1];
        2                     2
       d x2     dx2          d x1   dx1       dx1       dx2
(%o1) [---- = 3 --- - 2 x2 - ---- - --- + x1, --- = - 2 --- + 4 x2 - 2 x1]
         2      dt             2    dt        dt        dt
       dt                    dt
(%i2) subst(['diff(x2,t,2)='diff(u4,t), 'diff(x1,t,2)='diff(u3,t),
             'diff(x2,t)=u2, 'diff(x1,t)=u1],
             eqs);
         du4                 du3
(%o2)   [--- = - 2 x2 + x1 - --- + 3 u2 - u1, u1 = 4 x2 - 2 x1 - 2 u2]
         dt                  dt

And the system is in fact linear here, so the Taylor series is trivial.

I think that if you want Maxima to do something useful you should
probably tell us what your "sode" code is actually supposed to do. Is it
just a naive numerical integrator? In which case, give up on symbolic
algebra packages and code it in C/C++ or Octave. You should also
probably read some numerical analysis textbooks: just using Taylor
expansions isn't the best approach.

Or maybe you want your code to do some cool maths that automatically
spots special structures in the problems it's given? In which case, a
higher level tool might be fantastic. But it really isn't clear what
you're trying to achieve.

Rupert

_______________________________________________
Maxima mailing list
Maxima <at> math.utexas.edu
http://www.math.utexas.edu/mailman/listinfo/maxima

headers

Dennis Darland | 10 Aug 2012 00:06

Re: Timing comparison for diffeq program in c++, Maple and Maxima

In testing I've mostly stuck to problems which have analytic solutions. But most problems do not have
analytic solutions at all. I think an analytic solution would always be preferable to a numeric one (I
cannot think of any exceptions). But you cannot always get one. Sometimes, you cannot do the 'integrate'
step. I've mostly been working on problems with analytic solutions for testing purposes. I do not
question the superiority of maxima or maple for symbolic calculations. I have much more experience with
maple. I also know there are other, more common, numeric methods. I got interested in this as a possibly
overlooked one.

Dennis J. Darland
dennis.darland <at> yahoo.com
http://dennisdarland.com/
http://dennisdarland.com/dennisdaze/
http://dennisdarland.com/philosophy/
http://sode.sourceforge.net/
"According to the World Health Organization, the warming of the planet caused an additional 140,000
deaths in 2004, as compared with the number of deaths there would have been had average global
temperatures remained as they were during the period 1961 to 1990. This means that climate change is
already causing, every week, as many deaths as occurred in the terrorist attacks on September 11, 2001"
-- Peter Singer _Practical Ethics, Third Edition_, p. 216.

--- On Thu, 8/9/12, Rupert Swarbrick <rswarbrick <at> gmail.com> wrote:

> From: Rupert Swarbrick <rswarbrick <at> gmail.com>
> Subject: Re: [Maxima] Timing comparison for diffeq program in c++, Maple and Maxima
> To: maxima <at> math.utexas.edu
> Date: Thursday, August 9, 2012, 10:50 AM
> Dennis Darland <dennis.darland <at> yahoo.com>
> writes:
> > How, given the diffeq below, do you generate a Taylor
> series in 
> > Maxima?
> >
> > diff ( y , x , 1 ) = tan(sqrt(2.0*x + 3.0));
> 
> Well a 1d example like this is easy. Don't forget what a
> Taylor series
> is:
> 
>   y(x) = y(c) + (x-c)*y'(c) + (x-c)^2/2*y''(c) + ...
> 
> You're saying that you have a formula for y'(x). In which
> case a
> (forward-Euler style) Taylor series is easy enough:
> 
> (%i1) rhs: tan(sqrt(2*x+3));
> (%o1)               
>          tan(sqrt(2 x + 3))
> (%i2) assume(x>c);
> (%o2)               
>            
>    [x > c]
> (%i3) taylor ('integrate(rhs, x, c, x), x, c, 2);
> (%o3)/T/ tan(sqrt(2 c + 3)) (x - c)
>                
>            
>    2           
>                
>           2
>                
>            (sec (sqrt(2 c
> + 3)) sqrt(2 c + 3)) (x - c)
>                
>          +
> -------------------------------------------- + . . .
>                
>                
>              4 c +
> 6
> 
> 
> (You need to quote integrate, otherwise Maxima tries to do
> the
> integration)
> 
> > or better, the system:
> > diff (x2,t,2) = 3.0 * diff(x2,t,1) - 2.0 * x2 -
> diff(x1,t,2) - diff (x1,t,1) + x1;
> > diff (x1,t,1) = 4.0 * x2 -  2.0 * diff (x2,t ,1) -
> 2.0 * x1;
> 
> Well, if you look at the documentation for Taylor, you'll
> see that it
> can do multivariate Taylor series. You have a weird mixture
> of a second
> order and first order equation here. Presumably you want
> something that
> works for "any" equation you give it, so there's no point in
> trying to
> spot some structure in the example you've posted. As such,
> what you
> should probably do is transform this into a collection of
> coupled
> first-order ODEs.
> 
> Let
> 
>   u1 = x1
>   u2 = x2
>   u3 = dx1/dt
>   u4 = dx2/dt
> 
> Then you end up with
> 
> (%i1) eqs:
> ['diff(x2,t,2)=3*'diff(x2,t)-2*x2-'diff(x1,t,2)-'diff(x1,t)+x1,
>             'diff(x1,t) 
> =4*x2 - 2*'diff(x2,t)-2*x1];
>         2       
>              2
>        d x2 
>    dx2          d
> x1   dx1   
>    dx1       dx2
> (%o1) [---- = 3 --- - 2 x2 - ---- - --- + x1, --- = - 2 ---
> + 4 x2 - 2 x1]
>          2     
> dt         
>    2    dt     
>   dt        dt
>        dt     
>               dt
> (%i2) subst(['diff(x2,t,2)='diff(u4,t),
> 'diff(x1,t,2)='diff(u3,t),
>          
>    'diff(x2,t)=u2, 'diff(x1,t)=u1],
>              eqs);
>          du4   
>              du3
> (%o2)   [--- = - 2 x2 + x1 - --- + 3 u2 - u1,
> u1 = 4 x2 - 2 x1 - 2 u2]
>          dt   
>               dt
> 
> And the system is in fact linear here, so the Taylor series
> is trivial.
> 
> 
> I think that if you want Maxima to do something useful you
> should
> probably tell us what your "sode" code is actually supposed
> to do. Is it
> just a naive numerical integrator? In which case, give up on
> symbolic
> algebra packages and code it in C/C++ or Octave. You should
> also
> probably read some numerical analysis textbooks: just using
> Taylor
> expansions isn't the best approach.
> 
> Or maybe you want your code to do some cool maths that
> automatically
> spots special structures in the problems it's given? In
> which case, a
> higher level tool might be fantastic. But it really isn't
> clear what
> you're trying to achieve.
> 
> 
> Rupert
> 
> -----Inline Attachment Follows-----
> 
> _______________________________________________
> Maxima mailing list
> Maxima <at> math.utexas.edu
> http://www.math.utexas.edu/mailman/listinfo/maxima
>

headers

Dennis Darland | 9 Aug 2012 16:18

Re: Timing comparison for diffeq program in c++, Maple and Maxima

I am using just basic math like you say. In maple I can use higher precision floating point by setting
"Digits". (Though it only seems to work up to about 32 digits). I expected to be able to do something similar
in Maxima. Maxima does have "big floats". I tried them, but, as far as I could tell, they did not support trig
functions, etc. (You only get about 16 digits and a lot of warning messages).  If  big floats can me made to
support trig functions, etc., I would like to know about it. I plan to look also for a c++ library for
extended precision floating point numbers. I am also interested in what is called "interval arithmetic."

I also used Maxima as well as Maple as it is more affordable, and I like to support open source. I am not trying
to criticize Maple or Maxima, only to ascertain the facts. It is interesting that c++ is so much faster, in
that it makes solving some problems more practical.

The program was debugged in Maple and Maxima together. Both, in some cases gave better error messages than
the other. I doubt I could have debugged it in c or c++, which most likely have crashed instead of giving an
error message. (The code to generate c or c++ is not released yet, as I am just beginning to test it, but it
seems to work OK so far)

The reason I started subscripts at 1 was Dr Chang's work started subscripts at 1, and thus it was a lot easier.
I used the formulas from his draft of a book he started. He was working in FORTRAN, but my program is not at all
a translation of his program. (He wrote as program in FORTRAN which generated a FORTRAN program,) His
program is beyond my comprehension.  Also other languages I may want to use in the future may not permit "0"
subscripts. I doubt I will ever support FORTRAN.

Dennis J. Darland
dennis.darland <at> yahoo.com
http://dennisdarland.com/
http://dennisdarland.com/dennisdaze/
http://dennisdarland.com/philosophy/
http://sode.sourceforge.net/
"According to the World Health Organization, the warming of the planet caused an additional 140,000
deaths in 2004, as compared with the number of deaths there would have been had average global
temperatures remained as they were during the period 1961 to 1990. This means that climate change is
already causing, every week, as many deaths as occurred in the terrorist attacks on September 11, 2001"
-- Peter Singer _Practical Ethics, Third Edition_, p. 216.

--- On Thu, 8/9/12, Rupert Swarbrick <rswarbrick <at> gmail.com> wrote:

> From: Rupert Swarbrick <rswarbrick <at> gmail.com>
> Subject: Re: [Maxima] Timing comparison for diffeq program in c++, Maple and Maxima
> To: maxima <at> math.utexas.edu
> Date: Thursday, August 9, 2012, 7:32 AM
> Dennis Darland <dennis.darland <at> yahoo.com>
> writes:
> > I ran a timing test comparison for c++, Maple and
> Maxima.
> > All three programs generated by omnisode - a set of
> Ruby programs.
> > Set time limit to 1 minute.
> > Maximum iteration was sufficient to solve entire
> problem.
> > Problem was sin.ode for all three.
> > Output was redirected to file only - none to screen
> > Results:
> > c++ solved entire problem in 23 seconds (140001
> iterations)
> > Maple performed 11542 iterations in 60 seconds
> > Maxima performed 372 iterations in 60 seconds
> > That amounts to:
> > c++ 6,087 iterations/second
> > Maple 192 iterations/second
> > Maxima 6.2 iterations/second
> > c++ is almost 32 times faster than Maple which is
> almost 31 times faster than Maxima.
> > So c++ is almost 982 times faster than Maxima.
> >
> > More info on omnisode at:
> > http://sode.sourceforge.net/
> 
> Right, I just tried to look up the Maxima code you're
> generating and
> found things like [1]. Since I'm clearly not going to read
> through that
> carefully, and I presume no-one else is either, can you
> explain exactly
> what you're measuring?
> 
> Your code looks to me like a C/FORTRAN program translated
> to
> Maxima. Unsurprisingly, it runs very slowly. What are you
> actually
> trying to do? What capabilities of Maple or Maxima are you
> using other
> than basic arithmetic?
> 
> Or should we interpret your message as
> 
>   "Writing bare-metal calculations in Maple and running
> them is
>    marginally less slow that writing them in
> Maxima and running
>    them. But it would have been easier to do
> it in C anyway"
> 
>  ?
> 
> 
> Rupert
> 
> [1] http://sode.sourceforge.net/omniresults/special_cases_007/diffeq.tan_sqrt_lin.mxt.txt
> 
> -----Inline Attachment Follows-----
> 
> _______________________________________________
> Maxima mailing list
> Maxima <at> math.utexas.edu
> http://www.math.utexas.edu/mailman/listinfo/maxima
>

headers

Stavros Macrakis | 9 Aug 2012 17:34

Re: Timing comparison for diffeq program in c++, Maple and Maxima

A quick look at your code shows that the only mode_declare's are mode_declare(f,bfloat), where f is a function. There are several problems with this:

* That is not the correct syntax for mode_declare of a function.

* bfloat is not one of the types that mode_declare understands (and in fact it gives a warning for this).

* In any case, bfloat calculation is going to be about equally expensive whether compiled or interpreted.

I haven't looked closely, but I also get the impression that you're using arrays incorrectly. Please don't assume that Maxima arrays behave the same as C, Fortran, or Maple arrays. They do not. Some of the differences are certainly idiosyncratic, but that's what they are for now....

Without declarations for machine types (notably float and fixnum) for your variables and arrays, Maxima assumes fully general symbolic calculations, which are expensive.

Again, I haven't looked at your code in detail, but where do you actually compile all the functions anyway?

I would suggest that you start with some "finger exercises" on smaller cases before trying to run your full DE code. Also not clear why you want to do this in Maxima at all if you're using none of its symbolic capabilities. Mixed symbolic/numeric calculations are another matter....

-s

On Thu, Aug 9, 2012 at 10:18 AM, Dennis Darland <dennis.darland <at> yahoo.com> wrote:

I am using just basic math like you say. In maple I can use higher precision floating point by setting "Digits". (Though it only seems to work up to about 32 digits). I expected to be able to do something similar in Maxima. Maxima does have "big floats". I tried them, but, as far as I could tell, they did not support trig functions, etc. (You only get about 16 digits and a lot of warning messages). If big floats can me made to support trig functions, etc., I would like to know about it. I plan to look also for a c++ library for extended precision floating point numbers. I am also interested in what is called "interval arithmetic."

I also used Maxima as well as Maple as it is more affordable, and I like to support open source. I am not trying to criticize Maple or Maxima, only to ascertain the facts. It is interesting that c++ is so much faster, in that it makes solving some problems more practical.

The program was debugged in Maple and Maxima together. Both, in some cases gave better error messages than the other. I doubt I could have debugged it in c or c++, which most likely have crashed instead of giving an error message. (The code to generate c or c++ is not released yet, as I am just beginning to test it, but it seems to work OK so far)

The reason I started subscripts at 1 was Dr Chang's work started subscripts at 1, and thus it was a lot easier. I used the formulas from his draft of a book he started. He was working in FORTRAN, but my program is not at all a translation of his program. (He wrote as program in FORTRAN which generated a FORTRAN program,) His program is beyond my comprehension. Also other languages I may want to use in the future may not permit "0" subscripts. I doubt I will ever support FORTRAN.

Dennis J. Darland
dennis.darland <at> yahoo.com
http://dennisdarland.com/
http://dennisdarland.com/dennisdaze/
http://dennisdarland.com/philosophy/
http://sode.sourceforge.net/
"According to the World Health Organization, the warming of the planet caused an additional 140,000 deaths in 2004, as compared with the number of deaths there would have been had average global temperatures remained as they were during the period 1961 to 1990. This means that climate change is already causing, every week, as many deaths as occurred in the terrorist attacks on September 11, 2001"
-- Peter Singer _Practical Ethics, Third Edition_, p. 216.

--- On Thu, 8/9/12, Rupert Swarbrick <rswarbrick <at> gmail.com> wrote:

> From: Rupert Swarbrick <rswarbrick <at> gmail.com>
> Subject: Re: [Maxima] Timing comparison for diffeq program in c++, Maple and Maxima
> To: maxima <at> math.utexas.edu
> Date: Thursday, August 9, 2012, 7:32 AM
> Dennis Darland <dennis.darland <at> yahoo.com>
> writes:
> > I ran a timing test comparison for c++, Maple and
> Maxima.
> > All three programs generated by omnisode - a set of
> Ruby programs.
> > Set time limit to 1 minute.
> > Maximum iteration was sufficient to solve entire
> problem.
> > Problem was sin.ode for all three.
> > Output was redirected to file only - none to screen
> > Results:
> > c++ solved entire problem in 23 seconds (140001
> iterations)
> > Maple performed 11542 iterations in 60 seconds
> > Maxima performed 372 iterations in 60 seconds
> > That amounts to:
> > c++ 6,087 iterations/second
> > Maple 192 iterations/second
> > Maxima 6.2 iterations/second
> > c++ is almost 32 times faster than Maple which is
> almost 31 times faster than Maxima.
> > So c++ is almost 982 times faster than Maxima.
> >
> > More info on omnisode at:
> > http://sode.sourceforge.net/
>
> Right, I just tried to look up the Maxima code you're
> generating and
> found things like [1]. Since I'm clearly not going to read
> through that
> carefully, and I presume no-one else is either, can you
> explain exactly
> what you're measuring?
>
> Your code looks to me like a C/FORTRAN program translated
> to
> Maxima. Unsurprisingly, it runs very slowly. What are you
> actually
> trying to do? What capabilities of Maple or Maxima are you
> using other
> than basic arithmetic?
>
> Or should we interpret your message as
>
> "Writing bare-metal calculations in Maple and running
> them is
> marginally less slow that writing them in
> Maxima and running
> them. But it would have been easier to do
> it in C anyway"
>
> ?
>
>
> Rupert
>
> [1] http://sode.sourceforge.net/omniresults/special_cases_007/diffeq.tan_sqrt_lin.mxt.txt
>

> -----Inline Attachment Follows-----
>
> _______________________________________________
> 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

headers

Dennis Darland | 9 Aug 2012 23:52

Re: Timing comparison for diffeq program in c++, Maple and Maxima

I commented out the generation of all the "mode_declares"
Got 394 iterations in 60 second (on same problem as before)
Ii.e. 6.6 iterations/second.

I had a lot of trouble with arrays in maxima.
I was trying to pass them as parameters at first.
As most of you probably know in c, most things (say integers, or floats) are passed by value, but for arrays, the address of the array is passed as the value. Thus you can change what is pointed to. (If you wanted to change an int, you would pass the address of the int, not the int itself).

It seems, in maxma (the best I can describe it - if there is a better way please let me know). Arrays are passed by value also.

I thus only use arrays on a global manner. (They seem automatically have this scope) I never pass them as parameters. This I also do in the generated Maple and c++ code. In cases I need to do the same sort of thing of two different arrays I generate the same code - once for each array. This would be a big problem if I were writing the code by hand. It is not when a program generates the code. The code is probably faster - fewer function calls. The code will take more memory, but will use less stack. Anyway that solved the problem with arrays.

I had just been interpreting the maxima code. I just tried to compile it and it did not like where I had a "declare_variable".(The 1st one)

I will look further at bfloats. I was pretty sure I had problems with them, but that was early on and I had other problems then. I can do that separate from the ODE code.

Dennis J. Darland
dennis.darland <at> yahoo.com
http://dennisdarland.com/
http://dennisdarland.com/dennisdaze/
http://dennisdarland.com/philosophy/
http://sode.sourceforge.net/
"According to the World Health Organization, the warming of the planet caused an additional 140,000 deaths in 2004, as compared with the number of deaths there would have been had average global temperatures remained as they were during the period 1961 to 1990. This means that climate change is already causing, every week, as many deaths as occurred in the terrorist attacks on September 11, 2001"
-- Peter Singer _Practical Ethics, Third Edition_, p. 216.

--- On Thu, 8/9/12, Stavros Macrakis <macrakis <at> alum.mit.edu> wrote:

From: Stavros Macrakis <macrakis <at> alum.mit.edu>
Subject: Re: [Maxima] Timing comparison for diffeq program in c++, Maple and Maxima
To: "Dennis Darland" <dennis.darland <at> yahoo.com>
Cc: maxima <at> math.utexas.edu, "Rupert Swarbrick" <rswarbrick <at> gmail.com>
Date: Thursday, August 9, 2012, 10:34 AM

A quick look at your code shows that the only mode_declare's are mode_declare(f,bfloat), where f is a function. There are several problems with this:

* That is not the correct syntax for mode_declare of a function.

* bfloat is not one of the types that mode_declare understands (and in fact it gives a warning for this).

* In any case, bfloat calculation is going to be about equally expensive whether compiled or interpreted.

I haven't looked closely, but I also get the impression that you're using arrays incorrectly. Please don't assume that Maxima arrays behave the same as C, Fortran, or Maple arrays. They do not. Some of the differences are certainly idiosyncratic, but that's what they are for now....

Without declarations for machine types (notably float and fixnum) for your variables and arrays, Maxima assumes fully general symbolic calculations, which are expensive.

Again, I haven't looked at your code in detail, but where do you actually compile all the functions anyway?

I would suggest that you start with some "finger exercises" on smaller cases before trying to run your full DE code. Also not clear why you want to do this in Maxima at all if you're using none of its symbolic capabilities. Mixed symbolic/numeric calculations are another matter....

-s
On Thu, Aug 9, 2012 at 10:18 AM, Dennis Darland <dennis.darland <at> yahoo.com> wrote:
I am using just basic math like you say. In maple I can use higher precision floating point by setting "Digits". (Though it only seems to work up to about 32 digits). I expected to be able to do something similar in Maxima. Maxima does have "big floats". I tried them, but, as far as I could tell, they did not support trig functions, etc. (You only get about 16 digits and a lot of warning messages). If big floats can me made to support trig functions, etc., I would like to know about it. I plan to look also for a c++ library for extended precision floating point numbers. I am also interested in what is called "interval arithmetic."

I also used Maxima as well as Maple as it is more affordable, and I like to support open source. I am not trying to criticize Maple or Maxima, only to ascertain the facts. It is interesting that c++ is so much faster, in that it makes solving some problems more practical.

The program was debugged in Maple and Maxima together. Both, in some cases gave better error messages than the other. I doubt I could have debugged it in c or c++, which most likely have crashed instead of giving an error message. (The code to generate c or c++ is not released yet, as I am just beginning to test it, but it seems to work OK so far)

The reason I started subscripts at 1 was Dr Chang's work started subscripts at 1, and thus it was a lot easier. I used the formulas from his draft of a book he started. He was working in FORTRAN, but my program is not at all a translation of his program. (He wrote as program in FORTRAN which generated a FORTRAN program,) His program is beyond my comprehension. Also other languages I may want to use in the future may not permit "0" subscripts. I doubt I will ever support FORTRAN.

Dennis J. Darland
dennis.darland <at> yahoo.com
http://dennisdarland.com/
http://dennisdarland.com/dennisdaze/
http://dennisdarland.com/philosophy/
http://sode.sourceforge.net/
"According to the World Health Organization, the warming of the planet caused an additional 140,000 deaths in 2004, as compared with the number of deaths there would have been had average global temperatures remained as they were during the period 1961 to 1990. This means that climate change is already causing, every week, as many deaths as occurred in the terrorist attacks on September 11, 2001"
-- Peter Singer _Practical Ethics, Third Edition_, p. 216.

--- On Thu, 8/9/12, Rupert Swarbrick <rswarbrick <at> gmail.com> wrote:

> From: Rupert Swarbrick <rswarbrick <at> gmail.com>
> Subject: Re: [Maxima] Timing comparison for diffeq program in c++, Maple and Maxima
> To: maxima <at> math.utexas.edu
> Date: Thursday, August 9, 2012, 7:32 AM
> Dennis Darland <dennis.darland <at> yahoo.com>
> writes:
> > I ran a timing test comparison for c++, Maple and
> Maxima.
> > All three programs generated by omnisode - a set of
> Ruby programs.
> > Set time limit to 1 minute.
> > Maximum iteration was sufficient to solve entire
> problem.
> > Problem was sin.ode for all three.
> > Output was redirected to file only - none to screen
> > Results:
> > c++ solved entire problem in 23 seconds (140001
> iterations)
> > Maple performed 11542 iterations in 60 seconds
> > Maxima performed 372 iterations in 60 seconds
> > That amounts to:
> > c++ 6,087 iterations/second
> > Maple 192 iterations/second
> > Maxima 6.2 iterations/second
> > c++ is almost 32 times faster than Maple which is
> almost 31 times faster than Maxima.
> > So c++ is almost 982 times faster than Maxima.
> >
> > More info on omnisode at:
> > http://sode.sourceforge.net/
>
> Right, I just tried to look up the Maxima code you're
> generating and
> found things like [1]. Since I'm clearly not going to read
> through that
> carefully, and I presume no-one else is either, can you
> explain exactly
> what you're measuring?
>
> Your code looks to me like a C/FORTRAN program translated
> to
> Maxima. Unsurprisingly, it runs very slowly. What are you
> actually
> trying to do? What capabilities of Maple or Maxima are you
> using other
> than basic arithmetic?
>
> Or should we interpret your message as
>
> "Writing bare-metal calculations in Maple and running
> them is
> marginally less slow that writing them in
> Maxima and running
> them. But it would have been easier to do
> it in C anyway"
>
> ?
>
>
> Rupert
>
> [1] http://sode.sourceforge.net/omniresults/special_cases_007/diffeq.tan_sqrt_lin.mxt.txt
>

> -----Inline Attachment Follows-----
>
> _______________________________________________
> 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

headers

Robert Dodier | 10 Aug 2012 01:54

Re: Timing comparison for diffeq program in c++, Maple and Maxima

On 2012-08-09, Dennis Darland <dennis.darland <at> yahoo.com> wrote:

> I had a lot of trouble with arrays in maxima.

Yeah, arrays are difficult to work with. There are probably some
relatively simple things that could be changed to make it easier,
although nothing on the horizon yet.

best,

Robert Dodier

headers

Dennis Darland | 10 Aug 2012 02:40

Warnings compiling

Compiling I get many warnings about undefined variables. As I understand it 'define variable' defines
global variables. Many of the variables I got warnings for I would not want to be global. Is there a way to
define local variables? Others are arrays. The arrays worked as global OK when the code was being
interpreted. I could not figure how to define arrays in define_variable either. That was some time ago.
Also, the code ran even with the warnings, but was no faster. Also variables defined with 'define
variable, were also listed. Perhaps because this was called in the main function, and the variables
appeared in functions before it in the file.

Dennis J. Darland
dennis.darland <at> yahoo.com
http://dennisdarland.com/
http://dennisdarland.com/dennisdaze/
http://dennisdarland.com/philosophy/
http://sode.sourceforge.net/
"According to the World Health Organization, the warming of the planet caused an additional 140,000
deaths in 2004, as compared with the number of deaths there would have been had average global
temperatures remained as they were during the period 1961 to 1990. This means that climate change is
already causing, every week, as many deaths as occurred in the terrorist attacks on September 11, 2001"
-- Peter Singer _Practical Ethics, Third Edition_, p. 216.

--- On Thu, 8/9/12, Robert Dodier <robert.dodier <at> gmail.com> wrote:

> From: Robert Dodier <robert.dodier <at> gmail.com>
> Subject: Re: [Maxima] Timing comparison for diffeq program in c++, Maple and Maxima
> To: maxima <at> math.utexas.edu
> Date: Thursday, August 9, 2012, 6:54 PM
> On 2012-08-09, Dennis Darland <dennis.darland <at> yahoo.com>
> wrote:
> 
> > I had a lot of trouble with arrays in maxima.
> 
> Yeah, arrays are difficult to work with. There are probably
> some
> relatively simple things that could be changed to make it
> easier,
> although nothing on the horizon yet.
> 
> best,
> 
> Robert Dodier
> 
> _______________________________________________
> Maxima mailing list
> Maxima <at> math.utexas.edu
> http://www.math.utexas.edu/mailman/listinfo/maxima
>

headers

Dennis Darland | 10 Aug 2012 04:33

Re: Warnings compiling

OK, I see mode_declare is used to declare variables and functions. I had not made sense of it before - I had
thought it was for functions and arguments. I could use it to get rid of the warnings and presumably speed
the program up it it is compiled. Does it do anything if the program is interpreted? It did not seem to, as I
had invalid ones and got no error. Are the variables local? I can figure this out by experimenting, but that
seems unnecessary. But I could not then use big floats, which I am not now, but would like to. I could try to
make it work both ways - that is one could choose either. I hope I am not asking too much, but some of this I wish
I had asked earlier.

Dennis J. Darland
dennis.darland <at> yahoo.com
http://dennisdarland.com/
http://dennisdarland.com/dennisdaze/
http://dennisdarland.com/philosophy/
http://sode.sourceforge.net/
"According to the World Health Organization, the warming of the planet caused an additional 140,000
deaths in 2004, as compared with the number of deaths there would have been had average global
temperatures remained as they were during the period 1961 to 1990. This means that climate change is
already causing, every week, as many deaths as occurred in the terrorist attacks on September 11, 2001"
-- Peter Singer _Practical Ethics, Third Edition_, p. 216.

--- On Thu, 8/9/12, Dennis Darland <dennis.darland <at> yahoo.com> wrote:

> From: Dennis Darland <dennis.darland <at> yahoo.com>
> Subject: [Maxima] Warnings compiling
> To: maxima <at> math.utexas.edu, "Robert Dodier" <robert.dodier <at> gmail.com>
> Date: Thursday, August 9, 2012, 7:40 PM
> Compiling I get many warnings about
> undefined variables. As I understand it 'define variable'
> defines global variables. Many of the variables I got
> warnings for I would not want to be global. Is there a way
> to define local variables? Others are arrays. The arrays
> worked as global OK when the code was being interpreted. I
> could not figure how to define arrays in define_variable
> either. That was some time ago. Also, the code ran even with
> the warnings, but was no faster. Also variables defined with
> 'define variable, were also listed. Perhaps because this was
> called in the main function, and the variables appeared in
> functions before it in the file.
> 
> Dennis J. Darland
> dennis.darland <at> yahoo.com
> http://dennisdarland.com/
> http://dennisdarland.com/dennisdaze/
> http://dennisdarland.com/philosophy/
> http://sode.sourceforge.net/
> "According to the World Health Organization, the warming of
> the planet caused an additional 140,000 deaths in 2004, as
> compared with the number of deaths there would have been had
> average global temperatures remained as they were during the
> period 1961 to 1990. This means that climate change is
> already causing, every week, as many deaths as occurred in
> the terrorist attacks on September 11, 2001"
> -- Peter Singer _Practical Ethics, Third Edition_, p. 216.
> 
> 
> --- On Thu, 8/9/12, Robert Dodier <robert.dodier <at> gmail.com>
> wrote:
> 
> > From: Robert Dodier <robert.dodier <at> gmail.com>
> > Subject: Re: [Maxima] Timing comparison for diffeq
> program in c++, Maple and Maxima
> > To: maxima <at> math.utexas.edu
> > Date: Thursday, August 9, 2012, 6:54 PM
> > On 2012-08-09, Dennis Darland <dennis.darland <at> yahoo.com>
> > wrote:
> > 
> > > I had a lot of trouble with arrays in maxima.
> > 
> > Yeah, arrays are difficult to work with. There are
> probably
> > some
> > relatively simple things that could be changed to make
> it
> > easier,
> > although nothing on the horizon yet.
> > 
> > best,
> > 
> > Robert Dodier
> > 
> > _______________________________________________
> > 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
>

headers

Robert Dodier | 10 Aug 2012 07:16

Re: Warnings compiling

On 2012-08-10, Dennis Darland <dennis.darland <at> yahoo.com> wrote:

> Compiling I get many warnings about undefined variables. As I
> understand it 'define variable' defines global variables. Many of the
> variables I got warnings for I would not want to be global. Is there
> a way to define local variables?

Well, as far as I know, the Maxima to Lisp translator complains about
variables which are neither function arguments nor local variables (as
in block([a, b, c], ...)). If you are getting complaints about such
variables, that seems like a bug. If you would provide examples it would
be helpful.

> Others are arrays. The arrays worked as global OK when the code was
> being interpreted. I could not figure how to define arrays in
> define_variable either.

There is something about arrays in the mode_declare documentation, but I
don't know to what extent the translator actually exploits that
information.

> Also, the code ran even with the warnings, but was no faster.

Not too surprising.

The long and the short of it is that Maxima is something of a mess as a
programming language. You will probably be less frustrated if you think
of programming in Maxima as more of an empirical exercise than logical.

FWIW

Robert Dodier

headers

Dennis Darland | 10 Aug 2012 09:03

Re: Warnings compiling

I had just supposed variables which were not global (from define variable) or function arguments were
local. Maybe I should look into block. My lisp is very rusty. I mainly used xlisp some with an amiga many
years ago.

Dennis J. Darland
dennis.darland <at> yahoo.com
http://dennisdarland.com/
http://dennisdarland.com/dennisdaze/
http://dennisdarland.com/philosophy/
http://sode.sourceforge.net/
"According to the World Health Organization, the warming of the planet caused an additional 140,000
deaths in 2004, as compared with the number of deaths there would have been had average global
temperatures remained as they were during the period 1961 to 1990. This means that climate change is
already causing, every week, as many deaths as occurred in the terrorist attacks on September 11, 2001"
-- Peter Singer _Practical Ethics, Third Edition_, p. 216.

--- On Fri, 8/10/12, Robert Dodier <robert.dodier <at> gmail.com> wrote:

> From: Robert Dodier <robert.dodier <at> gmail.com>
> Subject: Re: [Maxima] Warnings compiling
> To: maxima <at> math.utexas.edu
> Date: Friday, August 10, 2012, 12:16 AM
> On 2012-08-10, Dennis Darland <dennis.darland <at> yahoo.com>
> wrote:
> 
> > Compiling I get many warnings about undefined
> variables. As I
> > understand it 'define variable' defines global
> variables. Many of the
> > variables I got warnings for I would not want to be
> global. Is there
> > a way to define local variables?
> 
> Well, as far as I know, the Maxima to Lisp translator
> complains about
> variables which are neither function arguments nor local
> variables (as
> in block([a, b, c], ...)). If you are getting complaints
> about such
> variables, that seems like a bug. If you would provide
> examples it would
> be helpful.
> 
> > Others are arrays. The arrays worked as global OK when
> the code was
> > being interpreted. I could not figure how to define
> arrays in
> > define_variable either.
> 
> There is something about arrays in the mode_declare
> documentation, but I
> don't know to what extent the translator actually exploits
> that
> information.
> 
> > Also, the code ran even with the warnings, but was no
> faster.
> 
> Not too surprising.
> 
> The long and the short of it is that Maxima is something of
> a mess as a
> programming language. You will probably be less frustrated
> if you think
> of programming in Maxima as more of an empirical exercise
> than logical.
> 
> FWIW
> 
> Robert Dodier
> 
> _______________________________________________
> Maxima mailing list
> Maxima <at> math.utexas.edu
> http://www.math.utexas.edu/mailman/listinfo/maxima
>

headers

Stavros Macrakis | 10 Aug 2012 16:13

Re: Warnings compiling

Most programming languages require explicit declaration of local variables (other than function arguments), including all varieties of Lisp I'm aware of. A few do this implicitly for variables which are assigned to, e.g. Python and R. Maxima does not. See block([...],...) for Maxima.

I will repeat my advice of trying some smaller "finger exercises" before trying something big and ambitious like your ODE solver. Also, when you report problems, it is almost impossible for us to provide useful advice if all we have to go on is "Compiling I get many warnings about undefined variables" or a pointer to a multi-hundred line automatically generated code fragment without context (how is it run, how is it compiled, etc.).

Much more useful to provide a small and reproducible example of your problem. "Small" typically means 1-3 lines of code or at least some indication that you've made an effort to find the 'core' problem. "Reproducible" means that we can run your example and run into the problem; in particular, this means that the example should be self-contained, including any auxiliary functions (also reduced to a minimum) or data needed; it also means that you should report the version reported by bug_report. (We should probably put together a posting guide along the lines of the R-help posting guide -- though I don't aspire to R-help's tradition of viciously attacking clueless newbies.)

-s

On Fri, Aug 10, 2012 at 3:03 AM, Dennis Darland <dennis.darland <at> yahoo.com> wrote:

I had just supposed variables which were not global (from define variable) or function arguments were local. Maybe I should look into block. My lisp is very rusty. I mainly used xlisp some with an amiga many years ago.

Dennis J. Darland
dennis.darland <at> yahoo.com
http://dennisdarland.com/
http://dennisdarland.com/dennisdaze/
http://dennisdarland.com/philosophy/
http://sode.sourceforge.net/
"According to the World Health Organization, the warming of the planet caused an additional 140,000 deaths in 2004, as compared with the number of deaths there would have been had average global temperatures remained as they were during the period 1961 to 1990. This means that climate change is already causing, every week, as many deaths as occurred in the terrorist attacks on September 11, 2001"
-- Peter Singer _Practical Ethics, Third Edition_, p. 216.

--- On Fri, 8/10/12, Robert Dodier <robert.dodier <at> gmail.com> wrote:

> From: Robert Dodier <robert.dodier <at> gmail.com>

> Subject: Re: [Maxima] Warnings compiling
> To: maxima <at> math.utexas.edu
> Date: Friday, August 10, 2012, 12:16 AM
> On 2012-08-10, Dennis Darland <dennis.darland <at> yahoo.com>
> wrote:
>
> > Compiling I get many warnings about undefined
> variables. As I
> > understand it 'define variable' defines global
> variables. Many of the
> > variables I got warnings for I would not want to be
> global. Is there
> > a way to define local variables?
>
> Well, as far as I know, the Maxima to Lisp translator
> complains about
> variables which are neither function arguments nor local
> variables (as
> in block([a, b, c], ...)). If you are getting complaints
> about such
> variables, that seems like a bug. If you would provide
> examples it would
> be helpful.
>
> > Others are arrays. The arrays worked as global OK when
> the code was
> > being interpreted. I could not figure how to define
> arrays in
> > define_variable either.
>
> There is something about arrays in the mode_declare
> documentation, but I
> don't know to what extent the translator actually exploits
> that
> information.
>
> > Also, the code ran even with the warnings, but was no
> faster.
>
> Not too surprising.
>
> The long and the short of it is that Maxima is something of
> a mess as a
> programming language. You will probably be less frustrated
> if you think
> of programming in Maxima as more of an empirical exercise
> than logical.
>
> FWIW
>
> Robert Dodier
>
> _______________________________________________
> 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

headers

Steve Haflich | 10 Aug 2012 17:42

Re: Warnings compiling

Stavros Macrakis <macrakis <at> alum.mit.edu> wrote:

   Most programming languages require explicit declaration of local
   variables (other than function arguments), including all varieties of
   Lisp I'm aware of.  A few do this implicitly for variables which are
   assigned to, e.g. Python and R.  Maxima does not.

Two minor points (which are barely relevant to the discussion 

Common Lisp assigns no semantics whatever to a free (i.e. undeclared)
reference to a variable, but essentially every implementation treats the
variable implicitly as though it had been declared special in that
context.  Most warn, at least in the compiler.  This is because there is
a long history of Lisp dialects that provided _only_ special variables,
so no declarations were necessary or meaningful.

Your "except function arguments" distinction is not a real distinction.
Constructs such as LET that bind variables are really just semantic
sugar for the same kind of lambda binding that lambda functions do.

  (let ((y (* x x))
        (c (+ x 1)))
    ...)

is semantically equivalent to

  (apply (lambda (y c) ...)
         (* x x)
         (x (+ x 1)))

hence LET binding is sometimes confusingly called "lambda binding".  Of
course, implementations usually try to rewrite internal lambdas as lets
rather than the other way around.
_______________________________________________
Maxima mailing list
Maxima <at> math.utexas.edu
http://www.math.utexas.edu/mailman/listinfo/maxima

headers

Stavros Macrakis | 10 Aug 2012 23:52

Re: Warnings compiling

Steve,

Everything you say is true (and consistent with what I said), but not particularly helpful to the original poster.

-s

PS Exotic as it may seem, when I first started coding in Lisp (1970), 'let' didn't exist, and we wrote ((lambda (a) ...) ...) or (prog (a)...). Even with proper indentation, reading the correspondence between variables and values in the first case was clumsy, since they were separated by the body, but I felt virtuous because I was avoiding evil side-effect programming :-)

On Fri, Aug 10, 2012 at 11:42 AM, Steve Haflich <smh <at> franz.com> wrote:

Stavros Macrakis <macrakis <at> alum.mit.edu> wrote:

Most programming languages require explicit declaration of local
variables (other than function arguments), including all varieties of
Lisp I'm aware of. A few do this implicitly for variables which are
assigned to, e.g. Python and R. Maxima does not.

Two minor points (which are barely relevant to the discussion

Common Lisp assigns no semantics whatever to a free (i.e. undeclared)
reference to a variable, but essentially every implementation treats the
variable implicitly as though it had been declared special in that
context. Most warn, at least in the compiler. This is because there is
a long history of Lisp dialects that provided _only_ special variables,
so no declarations were necessary or meaningful.

Your "except function arguments" distinction is not a real distinction.
Constructs such as LET that bind variables are really just semantic
sugar for the same kind of lambda binding that lambda functions do.

(let ((y (* x x))
(c (+ x 1)))
...)

is semantically equivalent to

(apply (lambda (y c) ...)
(* x x)
(x (+ x 1)))

hence LET binding is sometimes confusingly called "lambda binding". Of
course, implementations usually try to rewrite internal lambdas as lets
rather than the other way around.

_______________________________________________
Maxima mailing list
Maxima <at> math.utexas.edu
http://www.math.utexas.edu/mailman/listinfo/maxima

headers

Rupert Swarbrick | 9 Aug 2012 17:31

Re: Timing comparison for diffeq program in c++, Maple and Maxima

Dennis Darland <dennis.darland <at> yahoo.com> writes:
> I am using just basic math like you say. In maple I can use higher
> precision floating point by setting "Digits". (Though it only seems to
> work up to about 32 digits). I expected to be able to do something
> similar in Maxima. Maxima does have "big floats". I tried them, but,
> as far as I could tell, they did not support trig functions, etc. (You
> only get about 16 digits and a lot of warning messages). 

Maybe you can give an example of how you ended up with warning messages?
If you want more than 16 digits of precision, look at the fpprec
variable.

> If big floats can me made to support trig functions, etc., I would
> like to know about it. I plan to look also for a c++ library for
> extended precision floating point numbers. I am also interested in
> what is called "interval arithmetic."

As far as I know, Maxima doesn't have interval arithmetic built in. It
seems to have been a "nice to have" project for many years.

> I also used Maxima as well as Maple as it is more affordable, and I
> like to support open source. I am not trying to criticize Maple or
> Maxima, only to ascertain the facts. It is interesting that c++ is so
> much faster, in that it makes solving some problems more practical.

C++ is indeed much faster at basic arithmetic. But the languages of
Maxima and Maple aren't really designed for that. You'll probably find
Matlab and Octave to be slower than C/C++ but faster than Maple: if
you're trying to do numerics, they might actually be more suitable than
Maxima.

I'm not sure whether Maxima/Maple could be more help for what you're
doing, but currently you aren't using either in a way that they really
shine.

> The reason I started subscripts at 1 was Dr Chang's work started
> subscripts at 1, and thus it was a lot easier. I used the formulas
> from his draft of a book he started. He was working in FORTRAN, but my
> program is not at all a translation of his program. (He wrote as
> program in FORTRAN which generated a FORTRAN program,) His program is
> beyond my comprehension.  Also other languages I may want to use in
> the future may not permit "0" subscripts. I doubt I will ever support
> FORTRAN.

I presume this was in reply to my comment that your code looked like
FORTRAN. I wasn't being that specific to be honest: I just thought I
should include a language that wasn't from the C family.

Rupert

_______________________________________________
Maxima mailing list
Maxima <at> math.utexas.edu
http://www.math.utexas.edu/mailman/listinfo/maxima

headers

Richard Fateman | 9 Aug 2012 18:33

Re: Timing comparison for diffeq program in c++, Maple and Maxima

On 8/9/2012 7:18 AM, Dennis Darland wrote:
> I am using just basic math like you say. In maple I can use higher precision floating point by setting
"Digits". (Though it only seems to work up to about 32 digits). I expected to be able to do something similar
in Maxima. Maxima does have "big floats". I tried them, but, as far as I could tell, they did not support trig
functions, etc. (You only get about 16 digits and a lot of warning messages).
bigfloats work with trig functions, but the compiler works on (declared) 
machine floats.

>    If  big floats can me made to support trig functions, etc., I would like to know about it.
Sure. don't compile that part.
>   I plan to look also for a c++ library for extended precision floating point numbers.
There are libraries for quad double and also arbitrary precision like MPFR.
I doubt that these are really the first port of call for improving the 
code for this application (solving ODEs)
>   I am also interested in what is called "interval arithmetic."
Same comment.
>
> I also used Maxima as well as Maple as it is more affordable, and I like to support open source. I am not trying
to criticize Maple or Maxima, only to ascertain the facts. It is interesting that c++ is so much faster, in
that it makes solving some problems more practical.
If your program is oriented toward producing C code, then it is quite 
reasonable to
expect that the C code it produces will run fastest with a C compiler, 
and simulating
this environment on Maxima or Maple can be quite slow unless those 
programs can
take advantage of the knowledge that "everything is simply a number"  and no
symbolic computation at all should happen.
>
> The program was debugged in Maple and Maxima together. Both, in some cases gave better error messages than
the other. I doubt I could have debugged it in c or c++, which most likely have crashed instead of giving an
error message. (The code to generate c or c++ is not released yet, as I am just beginning to test it, but it
seems to work OK so far)
>
> The reason I started subscripts at 1 was Dr Chang's work started subscripts at 1, and thus it was a lot
easier. I used the formulas from his draft of a book he started. He was working in FORTRAN, but my program is
not at all a translation of his program. (He wrote as program in FORTRAN which generated a FORTRAN
program,) His program is beyond my comprehension.  Also other languages I may want to use in the future may
not permit "0" subscripts. I doubt I will ever support FORTRAN.
>
> Dennis J. Darland
> dennis.darland <at> yahoo.com
> http://dennisdarland.com/
> http://dennisdarland.com/dennisdaze/
> http://dennisdarland.com/philosophy/
> http://sode.sourceforge.net/
> "According to the World Health Organization, the warming of the planet caused an additional 140,000
deaths in 2004, as compared with the number of deaths there would have been had average global
temperatures remained as they were during the period 1961 to 1990. This means that climate change is
already causing, every week, as many deaths as occurred in the terrorist attacks on September 11, 2001"
> -- Peter Singer _Practical Ethics, Third Edition_, p. 216.
>
>
> --- On Thu, 8/9/12, Rupert Swarbrick <rswarbrick <at> gmail.com> wrote:
>
>> From: Rupert Swarbrick <rswarbrick <at> gmail.com>
>> Subject: Re: [Maxima] Timing comparison for diffeq program in c++, Maple and Maxima
>> To: maxima <at> math.utexas.edu
>> Date: Thursday, August 9, 2012, 7:32 AM
>> Dennis Darland <dennis.darland <at> yahoo.com>
>> writes:
>>> I ran a timing test comparison for c++, Maple and
>> Maxima.
>>> All three programs generated by omnisode - a set of
>> Ruby programs.
>>> Set time limit to 1 minute.
>>> Maximum iteration was sufficient to solve entire
>> problem.
>>> Problem was sin.ode for all three.
>>> Output was redirected to file only - none to screen
>>> Results:
>>> c++ solved entire problem in 23 seconds (140001
>> iterations)
>>> Maple performed 11542 iterations in 60 seconds
>>> Maxima performed 372 iterations in 60 seconds
>>> That amounts to:
>>> c++ 6,087 iterations/second
>>> Maple 192 iterations/second
>>> Maxima 6.2 iterations/second
>>> c++ is almost 32 times faster than Maple which is
>> almost 31 times faster than Maxima.
>>> So c++ is almost 982 times faster than Maxima.
>>>
>>> More info on omnisode at:
>>> http://sode.sourceforge.net/
>> Right, I just tried to look up the Maxima code you're
>> generating and
>> found things like [1]. Since I'm clearly not going to read
>> through that
>> carefully, and I presume no-one else is either, can you
>> explain exactly
>> what you're measuring?
>>
>> Your code looks to me like a C/FORTRAN program translated
>> to
>> Maxima. Unsurprisingly, it runs very slowly. What are you
>> actually
>> trying to do? What capabilities of Maple or Maxima are you
>> using other
>> than basic arithmetic?
>>
>> Or should we interpret your message as
>>
>>    "Writing bare-metal calculations in Maple and running
>> them is
>>     marginally less slow that writing them in
>> Maxima and running
>>     them. But it would have been easier to do
>> it in C anyway"
>>
>>   ?
>>
>>
>> Rupert
>>
>> [1] http://sode.sourceforge.net/omniresults/special_cases_007/diffeq.tan_sqrt_lin.mxt.txt
>>
>> -----Inline Attachment Follows-----
>>
>> _______________________________________________
>> 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

headers

Dennis Darland | 10 Aug 2012 00:51

Re: Timing comparison for diffeq program in c++, Maple and Maxima

I got bfloats to work with trig function. Same answer with Maple and Maxima anyway with 50 digits. C++
doesn't have that, but I suppose there are probably libraries for C++. Would take some work to implement in
omnisode. The built-in help was more useful than the manual had been. 

Dennis J. Darland
dennis.darland <at> yahoo.com
http://dennisdarland.com/
http://dennisdarland.com/dennisdaze/
http://dennisdarland.com/philosophy/
http://sode.sourceforge.net/
"According to the World Health Organization, the warming of the planet caused an additional 140,000
deaths in 2004, as compared with the number of deaths there would have been had average global
temperatures remained as they were during the period 1961 to 1990. This means that climate change is
already causing, every week, as many deaths as occurred in the terrorist attacks on September 11, 2001"
-- Peter Singer _Practical Ethics, Third Edition_, p. 216.

--- On Thu, 8/9/12, Richard Fateman <fateman <at> eecs.berkeley.edu> wrote:

> From: Richard Fateman <fateman <at> eecs.berkeley.edu>
> Subject: Re: [Maxima] Timing comparison for diffeq program in c++, Maple and Maxima
> To: "Dennis Darland" <dennis.darland <at> yahoo.com>
> Cc: maxima <at> math.utexas.edu, "Rupert Swarbrick" <rswarbrick <at> gmail.com>
> Date: Thursday, August 9, 2012, 11:33 AM
> On 8/9/2012 7:18 AM, Dennis Darland
> wrote:
> > I am using just basic math like you say. In maple I can
> use higher precision floating point by setting "Digits".
> (Though it only seems to work up to about 32 digits). I
> expected to be able to do something similar in Maxima.
> Maxima does have "big floats". I tried them, but, as far as
> I could tell, they did not support trig functions, etc. (You
> only get about 16 digits and a lot of warning messages).
> bigfloats work with trig functions, but the compiler works
> on (declared) 
> machine floats.
> 
> >    If  big floats can me made to support
> trig functions, etc., I would like to know about it.
> Sure. don't compile that part.
> >   I plan to look also for a c++ library
> for extended precision floating point numbers.
> There are libraries for quad double and also arbitrary
> precision like MPFR.
> I doubt that these are really the first port of call for
> improving the 
> code for this application (solving ODEs)
> >   I am also interested in what is called
> "interval arithmetic."
> Same comment.
> >
> > I also used Maxima as well as Maple as it is more
> affordable, and I like to support open source. I am not
> trying to criticize Maple or Maxima, only to ascertain the
> facts. It is interesting that c++ is so much faster, in that
> it makes solving some problems more practical.
> If your program is oriented toward producing C code, then it
> is quite 
> reasonable to
> expect that the C code it produces will run fastest with a C
> compiler, 
> and simulating
> this environment on Maxima or Maple can be quite slow unless
> those 
> programs can
> take advantage of the knowledge that "everything is simply a
> number"  and no
> symbolic computation at all should happen.
> >
> > The program was debugged in Maple and Maxima together.
> Both, in some cases gave better error messages than the
> other. I doubt I could have debugged it in c or c++, which
> most likely have crashed instead of giving an error message.
> (The code to generate c or c++ is not released yet, as I am
> just beginning to test it, but it seems to work OK so far)
> >
> > The reason I started subscripts at 1 was Dr Chang's
> work started subscripts at 1, and thus it was a lot easier.
> I used the formulas from his draft of a book he started. He
> was working in FORTRAN, but my program is not at all a
> translation of his program. (He wrote as program in FORTRAN
> which generated a FORTRAN program,) His program is beyond my
> comprehension.  Also other languages I may want to use
> in the future may not permit "0" subscripts. I doubt I will
> ever support FORTRAN.
> >
> > Dennis J. Darland
> > dennis.darland <at> yahoo.com
> > http://dennisdarland.com/
> > http://dennisdarland.com/dennisdaze/
> > http://dennisdarland.com/philosophy/
> > http://sode.sourceforge.net/
> > "According to the World Health Organization, the
> warming of the planet caused an additional 140,000 deaths in
> 2004, as compared with the number of deaths there would have
> been had average global temperatures remained as they were
> during the period 1961 to 1990. This means that climate
> change is already causing, every week, as many deaths as
> occurred in the terrorist attacks on September 11, 2001"
> > -- Peter Singer _Practical Ethics, Third Edition_, p.
> 216.
> >
> >
> > --- On Thu, 8/9/12, Rupert Swarbrick <rswarbrick <at> gmail.com>
> wrote:
> >
> >> From: Rupert Swarbrick <rswarbrick <at> gmail.com>
> >> Subject: Re: [Maxima] Timing comparison for diffeq
> program in c++, Maple and Maxima
> >> To: maxima <at> math.utexas.edu
> >> Date: Thursday, August 9, 2012, 7:32 AM
> >> Dennis Darland <dennis.darland <at> yahoo.com>
> >> writes:
> >>> I ran a timing test comparison for c++, Maple
> and
> >> Maxima.
> >>> All three programs generated by omnisode - a
> set of
> >> Ruby programs.
> >>> Set time limit to 1 minute.
> >>> Maximum iteration was sufficient to solve
> entire
> >> problem.
> >>> Problem was sin.ode for all three.
> >>> Output was redirected to file only - none to
> screen
> >>> Results:
> >>> c++ solved entire problem in 23 seconds
> (140001
> >> iterations)
> >>> Maple performed 11542 iterations in 60 seconds
> >>> Maxima performed 372 iterations in 60 seconds
> >>> That amounts to:
> >>> c++ 6,087 iterations/second
> >>> Maple 192 iterations/second
> >>> Maxima 6.2 iterations/second
> >>> c++ is almost 32 times faster than Maple which
> is
> >> almost 31 times faster than Maxima.
> >>> So c++ is almost 982 times faster than Maxima.
> >>>
> >>> More info on omnisode at:
> >>> http://sode.sourceforge.net/
> >> Right, I just tried to look up the Maxima code
> you're
> >> generating and
> >> found things like [1]. Since I'm clearly not going
> to read
> >> through that
> >> carefully, and I presume no-one else is either, can
> you
> >> explain exactly
> >> what you're measuring?
> >>
> >> Your code looks to me like a C/FORTRAN program
> translated
> >> to
> >> Maxima. Unsurprisingly, it runs very slowly. What
> are you
> >> actually
> >> trying to do? What capabilities of Maple or Maxima
> are you
> >> using other
> >> than basic arithmetic?
> >>
> >> Or should we interpret your message as
> >>
> >>    "Writing bare-metal calculations in
> Maple and running
> >> them is
> >>     marginally less slow that
> writing them in
> >> Maxima and running
> >>     them. But it would have
> been easier to do
> >> it in C anyway"
> >>
> >>   ?
> >>
> >>
> >> Rupert
> >>
> >> [1] http://sode.sourceforge.net/omniresults/special_cases_007/diffeq.tan_sqrt_lin.mxt.txt
> >>
> >> -----Inline Attachment Follows-----
> >>
> >> _______________________________________________
> >> 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
> 
>

headers

Robert Dodier | 9 Aug 2012 17:54

Re: Timing comparison for diffeq program in c++, Maple and Maxima

On 2012-08-09, Dennis Darland <dennis.darland <at> yahoo.com> wrote:

> I ran a timing test comparison for c++, Maple and Maxima.
> All three programs generated by omnisode - a set of Ruby programs.

> c++ 6,087 iterations/second
> Maple 192 iterations/second
> Maxima 6.2 iterations/second

Thanks, Dennis. I see some defensive comments elsewhere in this thread,
but I see these as simple facts, without judgement. In order to make
informed decisions, one must know the facts. If using Maxima means I can
avoid C++, that could be a very worthwhile trade ....

Thanks for your interest in Maxima, and keep up the good work.

Robert Dodier