@spradlig Yes, calling `plotsetup` with the first argument (plotdevice) supplied as "ps" will produce an Encapsulated Postscript file (suitable for image inclusion into another document, along with a bounding box).

Where my earlier example constructed a fully qualified filename "bypd.ps" you could instead have it be "bypd.eps" or whatever else you'd like to have it be named.

The `plotsetup` command also supports ".bmp" bitmap export.

In my experience the .eps export produces the sharpest and clearest results. The results for formats other than .eps, when produced via `plotsetup`, are often quite grainy, with harsh jagged curves in plots.

Even with the right-click plot export mechanism the formats other than .eps often produce poor quality images. A common workaround for that is (incredibly) to resize the plot by some very large amount (much bigger than even the Maple window), right-click-export, and then scale to the final desired size in an external image program. Doing all this successfuly may entail a need to use various plot,options to specify much larger fonts for plot labels and legends, so that the external resizing produces something legible. Hence .eps is quite often preferred, to try and avoid most of the above manual work, as I've heard it.

@brian bovril Finding approximations of the real roots can also be tried along with checks that no exact solutions exist outside the numerically tested range. And if the approximations can be identified as exact quantities then those in turn can be tested in the original.

A weak link in all this is that the numeric rootfinder might have missed some approximate solutions; it is not established that they are all found.

expr:=sin(Pi*(x+1)/(4*x^2-4*x+2))=cos(Pi*(x-2)/(4*x^2-4*x+2)):
new:=simplify(trigsubs(convert((lhs-rhs)(expr),sin)),size)[];

                /        2     \    /   / 2        \\
                |    Pi x      |    |Pi \x  - x - 1/|
          -2 cos|--------------| sin|---------------|
                |   2          |    |   2           |
                \4 x  - 4 x + 2/    \4 x  - 4 x + 2 /

solve({new,x>2},x); # NULL
solve({new,-2>x},x); # NULL

fsols:=Student:-Calculus1:-Roots(new,x=-2..2,numeric);

   [-0.6180339888, 0.2763932023, 0.7236067977, 1.000000000, 
     1.618033989]

efsols := map(identify,fsols);

 [1   1  (1/2)  1   1   (1/2)  1   1   (1/2)     1  (1/2)   1]
 [- - - 5     , - - -- 5     , - + -- 5     , 1, - 5      + -]
 [2   2         2   10         2   10            2          2]

seq( simplify(eval(new,x=s)), s in efsols );

                         0, 0, 0, 0, 0

Explore(plot(a*sin(b*x)+c,x=-3.14..3.14,view=-3..3,gridlines),
        parameters=[a=-5..5.,b=-5..5.,c=-3..3.],
        initialvalues=[a=-3.,b=-3.,c=-1.],
        newsheet,title="Plot of y=a*sin(b*x)+c" );

@daryljanzen I saw your earlier Question, and the first things that came to mind were:

Is this numeric computation?

Could it be possible that serial (nonparallel) version might be optimized? This is often true of Maple code written by people coming to Maple from some other computing environment.

You example code in that earlier question involved Arrays. Is that what most of your code is like, and if the computations are numeric and could be done at double precision then optimizing it may be possible. Are you using datatype=float[8] Arrays? Is your code able to run under evalhf, or can some of the your procedures be Compiled? If memory allocation is an issue then are inplace computations possible for parts of your code?

You might be able to use the Grid package to automate running dispatched instances in parallel, or you might be able to run a shell script on some Maple code that accepts parameter values. But experience tells me that the best course of action might be first to investigate whether your serial version could be optimized for memory and speed performance. Are you able to upload your full code in a Comment on your earlier Question? If not the full code, then how about a working, representative portion which exhibits the issues?

@daryljanzen I saw your earlier Question, and the first things that came to mind were:

Is this numeric computation?

Could it be possible that serial (nonparallel) version might be optimized? This is often true of Maple code written by people coming to Maple from some other computing environment.

You example code in that earlier question involved Arrays. Is that what most of your code is like, and if the computations are numeric and could be done at double precision then optimizing it may be possible. Are you using datatype=float[8] Arrays? Is your code able to run under evalhf, or can some of the your procedures be Compiled? If memory allocation is an issue then are inplace computations possible for parts of your code?

You might be able to use the Grid package to automate running dispatched instances in parallel, or you might be able to run a shell script on some Maple code that accepts parameter values. But experience tells me that the best course of action might be first to investigate whether your serial version could be optimized for memory and speed performance. Are you able to upload your full code in a Comment on your earlier Question? If not the full code, then how about a working, representative portion which exhibits the issues?

@TomM Are you using Maple 16.02 without the patched .jar file to fix a regression in the Standard GUI's 2D plot renderer?

@TomM Are you using Maple 16.02 without the patched .jar file to fix a regression in the Standard GUI's 2D plot renderer?

@Thomas Richard If that 1D Maple Notation (plaintext) is mistakenly pasted in as 2D Math input then the space gets interpreted as implicit mutiplation. The result is `simplify` multiplied by the bracketed expression involving Bessels.

Not all 1D input can be pasted directly as 2D Math input. See Parser Differences.

@Thomas Richard If that 1D Maple Notation (plaintext) is mistakenly pasted in as 2D Math input then the space gets interpreted as implicit mutiplation. The result is `simplify` multiplied by the bracketed expression involving Bessels.

Not all 1D input can be pasted directly as 2D Math input. See Parser Differences.

@Markiyan Hirnyk It might be called in Maple 16 like,

Explore( proc(a,b)
           Statistics:-DensityPlot(
             Statistics:-RandomVariable(
               Statistics:-Distribution(
                 PDF = (x-> x^(a-1)*(1+x)^(-a-b)/Beta(a, b)),
                 Support = 0 .. infinity)), range=0..infinity);
         end proc(alpha,beta) );

And then in the pop-up window adjust (at least some lower) end-values. But the Slider components that will appear in a new worksheet will reference names whose assignments are in a hidden document block, so it's not easy to cut and paste it as a whole back into the original open worksheet.

It might be easier to build an interactive version in the currently opened worksheet by following the few manual steps outlined here. The call to `plot` might then be replaced by your DensityPlot(Z,...) call above, for example.

@Markiyan Hirnyk It might be called in Maple 16 like,

Explore( proc(a,b)
           Statistics:-DensityPlot(
             Statistics:-RandomVariable(
               Statistics:-Distribution(
                 PDF = (x-> x^(a-1)*(1+x)^(-a-b)/Beta(a, b)),
                 Support = 0 .. infinity)), range=0..infinity);
         end proc(alpha,beta) );

And then in the pop-up window adjust (at least some lower) end-values. But the Slider components that will appear in a new worksheet will reference names whose assignments are in a hidden document block, so it's not easy to cut and paste it as a whole back into the original open worksheet.

It might be easier to build an interactive version in the currently opened worksheet by following the few manual steps outlined here. The call to `plot` might then be replaced by your DensityPlot(Z,...) call above, for example.

I wonder whether he could try to code it to solve for the constant of integration such that Im(int(U,t))=0, and then use that in Re(int(U,t)) if it weren't too messy or implicit.

Using U from his worksheet

s:=int(U,t):

ims:=simplify(combine(evalc(Im(s))),size);

                          8   (1/2)    
                        - -- 7      _C1
                          21           

sims:=solve(ims,indets(ims,name) minus {constants});

                           {_C1 = 0}

simplify(eval(simplify(combine(evalc(Re(s))), size), sims));

               /1  \    /3  (1/2)  \ /              2\
            exp|- t| sin|- 7      t| \65 - 4 t + 8 t /
               \8  /    \8         /                  
          - ------------------------------------------
                       /        /3  (1/2)  \\         
                    32 |-1 + cos|- 7      t||         
                       \        \4         //         

I suppose that this is a fragile approach.

I wonder whether he could try to code it to solve for the constant of integration such that Im(int(U,t))=0, and then use that in Re(int(U,t)) if it weren't too messy or implicit.

Using U from his worksheet

s:=int(U,t):

ims:=simplify(combine(evalc(Im(s))),size);

                          8   (1/2)    
                        - -- 7      _C1
                          21           

sims:=solve(ims,indets(ims,name) minus {constants});

                           {_C1 = 0}

simplify(eval(simplify(combine(evalc(Re(s))), size), sims));

               /1  \    /3  (1/2)  \ /              2\
            exp|- t| sin|- 7      t| \65 - 4 t + 8 t /
               \8  /    \8         /                  
          - ------------------------------------------
                       /        /3  (1/2)  \\         
                    32 |-1 + cos|- 7      t||         
                       \        \4         //         

I suppose that this is a fragile approach.

As of Maple 14, non-exported module locals can be accessed by the showstat command using the :: (double colon) as opposed to :- (colon minus).

Using the double colon, module locals can be viewed regardless of whether kernelopts(opaquemodules) has been set to false.

See Joe Riel's comment, though, on nonassociativity and the potential need for bracketing.

As of Maple 14, non-exported module locals can be accessed by the showstat command using the :: (double colon) as opposed to :- (colon minus).

Using the double colon, module locals can be viewed regardless of whether kernelopts(opaquemodules) has been set to false.

See Joe Riel's comment, though, on nonassociativity and the potential need for bracketing.