10 years, 359 days

These are answers submitted by acer

premature evaluation

September 23 2016 acer 12679

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.

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 ] );



September 22 2016 acer 12679

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).

Once the 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.


please clarify

September 21 2016 acer 12679

Is it just the case that you want,

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


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);


md5sum checksums

September 20 2016 acer 12679

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

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 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.


September 19 2016 acer 12679

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


default value

September 16 2016 acer 12679

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.




g := piecewise( x<1, x^2, x<2, sin(x) );

g := piecewise(x < 1, x^2, x < 2, sin(x))

eval(g, x=5 );


h := piecewise[16]( x<1, x^2, x<2, sin(x) );

h := piecewise(x < 1, x^2, x < 2, sin(x))

eval(h, x=5);




piecewise(x < 1, x^2, x < 2, sin(x), 0)

eval(g, x=5);



piecewise(x < 1, x^2, x < 2, sin(x), 16)

eval(h, x=5);







September 14 2016 acer 12679

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


filename := cat(kernelopts(homedir),"/mapleprimes/","16.3.xlsx"):
m,n := op(1,M):

found := 0:
xdata,ydata := 'xdata','ydata':
for j from 1 to n do
  for i from 1 to m do
    if M[i,j]="X" then
      found := found+1;
      xdata[found] := M[i+2 .. -1, j];
      ydata[found] := M[i+2 .. -1, j+1];
      xend := op(1,xdata[found]);
      while xdata[found][xend]=0.0 do xend:=xend-1; end do;
      xdata[found] := xdata[found][..xend];
      ydata[found] := ydata[found][..xend];
    end if;
  end do;
end do;


# xdata[2],xdata[3],xdata[4] all have entries of 1.0 throughout!
# Did you intend on using xdata[1] for all of then??
# The "X" data for "CURVE" number one is also goofy. Why do many of
# the "X" entries appear twice? Is that correct, or did you intend
# on smoothing the data?
plot( [ seq( <xdata[1]|ydata[k]>, k=1..found ) ],
      legend = [ seq( k, k=1..found ) ], gridlines=false);





September 13 2016 acer 12679

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.


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.

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.)


generated locals

September 08 2016 acer 12679

@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)


Error, (in fprintf) string expected for string format

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

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

3D plot leakage

September 08 2016 acer 12679

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.



September 08 2016 acer 12679

See my Answer here, and in particular the attached worksheets (there were a few, as I made amendments to the original).



September 07 2016 acer 12679

Your example can be handled quite simply by using the combine command.

expr := cos(v)*sin(w)-cos(w)*sin(v);

                                 expr := cos(v) sin(w) - cos(w) sin(v)

combine(expr, trig);

                                              -sin(v - w)


                                              -sin(v - w)

Another example,

expr := 2*sin(x)*cos(x):


                                                 sin(2 x)

You might also observe the effect that omitting that 'trig' option can have on other types of subexpression.

expr := cos(v)*sin(w) - cos(w)*sin(v) + exp(x)*exp(y):


                                       -sin(v - w) + exp(x) exp(y)


                                         -sin(v - w) + exp(x + y)

You could also read the help page for topic combine,trig . That page specifically mentions combining products of trigonometric terms into sums of trigonometric terms. So, for example, it has the following behavior (which may or may not be what you want for some other "simplification" example).

combine( cos(x)*cos(y) );

                                      1/2 cos(x - y) + 1/2 cos(x + y)

It's important to note that you can easily find other examples for which you would need several different commands (apart from or in addition to combine, as nested steps of operation) in order to attain some particular target, and for some examples it would be difficult or impossible.



September 06 2016 acer 12679

How about using the title option instead of the legend option, on each frame? Or create each frame of the sequence as a plots:-display of a PointPlot and a textplot?


distinct ratios

September 06 2016 acer 12679

A few years ago I made this post about doing that sort of thing for 3D implicit plots.

I wrote some procedures this past summer (for my own use) that allowed me to take a PLOT3D structure, produced by a command like plot3d or pointplot3d, and rescale it by either x-z or y-z aspect ratios (or both). It's working for a reasonable number of cases. Are you interested or will you have all you need from Carl's Answer?

Ideally the PLOT3D structure should be able to contain a new substructure for this, which the plot renderers would respect (with no need for tickmark hacking). And the plotting commands should be able to support new options that allowed formation of this substructure (aka "global plot option"). I've been somewhat hesitant to put more effort into my (tickmark hacking) own code for this, since more and more I'm convinced that it really should be fixed in this better way, thoughout the plotting system.

Part of a nice solution to this (IMHO) would involve resizing of the visible plot window -- an issue sometimes related (and sometimes not) to separate axis ratios. I wrote something for this too.


mostly ok so far

August 31 2016 acer 12679

It seems to work as expected in the few cases I've tried so far with 64bit Linux and 64bit Windows 7 versions of Maple 2016.1. I haven't yet seen it hang.

I did notice an unexpected error when I executed a function call such as sin(x) and did not suppress output, after I had enabled profiling using CodeTools:-Profiling:-Profile() when interface(typesetting) was extended. It looks like Profile's TRACE mechanism doesn't like call_external() and so cannot handle the StringTools:-RegMatch command. I will submit a bug report for that.


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