MaplePrimes Commons General Technical Discussions

The primary forum for technical discussions.

Dear Maple Users

I have been testing Maple 16 for some time now, and I am overall very pleased with it. There is however one issue, which is really annoying. In previous version of Maple, images inserted into Maple and plots were printed much bigger than they looked like in the Worksheet. Then me and other users have requested to have the printed output look more like it does in the Worksheet on the computerscreen. Maple has adressed those user complaints in the new...

Way back in Maple 6, the rtable was introduced. You might be more familiar with its three types: Array, Matrix, and Vector. The name rtable is named after "rectangular table", since its entries can be stored contiguously in memory which is important in the case of "hardware" datatypes. This is a key aspect of the external-calling mechanism which allows Maple to use functions from the NAG and CLAPACK external libraries. In essence, the contiguous data portion of a hardware datatype rtable can be passed to a compiled C or Fortran function without any need for copying or preliminary conversion. In such cases, the data structure in Maple is storing its numeric data portion in a format which is also directly accessible within external functions.

You might have noticed that Matrices and Arrays with hardware datatypes (eg. float[8], integer[4], etc) also have an order. The two orders, Fortran_order and C_order, correspond to column-major and row-major storage respectively. The Wikipedia page row-major  explains it nicely.

There is even a help-page which illustrates that the method of accessing entries can affect performance. Since Fortran_order means that the individual entries in any column are contiguous in memory then code which accesses those entries in the same order in which they are stored in memory can perform better. This relates to the fact that computers cache data: blocks of nearby data can be moved from slower main memory (RAM) to very fast cache memory, often as a speculative process which often has very real benefits.

What I'd like to show here is that the relatively small performance improvement (due to matching the entry access to the storage order) when using evalhf can be a more significant improvement when using Maple's Compile command. For procedures which walk all entries of a hardware datatype Matrix or multidimensional Array, to apply a simple operation upon each value, the improvement can involve a significant part of the total computation time.

What makes this more interesting is that in Maple the default order of a float[8] Matrix is Fortran_order, while the default order of a float[8] Array used with the ImageTools package is C_order. It can sometimes pay off, to write your for-do loops appropriately.

If you are walking through all entries of a Fortran_order float[8] Matrix, then it can be beneficial to access entries primarily by walking down each column. By this I mean accessing entries M[i,j] by changing i in ther innermost loop and j in the outermost loop. This means walking the data entries, one at a time as they are stored. Here is a worksheet which illustrates a performance difference of about 30-50% in a Compiled procedure (the precise benefit can vary with platform, size, and what else your machine might be doing that interferes with caching).

If you are walking through all entries of an m-by-n-by-3 C_order float[8] Array (which is a common structure for a color "image" used by the ImageTools package) then it can be beneficial to access entries A[i,j,k] by changing k in the innermost loop and i in the outermost loop. This means walking the data entries, one at a time as they are stored. Here is a worksheet which illustrates a performance difference of about 30-50% in a Compiled procedure (the precise benefit can vary with platform, size, and what else your machine might be doing that interferes with caching).

The MRB constant Z will probably have several parts.

The following example is from the Maple help pages
> with(GraphTheory);
> with(SpecialGraphs);
> H := HypercubeGraph(3);

What I would like to do in the MRB constant z,  MRB constant z part2, and etc. is to draw a series of graphs that show the some of the geometry of the MRB constant.

See I would like to draw a tesseract of 4 units^4, a penteract of 5 units^5, etc and take an edge from each and line the edges up as in Diagram 3:





As usual I'm asking for your help.






This post can be downloaded here:  Download

Below we have approximations involving the MRB constant. The MRB constant plus a fraction is saved as P while a combination of another constant is saved as Q. We then subtract Q from P and always have a very small result!

The basic plot routine in Maple 16 has a serious problem with the domain.  The following is an example.

The domain is correct in Maple 15.  This failure occurs in both Windows 7 and Linux.

I have been generating graphics in Maple 16 using the plotsetup(ps,...) command under Windows 7 and Linux.  Maple tech support has a fix for Linux and has confirmed that there is a bug in the Windows version.  These are a Windows eps (converted to png for uploading) and png of the same figure.  The eps conversion should not do this.



The Locator object is a nice piece of Mathematica's Manipulate command's functionality. Perhaps Maple's Explore command could do something as good.

Here below is a roughly laid out example, as a Worksheet. Of course, this is not...


The MRB constant is evaluated by



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

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


What are the quotients  ot the  continued fration of the sum of f(1)+f(2)+f(3)+f(4)+...

Here are the  quotients  of some partial sums.


cfrac(evalf(sum(f(x), x = 1 .. 2)), 'quotients')

[0, 2, 1, 1, 1, 21, 10, 4, 1, 4, 8, `...`]


cfrac(evalf(sum(f(x), x = 1 .. 3)), 'quotients')

[0, 6, 1, 2, 3, 1, 1, 2, 3, 3, 24, `...`]


cfrac(evalf(sum(f(x), x = 1 .. 4)), 'quotients')

[0, 2, 1, 2, 1, 4, 2, 1, 3, 1, 1, `...`]


cfrac(evalf(sum(f(x), x = 1 .. 5)), 'quotients')

[0, 5, 1, 99, 1, 1, 1, 6, 1, 3, 1, `...`]


cfrac(evalf(sum(f(x), x = 1 .. 6)), 'quotients')

[0, 2, 1, 6, 1, 2, 1, 2, 2, 1, 1, `...`]


cfrac(evalf(sum(f(x), x = 1 .. 7)), 'quotients')

[0, 5, 1, 1, 142, 1, 1, 1, 1, 19, 1, `...`]


cfrac(evalf(sum(f(x), x = 1 .. 8)), 'quotients')

[0, 2, 1, 47, 1, 1, 1, 1, 27, 4, 1, `...`]


cfrac(evalf(sum(f(x), x = 1 .. 9)), 'quotients')

[0, 5, 5, 3, 1, 7, 1, 1, 1, 2, 1, `...`]


cfrac(evalf(sum(f(x), x = 1 .. 100)), 'quotients')

[0, 3, 1, 1, 1, 11, 2, 2, 1, 1, 4, `...`]


cfrac(evalf(sum(f(x), x = 1 .. 200)), 'quotients')

[0, 3, 1, 2, 1, 1, 1, 11, 3, 4, 6, `...`]


cfrac(evalf(sum(f(x), x = 1 .. 400)), 'quotients')

[0, 3, 1, 3, 3, 3, 1, 18, 1, 2, 1, `...`]


cfrac(evalf(sum(f(x), x = 1 .. 800)), 'quotients')

[0, 3, 1, 3, 1, 4, 16, 14, 3, 23, 2, `...`]


cfrac(evalf(sum(f(x), x = 1 .. 1600)), 'quotients')

[0, 3, 1, 4, 7, 4, 436, 1, 1, 1, 2, `...`]



Here are the quotients of the  continued fration  of the sum. 

cfrac(evalf(sum(f(x), x = 1 .. infinity)), 'quotients')

[0, 3, 1, 4, 1, 1, 1, 1, 1, 9, 1, `...`]


With the exception of the leading 0, that is close to the integer squence of pi.




The exponents of 2 that sum the numerator and denominator, in the following way, of that multiple of pi give rise to the integer sequences {0,1,2,3,8,16},numbers such that floor[a(n)^2 / 7] is a square, and {0,2,3,4,8,16},{0,3} union powers of 2.




We can do the same thing for the first 20 quotients giving rise to the integer sequences {0,1,2,5,6,8,10,13,17,19,22,23,24,28,31} and {0,4,6,9,12, 14,15,16,18,22, 23,24,28,31}. What can be said of these sequences?

cfrac(evalf(sum(f(x), x = 1 .. infinity), 20), 20, 'quotients')``

[0, 3, 1, 4, 1, 1, 1, 1, 1, 9, 1, 3, 1, 2, 1, 1, 1, 5, 1, 3, 11, `...`]


evalf((1849023129/1849306543)*Pi, 20)




evalf((2^31-2^28-2^24-2^23-2^22-2^19-2^17-2^13-2^10-2^8-2^6-2^5-2^2-2-2^0)*Pi/(2^31-2^28-2^24-2^23-2^22-2^18-2^16-2^15-2^14-2^12-2^9-2^6-2^4-2^0), 20)





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

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




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)


And perhaps it should not because of the alternating sign;

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



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



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






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 .

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:

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.

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.





                                1.217, 25685408





                                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.






                                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:

First 9 10 11 12 13 14 15 Last Page 11 of 76