MaplePrimes Commons General Technical Discussions

Extension of getdata

by: Markiyan Hirnyk 7809 Product: Maple

April 03 2012

2 4

Starting from Maple 15, the useful ?plottools/getdata command is added. It tansforms a Maple plot to a Matrix. Unfortunately, the getdata command deals only with Maple plots. The question arises: "How to get a data from bmp, jpg, tiff, pcx, gif, png and wmf formats?" This is used in medicine and engineering. Such question was asked here

MRB Constant V

by: Marvin Ray Burns 550 Product: Maple

March 23 2012

0 2

The*MRB*constant = sum((-1)^n*(n^(1/n)-1), n = 1 .. infinity) and sum((-1)^n*(n^(1/n)-1), n = 1 .. infinity) = sum((-1)^n*(n^(1/n)-1), n = 2 .. infinity)

But what can we say about

(∏)(-1)^(n)*(n^(1/(n))-1)?

Maple does not evaluate it:

evalf(product((-1)^n*(n^(1/n)-1), n = 2 .. infinity))

product: Cannot show that (-1)^n*(n^(1/n)-1) has no zeros on [2,infinity] product((-1)^n*(n^(1/n)-1), n = 2 .. infinity)

(1)

And perhaps it should not because of the alternating sign;

evalf(product((-1)^n*(n^(1/n)-1), n = 2 .. 10^2))

(2)

evalf(product((-1)^n*(n^(1/n)-1), n = 2 .. 10^3))

(3)

evalf(product((-1)^n*(n^(1/n)-1), n = 2 .. 10^3+1))

(4)

Download 3232012.mw

MRB constant U

by: Marvin Ray Burns 550 Product: Maple

March 18 2012

0 0

If you use all the convergents of the simple continued fraction of the MRB constant as the terms of a generalized continued fraction, then likewise use the new convergents in another generalized continued fraction, and so on... you arrive at 0.5557531.... For more on this process see https://oeis.org/wiki/Convergents_constant .

One more argument for long double

by: icegood 290 Product: Maple

February 01 2012

1 20

If there are still doubts to support "long double" in evalhf then there is one more argument to implement them in at least those machines that support it:
CalcInEvalhfFast.mw

P.S. In that well-known holy war about long double supporting in compilers i'm rather on side of "to support them" than on side of (stupid) microsoft visual c++ compiler.

animation of 3D plot rotation

by: acer 32016 Product: Maple 15

January 24 2012

9 6

Suppose that you wish to animate the whole view of a plot. By whole view, I mean that it includes the axes and is not just a rotation of a plotted object such as a surface.

One simple way to do this is to call plots:-animate (or plots:-display on a list of plots supplied in a list, with its `insequence=true` option). The option `orientation` would contain the parameter that governs the animation (or generates the sequence).

But that entails recreating the same plot each time. The plot data might not even change. The key thing that changes is the ORIENTATION() descriptor within each 3d plot object in the reulting data structure. So this is inefficient in two key ways, in the worst case scenario.

1) It may even compute the plot's numeric results, as many times as there are frames in the resulting animation.

2) It stores as many instances of the grid of computed numeric data as there are frames.

We'd like to do better, if possible, reducing down to a single computation of the data, and a single instance of storage of a grid of data.

To keep this understandable, I'll consider the simple case of plotting a single 3d surface. More complicated cases can be handled with revisions to the techniques.

Avoiding problem 1) can be done in more than one way. Instead of plotting an expression, a procedure could be plotted, where that procedure has `option remember` so that it automatically stores computed results an immediately returns precomputed stored result when the arguments (x and y values) have been used already.

Another way to avoid problem 1) is to generate the unrotated plot once, and then to use plottools:-rotate to generate the other grids without necessitating recomputation of the surface. But this rotates only objects in the plot, and does alter the view of the axes.

But both 1) and 2) can be solved together by simply re-using the grid of computed data from an initial plot3d call, and then constructing each frame's plot data structure component "manually". The only thing that has to change, in each, is the ORIENTATION(...) subobject.

At 300 frames, the difference in the following example (Intel i7, Windows 7 Pro 64bit, Maple 15.01) is a 10-fold speedup and a seven-fold reduction is memory allocation, for the creation of the animation structure. I'm not inlining all the plots into this post, as they all look the same.

restart:
P:=1+x+1*x^2-1*y+1*y^2+1*x*y:

st,ba:=time(),kernelopts(bytesalloc):

plots:-animate(plot3d,[P,x=-5..5,y=-5..5,orientation=[A,45,45],
                       axes=normal,labels=[x,y,z]],
               A=0..360,frames=300);

time()-st,kernelopts(bytesalloc)-ba;

                                1.217, 25685408

restart:
P:=1+x+1*x^2-1*y+1*y^2+1*x*y:

st,ba:=time(),kernelopts(bytesalloc):

g:=plot3d(P,x=-5..5,y=-5..5,orientation=[-47,666,-47],
          axes=normal,labels=[x,y,z]):

plots:-display([seq(PLOT3D(GRID(op([1,1..2],g),op([1,3],g)),
                           remove(type,[op(g)],
                                  specfunc(anything,{GRID,ORIENTATION}))[],
                           ORIENTATION(A,45,45)),
                    A=0..360,360.0/300)],
               insequence=true);

time()-st,kernelopts(bytesalloc)-ba;

                                0.125, 3538296

By creating the entire animation data structure manually, we can get a further factor of 3 improvement in speed and a further factor of 3 reduction in memory allocation.

restart:
P:=1+x+1*x^2-1*y+1*y^2+1*x*y:

st,ba:=time(),kernelopts(bytesalloc):

g:=plot3d(P,x=-5..5,y=-5..5,orientation=[-47,666,-47],
          axes=normal,labels=[x,y,z]):

PLOT3D(ANIMATE(seq([GRID(op([1,1..2],g),op([1,3],g)),
                           remove(type,[op(g)],
                                  specfunc(anything,{GRID,ORIENTATION}))[],
                           ORIENTATION(A,45,45)],
                    A=0..360,360.0/300)));

time()-st,kernelopts(bytesalloc)-ba;

                                0.046, 1179432

Unfortunately, control over the orientation is missing from Plot Components, otherwise such an "animation" could be programmed into a Button. That might be a nice functionality improvement, although it wouldn't be very nice unless accompanied by a way to export all a Plot Component's views to GIF (or mpeg!).

The above example produces animations each of 300 frames. Here's a 60-frame version:

MRB constant T

by: Marvin Ray Burns 550 Product: Maple

January 13 2012

0 2

Let c=MRB constant -1/2

MRB constant S part 2

by: Marvin Ray Burns 550 Product: Maple

January 08 2012

0 0

>

Define s as the following function involving a divergent series.

>

proc (x) options operator, arrow; sum((-1)^n*n^(1/n), n = 1 .. x) end proc

(1)

The upper limit point of the partial sums, of s is very slowly convergent.

>

(2)

>

(3)

>

(4)

Let mrb be tthe upper limit point of s as x goes to infinity.

>

(5)

Define f as the following function involving the divergnet series

>

proc (a) options operator, arrow; sum((-1)^n*(n^(a/n)-a), n = 1 .. infinity) end proc

(6)

Let c be the value for a in the neighborhood of 26 such that f(a)=mrb.

(7)

The average of the upper and lower limit points of the partil sums of f converges much faster than the upper limit point of the partial sums of s.

>

evalf((sum((-1)^n*(n^(c/n)-c), n = 1 .. 100)+sum((-1)^n*(n^(c/n)-c), n = 1 .. 101))*(1/2))

(8)

>

evalf((sum((-1)^n*(n^(c/n)-c), n = 1 .. 1000)+sum((-1)^n*(n^(c/n)-c), n = 1 .. 1001))*(1/2))

(9)

>

evalf((sum((-1)^n*(n^(c/n)-c), n = 1 .. 10000)+sum((-1)^n*(n^(c/n)-c), n = 1 .. 10001))*(1/2))

(10)

Download Jan72012.mw

Computable Document Format - wasn't Maple first?

by: Christopher2222 5960

January 04 2012

1 1

If I'm not mistaken Maple already had technical interactive documents. And Mathematica introduced cdf only in mid 2011, however why is there so much hype about cdf and media coverage about it replacing pdf's. Of course it differs by one letter and probably done so by design. And if pdf is so popular, then so might cdf be in the future. Pretty slick and trick marketing by Wolfram if you ask me.

Also Maple released the maple Player in...

MRB constant S

by: Marvin Ray Burns 550 Product: Maple

January 02 2012

0 15

Download jan022012.mw

MRB constant R

by: Marvin Ray Burns 550 Product: Maple

January 01 2012

0 0

easier background plot color

by: acer 32016 Product: Maple

December 22 2011

1 4

I wanted to set the background color of a plot to black (without axes shown) and figured I could add this to the PLOT structure: POLYGONS([[10,0],[0,0],[0,10],[10,10]],COLOUR(RGB, 0., 0., 0.))

And that worked fine. But I feel that it ought to be easier.

logistic map example

by: PatrickT 2163 Product: Maple

December 13 2011

7 19

Here's an example exhibited by Nusc, which I have tweaked slightly to make it look more like your mathematica example.

### Reference: http://www.mapleprimes.com/questions/36580-Bifurcation-Diagram

### xexpr is the logistic function to be iterated (we always start off at x=1/2, which will eventually attract).
### [ra,rb] is the range of the parameter.
### acc is the number of points sampled in [ra,rb]

Bifurcation := proc(initialpoint,xexpr,ra,rb,acc)

thickening 2D plot axes

by: acer 32016 Product: Maple 15

December 12 2011

7 3

It is possible to thicken the axes of 2D plots by adjusting the underlying data structure, since the appropriately placed THICKNESS() call within the PLOT() data structure is recognized by the Standard GUI. This does not seem to be recognized for PLOT3D structures, however.

The issue of obtaining thicker axes for 2D plots can then be resolved by first creating a plot, and then subsequently modifying the PLOT structure.

The same techniques could be used to thin...

MRB constant Q

by: Marvin Ray Burns 550 Product: Maple

December 11 2011

0 3

Download 10102011.mw

As defined at http://mathworld.wolfram.com/MRBConstant.html the MRB constant is

OMP_NUM_THREADS and 64bit Maple on Windows

by: Dave L 527 Product: Maple

December 10 2011

5 1

Yesterday I wrote a post that began,

"I realized recently that, while 64bit Maple 15 on Windows (XP64, 7) is now using accelerated BLAS from Intel's MKL, the Operating System environment variable OMP_NUM_THREADS is not being set automatically."

But that first sentence is about where it stopped being correct, as far as how I was interpreting the performance on 64bit Maple on Windows. So I've rewritten the whole post, and this is the revision.

I concluded that, by setting the Windows operating system environment variable OMP_NUM_THREADS to 4, performance would double on a quad core i7. I even showed timings to help establish that. And since I know that memory management and dynamic linking can cause extra overhead, I re-ran all my examples in freshly launched GUI sessions, with the user-interface completely closed between examples. But I got caught out in a mistake, nonetheless. The problem was that there is extra real-time cost to having my machine's Windows operating system dynamically open the MKL dll the very first time after bootup.

So my examples done first after bootup were at a disadvantage. I knew that I could not look just at measured cpu time, since for such threaded applications that reports as some kind of sum of cycles for all threads. But I failed to notice the real-time measurements were being distorted by the cost of loading the dlls the first time. And that penalty is not necessarily paid for each freshly launched, completely new Maple session. So my measurements were not fair.

Here is some illustration of the extra real-time cost, which I was not taking into account. I'll do Matrix-Matrix multiplication for a 1x1 example, to try and show just how much this extra cost is unrelated to the actual computation. In these examples below, I've done a full reboot on Windows 7 where so annotated. The extra time cost for the very first load of the dynamic MKL libraries can be from 1 to over 3 seconds. That's about the same as the cpu time this i7 takes to do the full 3000x3000 Matrix multiplication! Hence the confusion.

Roman brought up hyperthreading in his comment on the original post. So part of redoing all these examples, with full restarts between them, is testing each case both with and without hyperthreading enabled (in the BIOS).

Quad core Intel i7. (four physical cores)

Hyperthreading disabled in BIOS
-------------------------------

> restart: # actual OS reboot
> getenv(OMP_NUM_THREADS);   # NULL, unset in OS

> CodeTools:-Usage( Matrix([[3.]]) . Matrix([[3.]]) ): # initialize external libs
memory used=217.18KiB, alloc change=127.98KiB, cpu time=219.00ms, real time=3.10s

> CodeTools:-Usage( Matrix([[3.]]) . Matrix([[3.]]) ):
memory used=9.46KiB, alloc change=0 bytes, cpu time=0ns, real time=0ns


> restart: # actual OS reboot
> getenv(OMP_NUM_THREADS);
                              "4"

> CodeTools:-Usage( Matrix([[3.]]) . Matrix([[3.]]) ): # initialize external libs
memory used=216.91KiB, alloc change=127.98KiB, cpu time=140.00ms, real time=2.81s

> CodeTools:-Usage( Matrix([[3.]]) . Matrix([[3.]]) ):
memory used=9.46KiB, alloc change=0 bytes, cpu time=0ns, real time=0ns


Hyperthreading enabled in BIOS
------------------------------

> restart: # actual OS reboot
> getenv(OMP_NUM_THREADS);    # NULL, unset in OS

> CodeTools:-Usage( Matrix([[3.]]) . Matrix([[3.]]) ): # initialize external libs
memory used=217.00KiB, alloc change=127.98KiB, cpu time=202.00ms, real time=2.84s

> CodeTools:-Usage( Matrix([[3.]]) . Matrix([[3.]]) ):
memory used=9.46KiB, alloc change=0 bytes, cpu time=0ns, real time=0ns


> restart: # actual OS reboot
> getenv(OMP_NUM_THREADS);
                              "4"

> CodeTools:-Usage( Matrix([[3.]]) . Matrix([[3.]]) ): # initialize external libs
memory used=215.56KiB, alloc change=127.98KiB, cpu time=187.00ms, real time=1.12s

> CodeTools:-Usage( Matrix([[3.]]) . Matrix([[3.]]) ):
memory used=9.46KiB, alloc change=0 bytes, cpu time=0ns, real time=0ns

Having established that the first use after reboot was incurring a real time penalty of a few seconds, I redid the timings in order to gauge the benefit of having OMP_NUM_THREADS set appropriately. These too were done with and without hyperthreading enabled. The timings below appear to indicate that slightly bettern performance can be had for this example in the case that hyperthreading is disabled. The timings also appear to indicate that having OMP_NUM_THREADS unset results in performance competitive with having it set to the number of physical cores.

Hyperthreading disabled in BIOS
-------------------------------

> restart:
> CodeTools:-Usage( Matrix([[3.]]) . Matrix([[3.]]) ): # initialize external libs
memory used=217.84KiB, alloc change=127.98KiB, cpu time=141.00ms, real time=142.00ms

> getenv(OMP_NUM_THREADS);  # NULL, unset in OS

> M:=LinearAlgebra:-RandomMatrix(3000,datatype=float[8]):
> CodeTools:-Usage( M . M ):
memory used=68.67MiB, alloc change=68.74MiB, cpu time=7.50s, real time=1.92s


> restart:
> CodeTools:-Usage( Matrix([[3.]]) . Matrix([[3.]]) ): # initialize external libs
memory used=217.84KiB, alloc change=127.98KiB, cpu time=141.00ms, real time=141.00ms

> getenv(OMP_NUM_THREADS);
                              "1"

> M:=LinearAlgebra:-RandomMatrix(3000,datatype=float[8]):
> CodeTools:-Usage( M . M ):
memory used=68.67MiB, alloc change=68.74MiB, cpu time=7.38s, real time=7.38s


> restart:
> CodeTools:-Usage( Matrix([[3.]]) . Matrix([[3.]]) ): # initialize external libs
memory used=217.11KiB, alloc change=127.98KiB, cpu time=125.00ms, real time=125.00ms

> getenv(OMP_NUM_THREADS);
                              "4"

> M:=LinearAlgebra:-RandomMatrix(3000,datatype=float[8]):
> CodeTools:-Usage( M . M ):
memory used=68.67MiB, alloc change=68.74MiB, cpu time=7.57s, real time=1.94s



Hyperthreading enabled in BIOS
------------------------------

> restart:
> CodeTools:-Usage( Matrix([[3.]]) . Matrix([[3.]]) ): # initialize external libs
memory used=216.57KiB, alloc change=127.98KiB, cpu time=125.00ms, real time=125.00ms

> getenv(OMP_NUM_THREADS);  # NULL, unset in OS

> M:=LinearAlgebra:-RandomMatrix(3000,datatype=float[8]):
> CodeTools:-Usage( M . M ):
memory used=68.67MiB, alloc change=68.74MiB, cpu time=8.46s, real time=2.15s


> restart:
> CodeTools:-Usage( Matrix([[3.]]) . Matrix([[3.]]) ): # initialize external libs
memory used=216.80KiB, alloc change=127.98KiB, cpu time=125.00ms, real time=125.00ms

> getenv(OMP_NUM_THREADS);
                              "1"

> M:=LinearAlgebra:-RandomMatrix(3000,datatype=float[8]):
> CodeTools:-Usage( M . M ):
memory used=68.67MiB, alloc change=68.74MiB, cpu time=7.35s, real time=7.35s


> restart:
> CodeTools:-Usage( Matrix([[3.]]) . Matrix([[3.]]) ): # initialize external libs
memory used=216.80KiB, alloc change=127.98KiB, cpu time=125.00ms, real time=125.00ms

> getenv(OMP_NUM_THREADS);  # NULL, unset in OS
                              "4"

> M:=LinearAlgebra:-RandomMatrix(3000,datatype=float[8]):
> CodeTools:-Usage( M . M ):
memory used=68.67MiB, alloc change=68.74MiB, cpu time=8.56s, real time=2.15s


> restart:
> CodeTools:-Usage( Matrix([[3.]]) . Matrix([[3.]]) ): # initialize external libs
memory used=216.80KiB, alloc change=127.98KiB, cpu time=125.00ms, real time=125.00ms

> getenv(OMP_NUM_THREADS);
                              "8"

> M:=LinearAlgebra:-RandomMatrix(3000,datatype=float[8]):
> CodeTools:-Usage( M . M ):
memory used=68.67MiB, alloc change=68.74MiB, cpu time=8.69s, real time=2.23s

With all those new timing measurements it appears that having to set the global environment variable OMP_NUM_THREADS to the number of physical cores may not be necessary. The performance is comparable, when that variable is left unset. So, while this post is now a non-story, it's interesting to know.

And the lesson about comparitive timings is also useful. Sometimes, even complete GUI/kernel relaunch is not enough to get a level and fair field for comparison.

E-Mail Address:
Password:
Remember Me:	Automatically sign in on future visits

E-Mail Address:
Password:
Remember Me:	Automatically sign in on future visits

Ask a Question

Create a Post