@phiost Your transformation is producing floats with 0.0*I artefacts.

You could have discovered this by trying it out for a few values. Eg,

evalf( eval([x,t],[X=-2,t=4]) );
                    [2.805755396 + 0. I, 4.]

You could try this,

P2D1 :=plots:-display(
  plottools:-transform((a,b)->eval([Re(evalf(x)),t],[X=a,t=b]))(Pft),
  labels=["x","t"]
);

phiost_2.mw

@saemi123 Why didn't you provide your example when you first asked the Question!?!?

More importantly what you show is ambiguous 2D Input. Either upload the example in an attached .mw worksheet or show it as unambiguous 1D plaintext code.

ps. you might just utilize yhe `unapply` command to define X, instead of that ambiguous 2D Input assignment.

@phiost Yes.

Suppose you have any 2D plot assigned to the name P.

Then the following will turn it into a 3D plot in the level plane z=17. (And of course you can use z=-1 or any other value for z.)

plottools:-transform((x,y)->[x,y,17])(P);

And you can use plots:-display to combine multiple 3D plots.

Here is a zip file of a .mw file example,  contour_labels_transformed_B.zip . It creates all the plots below. If you want some other variant on these effects then please just describe it in full detail.

The first plot below has the contour labels at the same z-value as the level curves, which are placed slightly above the level surface. The text is hard to see unless the surface has a transparency, but that make it look washed out compared to the 3D surface above it. The 3D surface doesn't have the contour-lines style that the other two plots below have, but that can be changed.

And here it is in 3D without the contour labels.

It seems that for 3D a better effect can be obtained by raising the contour labels (text) above both the level curves and the corresponding level surface.I think this looks best, although you might experiment with a color other than red for the text (contour labels).

The plots:-shadebetween command was introduced in Maple 2015 and not Maple 15 (released 2011), and so will not be present in Maple 18 (released 2014).

The naming scheme changed in the year 2015, with versions since then named according to the year in which they were released.

Try this attachment in your Maple 18 ,

between_18.mw

Since not everyone has an updated Physics package that can handle this example could you please show the result of applying lprint to sol?

I suspect that sol is a call something like `&where(foo, bar) and if so then you should be able to evaluate (or otherwise substitute) the equations in bar into the expression foo.

And while evalf(Int(..., n=1..infinity)) can sometimes be handled numerically, if may not always converge fast enough. In that case you could make a very targeted substitution of a number for infinity using subsindets which would be safer than a blanket substitution.

@nm I suspect that Joe intended an effect something more like that of the following:

if op([5,1],ToInert(eval(`latex/int`)))
     = _Inert_IF(_Inert_CONDPAIR(
                  _Inert_INEQUAT(_Inert_NARGS(),_Inert_INTPOS(2)),
                   _Inert_STATSEQ(_Inert_ERROR(_Inert_STRING("invalid arguments"))))) then
  `latex/int`:=FromInert(subsop([5,1]=NULL,ToInert(eval(`latex/int`))));
end if:

Did you consider that the plot of Im(z) versus s might depend on Re(z)?

The discrepancy appears to be fixed in Maple 2019.1, in the sense that the weights Y used in computations like Mean(X, weights = Y) are used in the same manner when performed by DataSummary.

In Maple 2018.0 (through to Maple 2019.1) I see the following improvement: Just one preliminary conversion required, although the original arcsin form remains.

Download simplification_example.mw

And an additional example mentioned below by vv also works directly:

restart;
arctan(-sqrt(2)-1+sqrt(2-sqrt(2))+sqrt(2+sqrt(2))):

simplify(%);
                             1    
                             -- Pi
                             16   

@mmcdara In my Maple 2019.1 the computation of Variance(Z(X+Y)) completes, slowly, under these assumptions on sigma__x and sigma__y.

It also sometimes completes without assumptions, if interrupted and re-computed. That's a sign that int is struggling. An important difficulty is that in nested/iterated form int(int(int(...))) the inner integrals are not aware that the outer variables of integration may be real, or lie within a specific range, etc.

But using the so-called collapsed form int(...,[...]) it computes reasonably quickly under those same assumptions.

I will submit another Software Change Request, to the effect that Statistics should probably use that collapsed form for all its multiple intergals -- whether active or inert.

The same goes for VectorCalculus:-int and Student:-MultivariateCalculus:-MultiInt. (I have a growing collection of simple examples where it makes the difference between success versus failure, or a quick versus a slow computation.)

So, for now, value(CollapseNested(Combine( some_inert_nested_integral ))) can be a useful alternative.

Download stats_example.mw

@qilianshan In your input you can type Ctrl-L to insert such an equation label reference.

@wsningrat I was striving to provide you with code whose approach was straightforward and where the plotting methodology seemed natural.

As it happens it was already reasonably quick. But for your interest here it is, but faster, and (I hope) still reasonably straightforward as far as the plotting goes. I also include Tom's approach, which is also pretty fast, and you could easily go with either (I leave it to you to decide which suits your style).   captive_breeding_ac2.mw

@chandrashekhar 

Your claims appear to be untrue. Please point out what is incorrect, specifically, with the worksheet I now attach.

Perhaps you should cut and paste what was in your own post (rather than work with any prior worksheet), and test your claims.

Please check that the expressions appearing below are the same as what you wrote in your original Question.

Download claims2.mw

I have already asked you to upload a worksheet that contained the expressions as you expected them. You post comment after comment without any such worksheet. It's not clear that you are really interested in help us to help you.

For what it might be worth, here are three forms of the first expression (as I copied it) that are compact. 

(mu^2*(beta-sigma)*(mu+2*lambda)*c+(2*beta*lambda^2
+2*mu*(mu+beta)*lambda+mu^2*beta)*sigma)*(nu+2*lambda)
+sigma*(nu+beta+2*lambda)*mu^3;

(mu^2*(beta-sigma)*(mu+2*lambda)*c+2*(beta*(lambda^2+1/2*mu^2)
+mu*(mu+beta)*lambda)*sigma)*(nu+2*lambda)
+sigma*(nu+beta+2*lambda)*mu^3;

mu^2*(beta-sigma)*(nu+2*lambda)*(mu+2*lambda)*c
+(nu+2*lambda)*(2*beta*lambda^2+2*mu*(mu+beta)*lambda
+mu^2*beta)*sigma+sigma*(nu+beta+2*lambda)*mu^3;

You should specify what metric you want to use to measure size of the expression. Maple's length command is not best. The commands MmaTranslator:-Mma:-LeafCount or `codegen/cost` may be better.

Does anyone else get that the OP's original and his manually simplified expression are actually equivalent?

And Christian's reformulation?

Perhaps I'm missing something in my copy&paste.

I find it difficult to take this seriously if you deliberately avoid providing a complete example that reproduces all the problem's characteristic issues.