@itsme As I'm sure you're aware, more usual array plots have the problem that right-click-export only exports one single cell's plot to a graphics format file. That is, IMO, a serious bug/limitation in the GUI's handling of GUI Table's of plots. And it affects this colorbar approach as well. I hope that it gets fixed in general.

Apart from export of the whole worksheet (to .pdf say) I'm not aware of any other way to get proper export of side-by-side multiple 3D plots or 2D/3D plot mixes.

This is why for a 2D plot and its colorbar an appealing way to proceed (at present) is to display both in a single plot -- with tickmarks and other things tweaked or faked accordingly.

@Carl Love In the attached worksheet I inlined (a modified version of) Ceil into Sols_z6z7 and then compiled that to Sols_z6z7c. I gave option threadsafe to Sols_z6z7 in order that it could be run in parallel without its call_external being blocking. Then I changed SolsRecurse to call Sols_z6z7c without evalhf.

On my 64bit Linux i5 this brought timing for the final full example from 26 minutes down to 18 minutes, where the latter is 68% of the former. I used Maple 2015.1.

I noticed that when running the original evalhf based version `top` reported a steady 365 "% CPU" on my quad-core i5. The compiled version ran steady with 295 "% CPU". The load averages reflected those numbers too. I find that difference in peak processor usage interesting. (A hypothetical number of 400 %CPU would mean all four cores were running flat out.)

LatticeCountmodif4f.mw

I made earlier experiments by only compiling Ceil. For example, I did it with calls to compiled Ceil wrapped in eval, using evalhf around the calls to Sols_z6z7. And I did it with compiled Ceil (and no eval) in Sols_z6z7 without evalhf. And I tried it with float arguments and a few more trunc calls (on both, or either proc separately), and with integer arguments, and so on. But the best I got with any of that was a timing slightly worse than the original.

For the inlined version of Ceil I used a single operator-form call to `if`, rather than a pair of such where one condition allows a return that didn't need trunc. You'll know what I mean. That change made no difference on the original evalhf version, but it did seem to speed it up a little for the compiled version. You could retest both, naturally.

The initial complaint from Compiler:-Compile about not handling rational arithmetic I got around by simply multiplying x/y by the float 1.0. (In the inlined version this became 1.0*a1/a2.)

I didn't put types on the declarations of parameters and locals of Sols_z6z7, and am not sure whether doing so would change the performance.

The final long example call to SolsParallel "used" 225Gb, while allocation stays very low. This means that a great deal of garbage collection has taken place. I wonder whether SolsRecurse could be called under evalhf inside SolsParallel (which would have to wrap the call to Sols_z6z7c in eval). Of course this would require alterations in how SolsRecurse is coded. Perhaps Vector arguments and an extra argument to indicate how many values are yet present in the Vector might work. I'm not sure.

@Markiyan Hirnyk The post you cited is about creating a 3D surface plot that has custom shading (by z-values). But in itself that does not provide a way to obtain an associated colorbar, which I believe is the central point of the question.

Actually, a 3D plot with a custom coloring (such as the cited link demonstrates) makes for a slightly more difficult case in constructing the corresponding colorbar as a separate 2D plot. Eventually I'd like to accomodate this more involved case in some code I'm investigating for generating 2D colorbars. But to begin I'm just looking at the simple, stock HSV shading=zhue case, for which the colorbar construction is simple. To begin I'm looking at conjoined display of 3D plot and 2D colorbar.

In Maple 18 a vertical color gradient can be applied directly and efficienctly in the plotting call, using the colorscheme option.

Eg,

restart:
N:=25000:
xy:=LinearAlgebra:-RandomMatrix(N,2,generator=0.0..1.0,
                                outputoptions=[datatype=float[8]]):

st,str:=time(),time[real]():

P:=plots:-pointplot(xy, colorscheme=["zgradient",[black,red]],
                    symbolsize=4):

time()-st,time[real]()-str;

                          0.090, 0.093

kernelopts(version);

    Maple 18.02, X86 64 LINUX, Oct 20 2014, Build ID 991181

acer

@itsme Does your example get laid out acceptably better in Maple 2015.1?

Explore(plots:-display(Matrix((i,j)->plot(sin(a*x), x=0..5),4,4),
                       labels=["x", "this is y"]),
        parameters=[a=1..2], placement=left, size=[1200, 1000]);

@Carl Love It is not unquestionable that cp=3220 is mathematically a root of expression pp just because eval(pp,cp=3220) returns exact zero.

It may be true that cp=3220 is an exact root of the given expression pp for any finite value of x. But that fact is not demonstrated just because eval(pp,cp=3220) returns exact zero.

It is not even true for ee an expression which is univariate (in name cp) that cp=val is a root of ee just because eval(ee,cp=val) returns exact zero. And the situation is more complicated for multivariate expressions. Here's a univariate example:

ee:=cp/(8*sin(cp^2)*cos(4)*cos(cp)^4-8*sin(cp^2)*cos(4)*cos(cp)^2
        +sin(cp^2)*cos(4)+8*sin(cp^2)*sin(4)*sin(cp)*cos(cp)^3
        -4*sin(cp^2)*sin(4)*sin(cp)*cos(cp)-8*cos(cp^2)*cos(4)*sin(cp)*cos(cp)^3
        +4*cos(cp^2)*cos(4)*sin(cp)*cos(cp)+8*cos(cp^2)*sin(4)*cos(cp)^4
        -8*cos(cp^2)*sin(4)*cos(cp)^2+cos(cp^2)*sin(4))
        -2/(8*sin(cp^2)*cos(4)*cos(cp)^4
        -8*sin(cp^2)*cos(4)*cos(cp)^2+sin(cp^2)*cos(4)
        +8*sin(cp^2)*sin(4)*sin(cp)*cos(cp)^3
        -4*sin(cp^2)*sin(4)*sin(cp)*cos(cp)
        -8*cos(cp^2)*cos(4)*sin(cp)*cos(cp)^3
        +4*cos(cp^2)*cos(4)*sin(cp)*cos(cp)
        +8*cos(cp^2)*sin(4)*cos(cp)^4-8*cos(cp^2)*sin(4)*cos(cp)^2
        +cos(cp^2)*sin(4));

eval(ee,cp=2);
                                      0

ff:=combine(ee);
                                      cp - 2       
                          ff := -------------------
                                   /  2           \
                                sin\cp  - 4 cp + 4/

eval(ff,cp=2);
Error, numeric exception: division by zero

limit(ff,cp=2);
                                  undefined

limit(ee,cp=2);
                                  undefined

So, we would go wrong by accepting only the result of exact zero from eval(ee,cp=2). So I don't see anything wrong with Markiyan's wanting to examine things further than just accepting eval(pp,cp=3220)=0.

And relying on high Digits for a floating point evaluation can also be more tricky. I'm not sure how tools like shake might do with the original expression pp, though.

@Wang Gaoteng The nonconvergence problem depends on the values of Digits (which is being used for both working precision and the accuracy goal).

It can be seen even when supplying a point that should be close enough -- internally `fsolve/sysnewton` gets close to the solution but bails when it fails to attain enough accuracy.

Notice that, in the cases where fsolve does return a numeric result below, there are relatively few correct digits in the result (relative to the Digits used). It's an interesting example.

restart:
f1 := {y = tan(-8*Pi*(1/180))*x,
      (x-cos(-8*Pi*(1/180))-sin(-8*Pi*(1/180)))^2
       +(y-sin(-8*Pi*(1/180))+cos(-8*Pi*(1/180)))^2 = 1}:
solve(f1);
                /       /2    \          /2    \    /2    \\ 
               { x = cos|-- Pi|, y = -tan|-- Pi| cos|-- Pi| }
                \       \45   /          \45   /    \45   // 
evalf(%);
                    {x = 0.9902680687, y = -0.1391731010}
for d from 10 to 25 do
  Digits:=d:
  sol:=fsolve(f1,{x=0.5,y=-0.5});
  if type(eval(sol,1),specfunc(anything,fsolve)) then
    print(d, FAIL);
  else
    print(d, sol);
  end if;
end do:
                                  10, FAIL
                                  11, FAIL
                12, {x = 0.990266468986, y = -0.139172876129}
                                  13, FAIL
              14, {x = 0.99026777793041, y = -0.13917306008923}
                                  15, FAIL
                                  16, FAIL
                                  17, FAIL
                                  18, FAIL
         19, {x = 0.9902680681796783120, y = -0.1391731008810966729}
                                  20, FAIL
                                  21, FAIL
      22, {x = 0.9902680687192257411404, y = -0.1391731009569251190394}
                                  23, FAIL
    24, {x = 0.990268068742932805847978, y = -0.139173100960256929701771}
                                  25, FAIL

@Rouben Rostamian  I would not be surprised if there were things in PDETools that could make it easier to do with D.

@Alejandro Jakubi I would guess so, in the simplest case.

But there are a few mechanisms by which an externally called routine (call_external, set up using define_external) can call back to Maple using functions in the OpenMaple API. For example, EvalMapleProc and friends, or queryInterrupt, or even MapleUserInfo... and I do not know whether any of these would allow the kernel to check the timelimit.

@kegj It's difficult to debug your code efficiently when all we have to go on is vague description. (Eg. first you write print (A) gives "no result", and then later you write that it gets "an output A".) Please just use the green up-arrow icon on the response editor here, and upload a worksheet containing what you've tried so far. That way we can ascertain what kind of "array of elements" may or may be yet assigned to any name, and guide you, etc.

By the way, have you read through the Programming Guide? That is one of the product manuals. I'd suggest you start with chapters 1-6 and try the examples from chapters 2-5, and then consider chapters 7-8 if you have time. Don't get bogged down in the heavy details of chapter 6.

@nm ...Just for the other readers: the term builtin is being used to refer to a procedure with option builtin. See here.

That pretty much almost always means a procedure with little or no interpreted code in its body -- the code for it is written in C and compiled into the Maple kernel interpreter.

Sometimes routines get moved from interpreted Library code to precompiled kernel code, to get better speed. And on rare occasions routines can sometimes even get moved from kernel out to the interpreted Library -- usually to allow intermediate garbage collection (if otherwise problematic in memory use).

@kegj If you are using 2D Math input mode (the default for new users) then print (A) with a space before the bracket will get interpreted as the implicit multiplication print*A rather than a call to the print command.

@Preben Alsholm I have submitted a bug report.

What you've shown in your followup Matlab figure is sometimes referred to as a colorbar.

I have some code for Maple 2015 which automates construction and placement of such a thing, from a given 3D plot with HUE/HSV coloring.

But I wish to make some adjustments to make it more robust (to handle both GRID and MESH structures for 3D plots) and customizable (orientation, position, tickmarks), and am also still fiddling with the automated sizing. I hope to be able to branch off a post for it towards the middle of next week.

acer

With some triple bypass surgery the procedure InlinedNewton below gets the bodies of the procedures prccons, prcconsJ, and s3 inlined into it. And it is then singly Compiled.

The singly Compiled InlinedNewtonc runs somewhat faster than did the previous Compiled `Newtonc` (which called compiled versions of those three other procedures) on a single iteration loop from a single initial point, with tolerance target 2e-6 and problem size N=50. And `Newtonc` was faster than uncompiled `Newton` even when that too called the three compiled worker procedures.

It's appropriate now to find examples which need multiple initial points in order to converge.

There are also the "extra parameters" yet to introduce, which must be done somewhat carefully as some of the ToInert/FromInert inlining is hand-edited.

Download newtoncompiled5.mw