eval(splcurve) assuming v>=3, v<4.2;

acer

Actually, it is the inner name-quotes (single left quotes) that you are not seeing.

That's because you have interface(prettyprint) too high.

Try it with prettyprint=1 instead. Note the _syslib attribute needs to be stripped off, in order for the proc body to be displayed when prettyprint=1. Below I do this to a copy of dsolve, since I don't want to mess with my session's actual dsolve procedure.

restart:
interface(prettyprint=1):
interface(verboseproc=3):
print( setattribute(copy(dsolve)) );

[edit] I was surprised to need to strip the _syslib attribute above. I was running the code in the Standard GUI, to see for myself what I'd guessed about the problem of doing it with prettyprint=3. I knew that prettyprint=0 made verboseproc irrelevant here, but didn't expect it for prettyprint=1. But sure enough I was definitely seeing an elided proc body for the printing of dsolve with the setting as above. Now when I try it again it seems to work as expected, without needing setattribute and copy. This is not the first time that the GUI's own interface implementation has acted up in a transient manner.

acer

According to the "Compatibility" section of the ?add help page for Maple 2015,

  "The step parameter was introduced in Maple 2015."

That new option could be better documented in the Examples section, IMO. Eg,

seq(i, i=1...7, 2 );

                                 1, 3, 5, 7

add(i, i=1...7, 2 );
                                     16

seq(1+2*(i-1), i=1..4 );

                                 1, 3, 5, 7

add(1+2*(i-1), i=1..4 );
                                     16

acer

The bodies procedures in the attached worksheet are computation sequences, and they each return a list of three results that correspond to X, Y, and Z.

The point is that common subexpressions (eg. t31, t45, t50...) may be used in more than one of the three. The idea is to try and keep the total arithmetic operation count down.

It might be possible to produce initial expressions that are even shorter than what simplify(...,size) provides. If I get big success I'll let you know.

Download optimfun.mw

acer

Put MAIN and the function mult into two separate source files.

Build a shared object from the mult source file. Something like,

g77 -c -o func.o func.for
g77 -shared -o libfunc.so func.o

Then compile your main program and link to the shared library object you just made. Something like,

g77 -o test2 test2.for -l func

or

g77 -o test2 test2.for -L locationofthesharedlib -lfunc

You would also have to add `-lf2c` and perhaps `-lm` to that last one. I don't know what the libf2c.so support library is called for your version of g77.

Giving any of these files the ms-windows filename extension .dll on Linux or OSX would be confusing and wrong.

Maple's define_external talks to shared library objects, not (runnable) executables. Sorry, I am not at a Linux box to test just now, so some detail of locations could be wrong but this is the general idea.

acer

Add either a colon or a semicolon to the end of the lines within the loop.

I notice that you continue to use round bracket Array indexing like newaa(i,j) on the left-hend side of assignment statements, which is a bad idea as mentioned in responses to your earlier posts.

acer

The web page mentioned in this thread's Question has already been updated with new timings. Those new results show 64bit MS-Windows versions of Maple 2015.0 and Mma 10.02 with matching timing performance for computing the rank of a double-precision Matrix up to size 8000x8000.

Actually there is a modification in that tester's code for Mma 10, which sets the session's kernel history length to a value shorter than the default. That is, it sets $HistoryLength = 0 in Mma syntax. According to a post on community.wolfram.com this nondefault setting had to be used since otherwise Mma 10 did not succeed on the code's testing for sizes above 7500x7500 without memory use exceeding the 16GB RAM on the tester's machine.

acer

You seem to be having trouble with 2D Math.

There is an extra space between kernel__data and (m,n) which I suggest you remove, so that it doesn't get interpreted as implicit multiplication of those terms.

Your use of new2zpic(i, j) on the left-hand side of an assignment statement is ambiguous. I suggest you change all your rtable (Array or Matrix) indexing to use [] square brackets instead of () round brackets.

It seems as if Maple might be interpreting the subscripted name used for an upper loop index value as the oldstyle atomic identifier `#msub(mi("kernel"),mi("length"))` which is not the same name as kernel__length. Your sheet did the earlier assignment of a value to the subscripted name kernel__length.

How about saving yourself all this trouble and coding this program in 1D Notation (in execution groups, or entirely in a Worksheet) instead of in 2D Input in paragraphs in a Document?

acer

Here is code for the surface of revolution of a Reuleaux triangle, which runs in Mapler 15. I extracted it from this MathApp (the .mw file for which is here, but which does not seem to run as is with Maple 15).

This is not the only way to construct it.

restart:
c1:=piecewise(x>0,sqrt(1-(x+1/2)^2),sqrt(1-(x-1/2)^2)):
c2:=sqrt(1-1/2^2)-sqrt(1-(x)^2):
opts := showfunction=false, showrotationline=false, revolutionpoints=100:
std := output=plot,axis=vertical,scaling=constrained:
s1 := Student:-Calculus1:-SurfaceOfRevolution(c1,x=-1/2..1/2,std,opts):
s2 := Student:-Calculus1:-SurfaceOfRevolution(c2,x=-1/2..1/2,std,opts):
S:=plots:-display(s1,s2,caption=``,axes=box):
subsindets(S,specfunc(anything,{PROJECTION,VIEW}),t->NULL);

[edited] I had originally written here that this code produces a Reuleaux tetrahedron, but that is a different surface. The surface of revolution of a Reuleaux triangle is the minimum volume surface of revolution with constant width, which makes it interesting but not what you asked, sorry.

acer

As Carl points out, the performance regression seems due to plot3d no longer using evalhf for procedure J. That is a shame, and I don't see a rationale for it so I'd call this regression a bug.

I'm not sure what Yiannis means by saying the values like lim, lambda, etc, have to be globals. It's easy enough to burn them into a generated procedure, though I note that doing so does not by itself make Maple 18.02 utilize evalhf.

By the way, in Maple 18 the colors from Maple 13 can be duplicated by using the lightmodel=none option, though it looks ugly when inlined into this sight, for some strange reason. I notice also that in the session that it's computed it has the matching colors, but after saving then when reopened in Maple 18 it initially appears different and applies a default lightmodel (until recomputed, sigh).

On my Windows 7 machine with 64bit Maple 18.02 it takes about 14 seconds to produce this plot using evalhf around a wrapped procedure call.

Download Euler_modif.mw

Using the Compiler package it is possible to make both the 3D plot and the 2D densityplot compute even faster. I also separated out the real and imaginary parts, while doing so. (That separation, and even some amount of shoehorning custom formula into a template of procedure J can be programmatic, but making it automatic can be tricky. Here, I did some manual copy and pasting after a few evalc computations.)

The end 3D plot appears the same as above, but computes in a about 3 seconds on my machine.

Euler_compiled.mw

It would be even faster to write an evalhf'ble or compilable procedure which would act inplace on a float[8] Array argument and populate it inplace using the iteration scheme. Such an Array could then be stuffed into a GRID substructure of a PLOT3D structure. It's often much faster to populate an Array all within a single procedure call than to have to invoke a scalar-valued procedure for each entry. (That's how Maple 18's Fractals:-EscapeTime package's commands do it.)

acer

My guess is that you are in the habit of sometimes reexecuting out of order some commands in your Worksheet/Document. That is particularly problematic when you utilize assume. The code below mimics the kind of trouble you can get into when you repeatedly execute calls to assume and assignments with the assumed names.

restart:

interface(showassumed=1):

U := x*P^2/3;
                                      1    2
                                 U := - x P 
                                      3     

assume(P>0);

diff(U,P);

                                    2    
                                    - x P
                                    3    

U := x*P^2/3;

                                      1    2
                                 U := - x P 
                                      3     

assume(P>0);

diff(U,P);

                                      0

Such endeavors are often easier and less problematic if you utilize assuming instead of assume. You can even make an assignment like,

   conds := P>0, Q>0:

and then later on do computations to take that into effect.  Eg,

   some_commmand(something) assuming conds;

acer

You mentioned at one point that you prefered not so use uneval-quoted 'sum'(...) for the inner summation because then you wouldn't get the summation symbol. I suppose that you might feel similarly about using a nested call to add.

It seems that for this example another workaround variant is to use inert Sum for the inner summation. That typesets with a  summation symbol, albeit in gray.

In 1D Maple Notation that could look like this.

X := [0, 1, 2, 3]:
n := 2:
value( sum(Sum(a[k]*X[i]^k, i = 1 .. nops(X)), k = 0 .. n) );

                           4 a[0] + 6 a[1] + 14 a[2]

In 2D Input it could look as follows. Note that I used command-completion (Ctrl-Shift-Spacebar on my Linux) after typing the word Sum and chose the command "template" for inert definite summation from the popup menu offerings.

I also keystrokes Ctl-Shift-underscore in my Maple to get the subscripted display of X[i] and a[k]. You could also just enter X[i] and a[k] to be displayed as indexed names, if you prefer. In earlier version of Maple getting 2D Input for an indexed name involved a different set of keystrokes.

Download typesetsum.mw

You also wondered why you couldn't place uneval-quotes around the entire inner summation, when using sum. For this example it seems that you can, if you handle nops(X) slightly differently. (The nops(X) looks ugly as upper index value on the summation symbol, anyway, in my opinion.) I used Maple 18.01 here too. In 1D Maple Notation,

X := [0, 1, 2, 3]:
n := 2:
r := nops(X):
eval( sum('sum(a[k]*X[i]^k, i = 1 .. r)', k = 0 .. n) );

                           4 a[0] + 6 a[1] + 14 a[2]

And in 2D Input using command-completions (or palette for typeset definite sum) the following has both summation symbols in black. Of course the uneval-quotes detract somewhat.

Download typesetsum2.mw

acer

Download solvegrin2.mw

acer

In Maple 18 a new 2D plot option size was introduced. This can be used with the 2D plot command and with 2D commands in the plots package, and when using the plots:-display command on 2D plots.

In Maple 17 the Standard Java GUI already understood an earlier form of the relavent substructure (or a PLOT structure) related to sizing. But the usual documented 2D plotting commands mentioned above did not have any means of inserting this substructure. But it could still be accomplished in Maple 17 (for just the choice of posint pixel numbers width-by-height) using the undocumented Plot:-Structure:-SetSize command.

And there are limitations. The result below of calling SetSize cannot subsequently be combined with other 2D plots or otherwise generally adjusted using the plots:-display command. You'd have to first do all the combining, and then make the call to SetSize be the very last action before finally doing a simple print call on the resized PLOT structure.

Also, I don't think that the File>Print mechanism of the Maple 17's GUI's menubar understands the structure. But pdf Export might...

Download m17setsize.mw

In Maple 18 one should definitely not go this route. Use the documented size option instead.

acer

The Grid package would provide more insulation.

acer