restart;

ee := GAMMA(n-1/n)*GAMMA(1/n)/(n*GAMMA(n)) = 1:

ff := simplify( ee * GAMMA(n-1) / GAMMA(1/n) );

                                                          2
                                                         n  - 1
                                                   GAMMA(------)
                                                           n       GAMMA(n - 1)
                                             ff := ------------- = ------------
                                                     (n - 1) n      GAMMA(1/n)

Now, if the numerator and the denominator of the LHS of that were both equal to 1, and if additionally the RHS of that were 1, then we'd have a solution. And since GAMMA(1)=1 then we could look at the operand of the GAMMA call in the numerator of the LHS. Of course that is merely manual observation.

op(numer(lhs(ff)))=1, denom(lhs(ff))=1, subsindets(rhs(ff),specfunc(GAMMA),op)=1;

                                           2
                                          n  - 1
                                          ------ = 1, (n - 1) n = 1, (n - 1) n = 1
                                            n

solve( {n>1, n<4, % } );

                                                            1/2
                                                           5
                                                      {n = ---- + 1/2}
                                                            2

simplify( eval( ee, % ) );

                                                           1 = 1

acer

The problem in Maple 2016.1 is that those two calls to simplify are trying internally to apply a simplify(...,size) cleanup and a bug prevents that from working in the presence of the radical and the float coefficients.

So, while I have not yet attained an expression in Maple 2016 whose numeric integration matches the speed of Maple 18, I have figured out one way to improve the Maple 2016 experience by avoidng that bug. One aspect is to supply the applysimplifysize=false option to those two problematic simplify(...,Laguerre) and simplify(...,sqrt) calls to avoid the error message. Another attempt also applies simplify(...,size) successfully by first freezing the radical. These two attempts get speed reasonably close to the original when executed in Maple 2015.2.

It may be that some customized call to collect (on the frozen radical, or the cos(theta) , or the exp call, perhaps with optional simplify(..,size) applied to the collected coefficients) might do even better. If I find something I'll let you know.

Maple_numeric_speed_3.mw

acer

Download lplot.mw

That plot looks less jagged in Maple itself. This site doesn't render 2D plot curves very nicely.

Slower but also better is,

evalf(Int(f(x)*g(x,a),x=-infinity..a-1,digits=16,epsilon=1e-3))

acer

I'm not sure which version of Maple you have, so I don't know which new features of Explore you can use. You may or may not want to use the echoexpression=false option.

TestExplore_1.mw

acer

You don't need to actually assign the values fo the variable in order to utilize then in some subsequent computation. Sometimes it is more convenient to not make the assignments, so that you can still use the names (as unassigned names).

restart;

l2 := Optimization:-NLPSolve( t1*th-tl-3, {t1+th<=3, th-tl>=3, t1>=-2} );

                      l2 := [-15., [t1 = -2., th = 5., tl = 2.00000000000000]]

op(2, l2);

                           [t1 = -2., th = 5., tl = 2.00000000000000]

eval( t1-th*tl, op(2, l2) ); # utilizing the solution without assignment

                                     -12.0000000000000

t1, th, tl; # still unassigned

                                         t1, th, tl

But you can make the assignments, if you wish. Note that doing do may make it more awkward to subsequently manipulate expressions where you want to use the names as just unassigned names.

assign( op(2, l2) ); # force the assignment

t1, th, tl;

                                 -2., 5., 2.00000000000000                                                   

t1-th*tl; # utilizing the assigned names;

                                     -12.0000000000000

acer

You have two problems, both related more to plotting in general than to the Explore command.

The first is that VEHQD assigns a value of 0.0 to local TD. That makes plots:-semilogplot throw the error message you see (which is then caught and rethrown by Explore).

The next problem is that the call to plots:-semilogplot prematurely evaluates its first argument, which is the call to QDCALC. That is resolved by wrapping that call to QDCALC in unevaluation quotes (single right-quotes). This is a common mistake.

Note that these two problems manifest themselves even if you invoke VEHQD outside of Explore, all on its own. For example, just computing this by itself,

VEHQD( 1.0 );

A sidenote on programming: At the start of your worksheet you call with(plots)  to load the plots package. And that allows the call to just semilogplot to work ok from within QDCALC. Better in my opinion is to instead add the line

   uses plots;

to the start of the QDCALC procedure, or to use the long-form fully qualified name plots:-semilogplot within that procedure. Your code can still work with the way you had it, though, and I did not make this change.

I also added the view option in that call to QDCALC, which I think makes for a nicer experience as the vertical range displayed is then common for the whole exploration. You can remove that is you don't prefer it.

Explore_VEHQD_1.mw

Lastly, you may indeed in future want a wrapping procedure like VEHQD for use with Explore. But that layer is not strictly necessary here. You could also do it with just,

Explore(plots:-semilogplot( 'QDCALC' ('TD' , RD), 'TD' = (1.0) .. (1000.0),
                           view = 0 .. 300 ),
        parameters = [ RD = 1.0 .. 30.0 ] );

acer

I get confused about the updated facilities to create help, and it's been a long time since I looked at this old format.

One crude way consists of reformatting the plaintext with new linebreaks, and then pushing it into a Help database (just as a block of plaintext).

mkhelpthing.mw

Once the xxxx.help file exists then you can relaunch your Maple 2016 GUI and query the topics. Also, once that's done the first time then you can likely query additionally added topics/pages within the same GUI session. There are some bugs to be aware of:

1) Despite what the makehelp documentation says, it appears to launch the Help Browser to open and display the newly added item even if that statement is terminated with a full colon. That happend in both the Java GUI and the TTY/CLI Commandline Interface for my 64bit Linux Maple 2016.1. That might make it awkward to automate the whole process.

2) The Maple 2016 GUI recognizes the set of locations for .help/.hdb Help databases only at launch. Depsite what the libname documentation says it seems not possible to augment libname within a GUI session and have help databases in augmented locations get recognized.

3) Problem 2) can be handled by either A) augmenting libname in a personal initialization file (which updates the path before GUI's help system deals with it) or B) put the .help/,hdb files in a special toolbox location. My attached sheet does the latter.

In some earlier versions of Maple you might be able to use INTERFACE_HELP rather than makehelp . And you might also be able to construct a .hdb rather than a .help database file. I forget when the ways the commands work changed. 

Another way, possible in Maple 2016, is to use some DocumentTools and DocumentTools:-Layout commands to form and write out an actual .mw worksheet/document, and then to load that in. That would allow keywords like, say, "PARAMETERS" to become a Section title and the appropriate bits put into the section, and input could be turned into actual Input lines, etc. I'm not doing that right now because it's possible that I've simply overlooked a key command which already does all this. It'd be nice to be able to make your text look like modern Help pages, and indeed I think it would be nice to have some markup format from plaintext (even if not like your example) which can be processed into fully functional, modern, working/looking Help pages. I like plaintext source because I can do revision control on it.

acer

Is it just the case that you want,

display([plot3,plot2], insequence=true);

instead?

It may take more work to get just a single legend visible. Hmm, that might even be very difficult to accomplish, if at all.

Since you mentioned it, yes you could also utilize piecewise to get a similar effect. Note that the h values are spread uniformly across the whole range 0 .. 1+1/sqrt(3) in this case. In your original plot2 and plot3 each get produced both with their own total numbers of frames. And the special point h=1 gets a frame.

plots[animate](plot, [piecewise(h>1,tau[1],tau[2]), z = -(1/2)*h .. (1/2)*h,
               color = piecewise(h>1,red,blue), legend = shear*stress],
               h = 0 .. 1+1/sqrt(3), frames=51);

acer

@itsme Interesting. I get the same checksum using md5sum as you cite, for the Maple2016.1a file Maple2016.1LinuxX64Upgrade.run

But for file Maple2016.0LinuxX64Installer.bin I get 8a74d1be80e3ba130055bdf90ed49e74 as the md5sum checksum. And the value that I get agrees with the value listed here (albeit the filename extension is .run instead of .bin but it doesn't change if I rename it).

[edit] I am on the Beta Testers Forum. The checksum you report ( 06455f61d8d822ad39d1242cfae85de2 ) for Maple2016.0LinuxX64Installer.run is the same as for one of the beta version builds. I suggest you obtain the final released installer with that same filename and try that instead.

Sure. You can use the sprintf command to construct the string used as the first argument to the printf command.

acer

The index can set the default value (when the number of arguments is even, say). Offhand I don't recall any command which make use of that when making the construction, but my memory is poor.

Download pwindexed.mw

acer

Read the comments. The "X" column data is weird.

Download plot_16_3.mw

acer

You didn't say how accurate you want the results, and note that the accuracy will be limited by the closeness of the interpolated approximation of the surface to the "true" surface. Hence it probably doesn't make much sense to ask for numeric quadrature results with a tolerance of less than say 1e-5 (and perhaps even 1e-3).

Next, change those lowercase `int` calls to `Int`(if only to make it appear deliberate -- too many people get hit by an unwanted failing symbolic integration prior to purely numeric quadrature kicking in).

Change the arrow-operator Vapprox to be defined with proc(rho) ...end proc instead. Do that so that you can make it's first line be,

       if `not`(type(rho, numeric)) then return ('procname')(args) end if;

As it stands now your calls like Vapprox(SSpline(t,r)) are prematurely evaluating, so that your get the high degree "polynomial" (in unevaluated SSpline calls). That means that SSpline gets called multiple times (with the same arguments) each time Vapprox is called. You could also add option remember (or option remember,system) to SSpline as a way to memoize. But do change Vapprox to return unevaluated unless it gets numeric arguments. [edited] Or you could set up the evalf(Int(...)) calls to use so-called operator form, rather than have the integrand be an expression. But this way seemed simplest. This brings about (at least?) a ten-fold speedup for me.

Try adding epsilon=1e-3 to each of your evalf(Int(...)) calls.

There is more to say, but I must run.

[edited]

Running in 64bit Maple 18.02 for Linux, on a fast (skylake) Intel i5. I obtained yet more speed by toning down the evalf(Int(...)) accuracy tolerance requests. But I refrained from using your digits=7, because in such examples where one computes evalf(Int(...)) of complicated procedure (that have there own accuracy issues to deal with) I have generaly found it best to not downgrade working precision but rather to just moderate the evalf(Int(...)) epsilon/accuracy goal. You may of course still experiment, but it's tricky to ensure that the numeric differentiation will produce accurate results -- you don't want to get a rough numeric quadrature approximation of a much rougher numeric differentiation approximation of a numeric interplation approximation of something and lose all versimilitude.

SimplifiedIntegration_1.mw

If this is not fast enough (or if you want to try and squeeze more  accuracy out -- keeping in mind that the interpolation order and method is likely going to have a big effect on how accurately your interpolated surface itself matches the "true" surface...) then you could probably improve on the numerical differentiation. The fdiff command basically does numeric differentiation using a difference scheme. You could build you own scheme and procedure to do that. I mention it because you could then call ArrayInterpolation to very quickly compute all the interpolated points required by that 1D numerical differentiation scheme at one shot, by passing in a float[8] Vector. (Imagine you are using a 7-point 1D scheme... I imagine that you get my gist.) That would mean the dtSSpline would only have to make a single call to ArrayInterpolation for each numerical derivative evaluation. Off the cuff I don't know how much benefit there'd be to eliminating that overhead portion. Of course you would not use the custom module exactly as I showed (which only gave modest savings in computing interpolation for single t-r pairs. You'd have to experiment first with the original rougher call to ArrayInterpolation to set it up, and them perhaps optimize with a module that handled the multiple points gracefuly and efficiently.)

acer

@nm If you would like the name (symbol) to appear the same then you could substitute with a generated local rather with some other spelling or case, etc. This allows you to force italic vs roman, and (if using Maple 18 say, though fixed in later releases for at least some `erf` calls) avoid that printf error.

latex( subs( [:-LambertW=`tools/gensym`(LambertW)], LambertW(x) ) );

{\it LambertW} \left( x \right)

latex(erf(2*x));

Error, (in fprintf) string expected for string format

latex( subs( [:-erf=`tools/gensym`(erf)], erf(2*x) ) );

{\it erf} \left( 2\,x \right)

In my experience the footprint of the Java GUI -- as distinct from the mserver processes (kernel engines) running from it -- is never lightweight, often 300MB+.

But displaying many plots, especially 3D plots, seems to often make it rise much higher, and it often stays high even when those plots are deleted in the same running session. For example if you run and re-run a longish animation of "large" 3D plots then the footprint often seems to just grow and grow.

With the most recent couple of Maple major versions the effect of that growing memory footprint on performance has improved. A few releases back the GUI responsiveness would degrade heavily when it got large. I suspect that moving to a more modern JRE version has contributed to the improvement in performance in that regard. I have heard mention that the Java garbage-collector "needs a lot of elbow room" in order to operate well, and that aspect might be related to improvement alongside JRE version updates.

acer