19562 Reputation

29 Badges

14 years, 317 days

Social Networks and Content at

MaplePrimes Activity

These are Posts that have been published by acer

I see two recent items on the web about Mathematica and the site. One was a Wolfram Inc. corporate blog post, and the other a post on Wolfram's relatively new community site.

There are many items on the page of tasks still without a submitted Maple implementation. It would be nice to see interesting implementations of some remaining tasks, as contributions from the Maple user base. The tasks remaining are of very mixed difficulty levels.

To date there are only 132 entries on the page for Maple implementations of that site's programming tasks. (Of these about 40 were submitted by one member while about 80 were submitted by another member.)


Some years ago member William Fish started a long discussion in part about a numeric integral involving high parameter (high oscillation) Bessel J0. That numeric integration task appeared in a Bitwise Magazine article.

At that time even obtaining numeric results involved extra effort such as handling real and imaginary components of the integrand separately, and requesting particular methods (sometimes hacked, to bump up the subinterval limit, for very high parameter values).

That led to a post where I showed that the result could be obtained quickly by using a fast compiled BesselJ (J0) from an external library along with a modified low-level call to a particular evalf/Int solver.

And sometime after that a numeric result for the real & imaginary split integrand became much more readily (if not quickly) available by using a new `maxintervals` option of evalf/Int to specify the maximal number of subintervals for the particular solver.

Maple 18 has its own compiled implementations of the Bessel functions for "hardware" (double) precision arguments. So now the numeric evaluations of the integrand are computed much faster.

Using Maple 18.00 on 64bit Windows 7 the same numeric results obtain in under a second, in a simple, single call to evalf,Int.


  evalf(Int(BesselJ(0, 50001*x)*x*exp(I*(355*x^2*1/2)), x = .35 .. 1))
memory used=9.28MiB, alloc change=32.00MiB, cpu time=437.00ms, real time=441.00ms, gc time=0ns

                           -8                 -8  
             3.181753502 10   - 7.798301124 10   I


  evalf(Int(BesselJ(0, 10000*x)*x*exp(I*(355*x^2*1/2)), x = .35 .. 1))
memory used=6.83MiB, alloc change=32.00MiB, cpu time=218.00ms, real time=211.00ms, gc time=15.60ms

                            -7                 -7  
             -2.007752340 10   + 4.275388462 10   I


Of course the ramifications of fast, compiled Bessel functions at double precision extend much farther than just this one example. But I like seeing the speed improvement in terms of a concrete example.


For some time I have been running into the problem where uploaded worksheets that are inlined into a Mapleprimes post get gridlines shown, even when they are not specified or shown in the original worksheet. This is a problem because quite often the gridlines make an inlined plot unattractive.

I believe that Mapleprimes uses some version of MapleNet as a mechanism for inlining uploaded worksheets.

It seems that the Standard GUI and/or MapleNet have special handling for gridlines in the sense that they actually distinguish between PLOT structures generated without the `gridlines` option versus those created with `gridlines=false`.  I believe that this has something to do with the persistence of various plot qualities in an output region which (perhaps for historical reasons?)  allow re-execution of a plot input command to produce a plot output rendering that remembers whether gridlines are visible.

If the second plot below does indeed get rendered here in Primes without gridlines visible then one workaround is evident: adding `gridlines=false` instead of omitting the option.





I'll submit a bug report against MapleNet.


At some point a version of the Maple Player (for the PC, rather than iPad) became available for download from its webpage.

The following (downsized) images of Lyapunov fractals were each generated in a few seconds, in Maple 16.


I may make an interface for this with embedded components, or submit it in some form on the Application Center. But I thought that I'd share this version here first.

I'm just re-using the techniques in the code behind an earlier Post on Mandelbrot and Julia fractals. But I've only used one simple coloring scheme here, so far. I'll probably try the so-called burning ship escape-time fractal next.





Here below is the contents of the worksheet attached at the end of this Post.



The procedures are defined in the Startup code region of this worksheet.


It should run in Maple 15 and 16, but may not work in earlier versions since it relies on a properly functioning Threads:-Task.


The procedure `Lyapunov` can be called as


          Lyapunov(W, xa, xb, ya, yb, xresolution)

          Lyapunov(W, xa, xb, ya, yb, xresolution, numterms=N)


where those parameters are,


 - W, a Vector or list whose entries should be only 0 or 1

 - xa, the leftmost x-point (a float, usually greater than 2.0)

 - xb, the rightmost x-point (a float, usually less than or equal to 4.0)

 - ya, the lowest y-point (a float, usually greater than 2.0)

 - yb, the highest y-point (a float, usually less than or equal to 4.0)

 - xresolution, the width in pixels of the returned image (Array)

 - numterms=N, (optional) where positive integer N is the number of terms added for the approx. Lyapunov exponent



The speed of calculation depends on whether the Compiler  is functional and how many cores are detected. On a 4-core Intel i7 under Windows 7 the first example below had approximately the following performce in 64bit Maple 16.





serial (1 core)

20 seconds

240 seconds

parallel (4 cores)

5 seconds

60 seconds





res1:=CodeTools:-Usage( Lyapunov(W, 2.01, 4.0, 2.01, 4.0, 500) ):

memory used=46.36MiB, alloc change=65.73MiB, cpu time=33.87s, real time=5.17s


res2:=CodeTools:-Usage( Lyapunov(W, 2.5, 3.4, 3.4, 4.0, 500) ):

memory used=30.94MiB, alloc change=0 bytes, cpu time=21.32s, real time=3.54s


res3:=CodeTools:-Usage( Lyapunov(W, 2.1, 3.7, 3.1, 4.0, 500) ):

memory used=26.18MiB, alloc change=15.09MiB, cpu time=18.44s, real time=2.95s


res4:=CodeTools:-Usage( Lyapunov(W, 2.01, 4.0, 2.01, 4.0, 500) ):

memory used=46.25MiB, alloc change=15.09MiB, cpu time=33.52s, real time=5.18s





1 2 3 4 5 6 7 Last Page 3 of 29