How should it handle abs(1,x) ?

@Bland3 I don't understand precisely why you are trying to write your own procedures for mimicing axes and tickmarks and tickmark labels.

It would help if you could state clearly what aspect of those things is not supported by the plot,axis and plot,tickmarks options. Specific examples and detailed descriptions of what you have not been able to accomplish using those would be helpful.

There are (of course) some aspects of functionality that are not provided by the current plotting options. But your attached worksheet(s) don't make it clear and explicit which if any of those you are trying to add and provide.

Given how the significant effort it would be to reproduce properly even the existing functionality I think that it would be prudent to first ensure that the functionalities you want are not currently achievable.

For example, the following things can be achieved with the current functionality, although it requires some creativity to come up with the solutions -- the documentation examples are skimpy.
  - all tickmark labels in common representation (scientific/engineering/reflated float format)
  - forced tickmark labels mixed with forced tickmark positions (ie. some in common location, some blank labels at some tickmarks, etc)
  - common font size and color for each axis's tickmark labels (but different per axis)
  - different font size and color for some tickmark labels along a common axis
etc.

Could you provide specific examples for most of the pieces of functionality for plotting axes which you have not been able to achieve?

There may be little point is getting it to run, at present, since the current performance of the Intel MKL BLAS gemm and gemv are so good.

The small number of CUDA enabled LinearAlgebra functions (Matrix-Matrix multiply and Matrix-Vector multiply) are so fast that the transfer time to upload/download the data to/from the GPU obscures the computation time.

Having said that, I see a few ideas for the future (although I think I wrote something similar a few years ago...).

1) Get one of the fuller LAPACK compilations (in GPU, of course) to work. The last time I checked there were a couple of candidates. But at that time neither had yet finished doing or optimizing the svd and nonsymmetric eigen-solvers, which have the higher complexity algorithms and longer computation times so that transfer-every-time wouldn't hide the benefits.

2) Make new "foreign DAG" MatrixVector in Maple whose hardware data lives on the card. (And procs to push up, and pull down, such beasts.) Then compound linear-algebra operations could be done on those, with the transfer overhead seen only at front and end of the computation.

3) Write BLAS and LAPACK direct front end packages in Maple. Have these access MKL or CUDA, as chosen. Bonus points for CodeGeneration or Compiler:-Compile of procs that use these.

These are all interesting, but it's unclear that the benefit would be in high enough demand. It might be tricky to justify these over, say, a new fast hardware quad-precision BLAS/LAPACK.

@chrisc Does it improve if you close the left panel (the "palette" pane)?

How about the right panel (the content-menus)?

Do you perhaps mean the Standard Java GUI?

@Carl Love 

You wrote, "It is obvious that the proper evaluation of F(G(e1, e2)) assuming a1, a2 requires that the assumptions be applied before F(G(e1, e2)) is evaluated."  But that aspect that you describe as obvious seems to be crux of what surprised the OP -- ie. the fact that all instances of name `x` within the unevaluated expression are temporarily replaced with an assumed name, prior to any part of F(G(e1,e2)) being evaluated. Hence the replacement with assumed names happens before even G(e1,e2) is computed.

That is the ususal evaluation model of `assuming`. It is (IMO) conveyed by the first sentence in the Desciption of the Help page for that command. The entirety of the first argument is evaluated under the assumptions placed on the names present.

@Kitonum Yes, but regardless of the strength of `solve`, isn't it zero over that wider domain?

I don't see why examination of the domains of subexpressions (radicals, csgn, ln, etc) present in some *particular* representation should always be an adequate and correct methodology. Their individual imaginary contributions may cancel for some x. Just because we don't know how to simplify/manipulate the expression into a representation where it clarifies differently doesnt mean that the expression might not be real-valued on a larger domain.

@Kitonum Why should one care that some arbitrary part of the expression may be considered as nonreal, as long as the whole expression is zero?

@Kitonum Perhaps I am missing something.

Why not   -exp(2)-1<x, x<=exp(2)-1  ?

(I don't mean just what solve returns.)

@snowman I just threw that in so that the procedure FF would return unevaluated if called with an argument that was not a number (eg. a name). That allows you to pass around FF(r), with r an unassigned name. It is not necessary here since the procedure returned by Interpolate (and assigned to F) already behaves like that. But when I started writing I didn't know for sure that I'd stick with the Interpolate approach.

The same mostly goes for that try...catch. I didn't know whether I'd need it, and I was suppressing potential difficulties.

Here is a copy of that worksheet which uses just F, and omits FF as wrapper. It works as well.
   polar_densityplot_modif.mw

Btw, I notice a slightly more even color gradient (visually more even, to my eye, at least) if I make the colorscheme progress through the Luv color space rather than the default. Another possibility is to adjust the grid resolution. Your opinion might differ. Eg,

plots:-densityplot(F(r), r=0..1, theta=0..2*Pi,
                   style=surface, axiscoordinates=polar,
                   labels=["", ""], grid=[101,51],
                   colorscheme=["zgradient",["White","Red"],
                                colorspace="Luv"]);

@Kitonum And for,

   simplify(expand(convert(Expr,exp)));

?

Sorry, you may have missed my interim edit, while responding. [edit] I updated it slightly before you posted your response. You might well have been submitting in the brief interim.

@snowman I did not understand before that you meant that f(r,theta) was independent of theta, sorry.

But I don't understand whether the numbers are supposed to relate to your given image. The data has r from 0..1, and f(r,theta) from 0.0..2.9. But your image shows x and y from -200..200 and values from 0.0..0.6.

Are the data and your image directly related? Or is the given image simply an example of a density plot with polar symmetry, but with values otherwise unrelated to your data?

I am going to suppose that the image is merely an example, since for one thing it is not independent of polar angle.

@nm I wrote that the (inner) call to odetest produces zero under the assumption. You have now left out the assumption, which is contrary to what I suggested.

That is the whole point of my answer. You have left out the key part of my answer.

In your first example,
   simplify(odetest(mysol,ode)) assuming x>0
invokes odetest under that assumption.

In your second example you were not calling odetest under the assumption.

That is the difference.

You quoted a sentence out of context. Here are the first two sentences in my Answer:

   "In the first case you are also calling odetest (and not just simplify)
    under the assumption.

    And that produces zero (in my Maple 2020.1 at least) even
    before simplify is called."

The "that" in the second sentence refers to the act (from the first sentence) of calling odetest under the assumption. You quoted the second sentence, ignored the first sentence and the context of "that", and then showed yet another call to odetest without the assumption.

There is nothing strange at all that the whole of the nested call is done under the assumption. This situation is neither uncommon not mysterious.

[edit] These examples are straightforward and normal instances of use of the assuming command, and follow its documentated description.

Please supply the more complete data:

      [r, theta, f(r,theta)]

for each (r,theta) pair.

If not, then it's pretty difficult to accomplish without knowing the f mapping.

@Bland3 I apologize for not being clear before.

I had written to someone about size formatting in pretty-printed subscripting by email, not in this forum. I apologize, as I see now that I gave the wrong impression.

I meant also that I have done several things like this and this old answer, but in greater detail and with some more programmatic flexibility. (The search facilities are so bad on this site, that I too have great difficulty finding some of the other related procedures I've posted on this site for very similar tasks.)

I would like to study your worksheets and requirements and use come up with a decent answer that is programmatically usable. I am just very busy right now.

I would also like to put together the kind of general description and example sheet that you suggest. But I don't know just when I'll have a next opportunity.