@Østerbro Ok, I have it now. I see two things to deal with: a problem in the static `*` procedure, and the Units Formatting mechanism. I will endeavor to accomodate both.

@Østerbro That download link does not work for me. Please try again (just insert a link to your comment, not the entire contents inlined). I suggest a simple name with no special Danish characters, such as file.mw with only one period in the filename (your above had two). You can test that it worked, using the Preview to test the download link, before posting any new comment.

I don't really understand why you have used the 2D Input that looks like & (ampersand) before the typeset angle symbol. Was that deliberate, because you knew it wasn't the way it's intended to be used, but just wanted to convey the computation flow you want?

I think that I can enhance it, to work with units...

@Østerbro I cannot read that tiny font, and have little wish to type it all in by hand. Please attach a worksheet/document. Thanks.

I am whipping the module object into better shape, and will augment if I can figure out exactly what more you want or need here.

@vv I think your original 1st and 2nd example can be covered by correcting the lhs/rhs thing, and robustifying the `is` call used to `ormap` to avoid problems with FAIL (from `is`).

And then, yes, the 3rd example would return unevaluated for me, which as you say is at least not a wrong result. I'll think about that 3rd one too. As you say, the solution is easy for a person, but how it may misstep in the code may be another thing...

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