@Carl Love A 2D contour plot (un-filled) can be combined with a 2D density plot of custom shading. The "2D density plot" can be constructed using plots:-densityplot or via plots:-surfdata(...,dimension=2,style=surface).

If using surfdata then the GRID data from a plot3d result can be re-used. And if you're willing to assemble the plot structure manually (or subsop) then even the very same RGB COLOR data from a plot3d(...,colorscheme=...) may be re-used I believe.

But, if the goal is only to insert the filled 2D contour plot as a lower, horizontal plane in the final, combined, 3D plot, then couldn't you just take a plot3d surface, shaded via with colorscheme, and map it down to the plane? And likewise map the 2D contours (explicit data) up to the upper surface.

Ie. Don't use style=surfacecontour for the plot3d upper surface. It's a pity that plots:-surfdata doesn't allow style=surfacecontour alongside dimension=2. I am supposing that it's nice to have the exact same x-y contour positions, as well as the same color shading.

[edited] Here are some of the ideas I was trying to convey.

Download densityplot_from_3dsurface.mw

@Christopher2222 OK, I think I see. You are also using 2D Input mode for your example.

So, in the writeto file, the output shows in prettyprint=1 form, but the input shows as Typesetting code.

If you also want the input sent to file as 1D Maple Notation then you'll need to toggle to 1D Input mode in an Execution Group (as well as set interface(typesetting=standard) ).

I will submit a few bug reports:

• There ought to be no need to set interface(typesetting=standard) when using writeto in the GUI. This seems a regression, now that extended is the default.
• Using writeto in the GUI, setting interface(prettyprint=0) produces output that is wrongly wrapped in a Typesetting:-mprintslash call. And that is not avoidable even if also setting interface(typesetting=standard) .
• It's not clear what 2D Input should produce when using writeto a file from the GUI. Personally I can imagine it as possible a useful way to debug 2D Input mode. But it's also just a barrier.
• These subtleties aren't all documented in the Help page for writeto .

@Christopher2222 Please give an example of how it goes wrong when you writeto a file, with interface(prettyprint=1): .

For me it seems ok, in the sense that I don't see all output wrapped in calls to Typesetting exports. But if you'd care to be helpful and upload a worksheet that reproduces the issue, then please do so.

I also seemed to get ok results if I kept the Maple 2018 Standard GUI's default of interface(prettyprint=3) but toggled to interface(typesetting=standard): .

So do neither of these work for you in the Maple 2018 Standard GUI, with writeto a file?

• interface(prettyprint=1):
  writeto(....);
  ...
  writeto(terminal):
   
• interface(prettyprint=3):  # or leave as default in fresh worksheet
  interface(typesetting=standard):
  writeto(....);
  ...
  writeto(terminal):

ps. You know that the command restart does not reset these interface settings in a given Worksheet/Document in the Standard GUI, right?

I will mention one more, with a twist on doing it via definition.

This one also has the unexpanded (3*x^3+y^2)^2 subterms, as requested.

But the reason that I like this one is that --  when hit with simplify, say -- it does not produce those ugly numerator and denominator, both as sums with most terms involving radicals with fractional powers. And numer or denom of it produces the same as appear after applying either simplify or radnormal, which just the mentioned subterm getting expanded.

Download impldiff_alt.mw

Yet another way, without a kludge, and with a nicer form than I had above. (If isolate is replaced with solve and the rhs is removed, or if I don't first collect wrt diff, then the messier form attains.)

Download impdiffalt.mw

You have not included the equation.

@Kitonum The Generate(choose(...)) functionality is not fast, as used here. It's a little faster if the makeproc option is used. But it's still much slower than indexing by an integer generated via rand.

restart;
with(RandomTools):

LetList := [C, E, F, H, K, P, T, W, X, Y]:

[seq(Generate(choose(LetList)), i=1..5)];
                        [T, Y, P, E, H]

genR:=Generate(choose(LetList), makeproc):

genR();
                               P

[seq(genR(), i=1..5)];
                        [K, C, W, K, Y]

N:=10^5;
                          N := 100000

CodeTools:-Usage( [seq(Generate(choose(LetList)), i=1..N)] ):
memory used=252.55MiB, alloc change=32.00MiB, cpu time=1.71s, real time=1.71s, gc time=80.78ms

CodeTools:-Usage( [seq(genR(), i=1..N)] ):
memory used=165.57MiB, alloc change=0 bytes, cpu time=1.17s, real time=1.17s, gc time=56.40ms

gen:=rand(1..nops(LetList)):

CodeTools:-Usage( LetList[['gen()'$N]] ):
memory used=2.29MiB, alloc change=0.77MiB, cpu time=40.00ms, real time=40.00ms, gc time=0ns


CodeTools:-Usage( Generate(choose(LetList)), iterations=N ):
memory used=2.61KiB, alloc change=0 bytes, cpu time=17.28us, real time=17.29us, gc time=8.6e+02ns

CodeTools:-Usage( genR(), iterations=N ):
memory used=1.72KiB, alloc change=0 bytes, cpu time=12.08us, real time=12.09us, gc time=5.1e+02ns

CodeTools:-Usage( gen(), iterations=N ):
memory used=32 bytes, alloc change=0 bytes, cpu time=6.0e+02ns, real time=6.0e+02ns, gc time=0ns

I would expect that a more runtime-efficient way to construct these Matrices (if that really matters much to the OP) would be through repeated used of ArrayTools:-BlockCopy.  That avoids construction of the rows as lists of sequences of duplicate copies of L and F, which is just temporary/collectible garbage.

Likely even more efficient than that would be repeated assignment of just the nonzero entries of sparse F and L into the target Matrix.

I answered in terms of Matrix(..., scan=triangular[upper]) because it seems simple and clear. And the way the rows are constructed is very much like the OP's construction of the bands in his call to BandMatrix for L, by simple use of seq.

Do you think that the consequences of such a change in behavior would be limited to, "just a little overhead"?

There are at least two actions here, both of which may take place in `^` which is a kernel built-in: splitting (2*Pi)^(1/2) and rationalizing the denominator in 1/2^(1/2) .  I don't see why changing either of those canonicalizations might not bring about unexpected changes in functionality or performance.

I really, really don't like customizable, computational preferences with such a low-level effect. Every time a new one is added the cost of an exhaustive regression- and unit-test run (against all combinations of all such kind of preferences) will likely nearly double.  There are now enough such preferences that the cost of a frequently scheduled, exhaustive test run must surely be prohibitive. And hence the consequence of adding such a new preference is the added risk that some computations will fail under some configurations without anyone discovering it before conflicting examples take root.

Since the OP asked about what formulas Maple might access, there is also this:

  map(print, FunctionAdvisor(hypergeom, quiet, "special_values")):

or, paying attention to the "special values" section which is produced in Maple 2018,

  FunctionAdvisor(hypergeom);

There are also somewhat brief help-pages for Topics convert,GAMMA_related and simplify,hypergeom and convert,StandardFunctions . The help page for Topic hypergeom mentions the last of those in its description.

The knowledge in FunctionAdvisor and in convert and simplify are related, but I suspect that it is a considerable ongoing task to put the mechanisms, knowledge, and documentation in optimal order.

In the rare times that I've needed to, it's been possible to extract programmatically a particular formula out of FunctionAdvisor's return, and then use it to effect a replacement.

Ok, it looks as if you entered x^2+5-2 presumably in 2D Input mode.

But there are a few other configuration options that might be affecting this. For example, do you have a language pack installed? What typesetting level is your default?

Did you type all the input from the keyboard, or did you use any of the palettes or command-completion?

It would probably be helpful if you could upload short Worksheet/Document that illustrated (just) the problem, as well as answered the above queries.

@digerdiga Try it as,

frontend~(expand,`[]`~(o))
 

@digerdiga Where did you get the idea that the following will apply both simplify and combine to the collected coefficients?  (If it's due to something I once wrote, then it was likely a mistake I missed in haste.)

   collect(f,[k,GAMMA],simplify,combine)

Please compare,

restart;
kernelopts(version);

    Maple 2018.1, X86 64 LINUX, Jun 8 2018, Build ID 1321769

collect( 1+x+x^2, x, K );

                          2                
                    K(1) x  + K(1) x + K(1)

collect( 1+x+x^2, x, K, W ); # no application of K

                          2                
                    W(1) x  + W(1) x + W(1)

collect( 1+x+x^2, x, W@K );

                         2                      
                W(K(1)) x  + W(K(1)) x + W(K(1))

collect( 1+x+x^2, x, u->W(K(u)) );

                         2                      
                W(K(1)) x  + W(K(1)) x + W(K(1))

And for your example these two produce the same thing,

collect(numer(f),[k,GAMMA],u->simplify(u/denom(f)));

collect(numer(f),[k,GAMMA],simplify@(u->u/denom(f)));

@digerdiga Please explain precisely what you mean, and if in doubt upload a worksheet that illustrates the problem clearly.

Download collect_numer_2015.mw

Don't try and insert the contents of your file here. Just insert a link to the uploaded file.

Hit the OK button as the last step in the pop-up dialog, after inserting the link.

If that all fails then try it with a compressed .zip file.