@vv As far as I can see so far, the example runs without error primarily due to either passing restricted ranges of due to passing float ranges.

If you pass the ranges x=-3.4..0 and y=0..3.4 then Maple 2016.x will return an incorrect result (failing to find value -1 at x=-Pi and y=Pi), regardless of whether the `location` option is supplied. 

I see the following in all of Maple 2015.2, 2016.0, and 2016.1. Notice that the location option does not seem to make the difference. With entirely float ranges the incorrect result attains, and with entirely rational ranges the ormap error is emitted. (And with some mixed ranges I saw mixed situations, but always the same whether `location` was supplied or not, as far as I noticed...)

restart; minimize((x+y)^2+cos(y), x = -34/10 .. 0, y = 0 .. 34/10, location=true);
Error, (in unknown) mapped procedure in `ormap' must return true or false

restart; minimize((x+y)^2+cos(y), x = -34/10 .. 0, y = 0 .. 34/10);               
Error, (in unknown) mapped procedure in `ormap' must return true or false

restart; minimize((x+y)^2+cos(y), x = -3.4 .. 0.0, y = 0.0 .. 3.4);                   
                                              -0.96679819

restart; minimize((x+y)^2+cos(y), x = -3.4 .. 0.0, y = 0.0 .. 3.4, location=true);    
                           -0.96679819, {[{x = -3.4, y = 3.4}, -0.96679819]}

That error from `ormap` is due to a check against results from `is` without accounting for a possible FAIL return. But not finding x=-Pi, y=Pi seems another issue.

[edited] oof. Line 39 of `minimize/cell/multivariate` sets up simple bounding inequalities from the ranges on the variables. It looks like it could be mistakenly using lhs(boundL[i]) instead of rhs(boundL[i]) to utilize the upper bounds. For the example at hand that'd mean that `isolve` would get the wrong bounding inequalities for the special case for y=Pi*_ZXXX . So the interior point y=Pi,x=-Pi wouldn't get found.

It looks to me like what you might have shown in your second timing is the how long it takes for Maple's CUDA attempt to fail and fall back to its regular mechanism. That would not be the same as a comparison "with/out CUDA" -- which would need it to have succeeded.

So perhaps the CUDA linkage is not working on your machine. How about adding the details of your Maple version and operating system?

acer

@anton_dys It's still less efficient since it calls `rhs` each time it's called.

@Carl Love ModuleCopy is invoked each time ModuleApply makes the Object(...) call. I think of it as copying the prototype to a new instance.

The 3rd argument of ModuleCopy is assigned to the local `labs` (magnitude) of the new instance (object), and if there is a 4th argument of ModuleCopy then it is assigned to the local `larg` (argument) of that new instance. The 3rd argument of that ModuleCopy is the lhs of the infix call to `∠`and the 4th argument of that ModuleCopy is the rhs of the infix call to `∠`, because those are the 1st and 2nd arguments respectively to the prefix call to `∠`.

The word "ModuleCopy" doesn't seem especially intuitive to me. I sometimes think of it more like an Instantiator (from template), or Factory.

Hmm, I'm not entirely sure what would happen if you replaced the internal calls to `∠` (ie. those which are not uneval quoted) with a call to ModuleApply. It's possible that it'd not be correct... some distinction between the ModuleApply of the class template and that of the new instance? I mean, hmm, are those calls (inside static exports `*`,`+`,`evalf`) to be considered more like calls to thismodule? You could try both and see.

@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).