@Carl Love I am not sure what can and cannot by used as infix operators when typing in 2D Input mode. It's possible that it mostly only works for leading-ampersand entities which are not yet recognized by the parser as having special definition and handling. I just get implicit multiplication when I try it with typeset Greek letters as the entity.

In 1D Maple Notation using such entity names seems problematic. The parsing of infix operator application seems to demand the absence of wrapping name-quotes, and as you guessed those are needed to stop the training semicolon on the names from inducing a syntax error.

There is also a bug with the reverse situaion, for which I first submitted a bug report long ago. If you create a compound name from a typeset Greek letter followed by some other letters, and then use this for an unevaluated function call of two arguments, then the output will be displayed like an infix operator call. Whether you like it or not. Eg, in 1D notation,

T:=`ΦHZ2`;
T(a,b);
T:=`Φ__2`;
T(a,b);

So it seems you can't use a subscripted atomic identifier with an entity base (like a Greek name) as an unevaluated two-argument function call without the Std GUI rendering it like an infix operator call! Good grief.

One mechanism or syntax gets used for multiple purposes, which leads to problems. A familiar story.

If you replace nonreal (complex) numeric values with zero then your new plot might contain unexpected/false elements, where those zeroes cause additional points/lines/polygons/whatever to be rendered.

You could try replacing with Float(undefined) instead of 0.

acer

I am submitting a bug report against the error you got from evalf(S2) in your number 2).

I see that error message for your example 2) in Maple 2016.0 but not Maple 2015.2 and before, in Linux at least. But that line of code seems no different in some earlier versions, so perhaps the code flow has changed.

[edited] The bug is that `evalf/Sum1` is now using local `i` to hold a temp expression in a loop, before it (sometimes) calls `evalf/Sun/infinite`. That later call to `evalf/Sum/infinite` was coded as if `i` were just an unassigned name. But `evalf/Sum1` is now using (1st arg) and passing (2nd arg) the value that `i` had at the end of the earlier loop when it makes the call to `evalf/Sum/infinite`.

acer

@Carl Love That line with Sum(F(2*n)+F(2*n-1), n= 1..infinity) computes like the code I gave if the proc option is passed like chunksize=2. All good and interesting.

But I don't quite see why you write that it is "separately summing the even and odd terms". I'd phrase it more as summing the sums of even-odd pairs (or something like that). To my ear "separately summing the even and odd terms" would mean something like, say, Sum(F(2*n),n= 1..infinity)+Sum(F(2*n-1),n= 1..infinity) which also happens to return a very close float result under evalf. I suspect that I have misunderstood your meaning.

@KNS 

restart;

evalf( sum( (BesselJ(0,(1/4*(2*i-1)*Pi))^2/(2*i-1)), i=1..2 ) );

                                0.7254935884


evalf( sum( (BesselJ(0,(1/4*(2*i-1)*pi))^2/(2*i-1)), i=1..2 ) );

                             2                                            2
 BesselJ(0., 0.2500000000 pi)  + 0.3333333333 BesselJ(0., 0.7500000000 pi) 

@YasH Perhaps it is related to text messaging?

@Carl Love I made the same comments and suggestion about the infinity norm above, including caveats. But you wrote it nicely- I concur.

It's not obvious how the user will figure out the choices of zrange to use in the colorscheme option passed to densityplot in order to produce the very same colorings as one obtains from the plot3d command.

[edited below]

For example, the user would have to figure out to do something like the following, say, replacing suboption zrange=-5..5 with zrange=0..1 and adding the option scaletorange=-5..5 .

I throw in the restricttoranges option only to get a closer match to the x-y values used by plot3d -- it's not really central to the shading issue.

  plots:-densityplot(sin(x*y), x=-5 .. 5, y=-5 .. 5,
                     colorscheme=["zgradient",["blue","green","yellow","red"],zrange=0..1],
                     style=surface, scaletorange=-5..5, restricttoranges,
                     size=[270,270], axes=box);

  plot3d(sin(x*y), x=-5 .. 5, y=-5 .. 5, view=-10 .. 10,
         colorscheme=["zgradient",["blue","green","yellow","red"],zrange=-5 .. 5],
         style=surface, lightmodel=none, orientation=[90,0,0]);

  plots:-densityplot(3*sin(x*y), x=-5 .. 5, y=-5 .. 5,
                     colorscheme=["zgradient",["blue","green","yellow","red"],zrange=0..1],
                     style=surface, scaletorange=-5..5, restricttoranges,
                     size=[270,270], axes=box);

  plot3d(3*sin(x*y), x=-5 .. 5, y=-5 .. 5, view=-10 .. 10,
         colorscheme=["zgradient",["blue","green","yellow","red"],zrange=-5 .. 5],
         style=surface, lightmodel=none, orientation=[90,0,0]);

  plots:-densityplot(5*sin(x*y), x=-5 .. 5, y=-5 .. 5,
                     colorscheme=["zgradient",["blue","green","yellow","red"],zrange=0..1],
                     style=surface, scaletorange=-5..5, restricttoranges,
                     size=[270,270], axes=box);

  plot3d(5*sin(x*y), x=-5 .. 5, y=-5 .. 5, view=-10 .. 10,
         colorscheme=["zgradient",["blue","green","yellow","red"],zrange=-5 .. 5],
         style=surface, lightmodel=none, orientation=[90,0,0]);

dens_zrange.mw

The attached worksheet may need to be re-executed as the lightmodel=none feature is undone upon re-opening (in Maple 2015.2 at least).

Someone (the OP?) has deleted the body of the question.

Followup: Since I wrote this post Maple has gained the functionality to conveniently use an image (from file, or float[8] rtable) as the background of a 2D plot. See the background option of the plots:-display command.

That makes it easy to overlay text, or typeset math, or plot axes over an image. And the result scrolls better in a worksheet, with less impact on GUI responsiveness than when using a high resolution density plot.

Re-extraction of such a background image directly from the PLOT structure is tricky. In Maple 2016 the image can be stored in a workbook, possibly avoiding re-extraction from the PLOT structure.

acer

@Carl Love I didn't want to check which global names were not protected across which Maple versions, so I just threw on protection all round. Very likely :-PLOT has been protected ever since it's been in use, so I knew it was overkill for that. But, for example, :-specfunc has been problematic...

You wrote "projected into the xy-plane." What I did works for GRID, but not for MESH (naturally). Possibly relevant for efficiency in some situations is that plottools:-transform might still might turn a MESH into a listlist instead of a float[8] rtable.

I really did mean to convey that the given code worked for the OP's plot3d at hand, but not in general. In some versions of Maple I wouldn't be surprised if careful use of remove were needed to get rid of all substructures not relevent to PLOT. (I feel confident that you know the kind of thing I mean.) And a plot3d call executed with something traditional like shading=zhue rather than a custom shading/coloring might not even contain the color data that's required here.

A more robust approach would be to carefully extract the float (color) data, ensure that it's in a float[8] 2D rtable, get the right ranges for the x- and y-domains, and build up the right PLOT structure. The basic idea is not sophisticated -- it's similar to the observation that the color data in a custom shaded 3D plot might also serve as the color data in a 2D density plot or even a color image (see this old post).

@anton_dys I don't know whether the following will more help you in the short term or confuse things in when going awry for more complicated examples, but...

Your given 3D plot generated using the plot3d command can be converted into a 2D density plot (like the surfdata or densityplot commands generate) without having to do recomputation. And the resulting 2D PLOT structure can even be further adjusted using plots:-display with its size option. And since the original call is to plot3d rather than surfdata there is no need to discretize the expression like sin(x*y) to a Matrix or 2d Array data structure as I did above.

Not all 3D plots can be converted in this way. It works for yours primarily because the data is in a GRID substructure and the surface was shaded by a custon shading scheme.

Having said all that, I still think it might be more prudent for any user who is not conversant with the subtleties of Maple's plot structures to instead rely on the surfdata approach I gave in my original answer (until such time, say, as the densityplot command might respect the colorscheme option differently).

restart;

P3d:=plot3d(sin(x*y), x=-5..5, y=-5..5, view=-10..10,
            colorscheme=["zgradient",["blue","green","yellow","red"],
                         zrange=-5..5],
            style=surface, lightmodel=none, orientation=[90,0,0], axes=box):

P2d:=':-PLOT'(remove(type,[op(P3d)],
              ':-specfunc(anything,{:-AXESLABELS,:-LIGHTMODEL,:-ORIENTATION})')[]):

P2d;

plots:-display(P2d, size=[600, 300]);

@anton_dys I have a pending post on 3D plots and size and aspect ratios. 

For 3D plots the size of the (projected, flat) display window, and the aspect ratios of the 3 axes should be controllable by different means. It would be a terrible mistake if some gui developer conflated them. This special case at hand, with an orientation that happens to line up with the axes, must NOT be used to characterize the wider need.

@Joe Riel A note of caution about pre tags: when pasting plaintext code within pre tags I have to replace lessthan symbols with ampersand-lt-semicolon entities, so that the editor doesn't get confused.

I toggle to html mode in the editor (using its icon) and then paste into a pre tag.

acer