BTW, a better test is to use default settings, and putting the Mma history length to 0 is not default!

@casperyc How about posting your machine specs in... English, and not as an image. Also helpful would be the output from kernelopts(version), but as text not an image which not all of us can see in full. Also, please wrap in CodeTools:-Usage rather than just time[real]. Thanks.

It would be interesting to know how your machine did under Mma 10.0, or 9.0.x, as your cited numbers for Mma 10.1 seem quite unusual.

My (old) quad-core Intel i7 930 @2.80GHz running a Worksheet in the Std GUI of 64bit Maple 2015.1 takes 17.5sec for the n=3000 case while in Maple 18.02 it took 29sec. But my i7 930 takes 760sec for the n=8000 case whereas the time reported by you on your quad-core i7 @400GHz is about 4 times faster.

By the way Nasser at www.12000.org reports identical timings when comparing his Maple 2015.0 and Mma 10.0.2 under 64bit Windows 7 on an i7-3930 @3.02GHz with the time for n=8000 at about 180sec each. Again, the time you report for Mma 10.1 is very fast, and I'd like to know whether it differs greatly on Mma 10.0.1. (All I can think of as yet is that MKL is making much better use of the AVX 2.0 in your CPU, or something weirder like Mma dropping from the robust SVD approach always favoured by Maple, Matlab and Mma historically in favour of a QR approach, or possibly even GPU use. Only the first of those seems reasonable, to me.)

@Wolff FYI, a "MathApp" implementation of the Monty Hall problem using Embedded Components, which works in the MaplePlayer and the MapleCloud, exists here.

The use of Embedded Components removes the need to pause computation (as you've asked in this message thread). It could also be done with Maplets, although that would not work with the MaplePlayer or MapleCloud.

@Rouben Rostamian  Indeed, it is quite a natural way to make the test, and very often used.

(Btw I used it myself in the brief code of the Answer I made in that thread you cited, on which you submitted the worksheet you mention in a Comment.)

@Rouben Rostamian  Thanks very much.

@Glowing I don't see what point you're trying to make. Post a full example, with a full explanation.

@Carl Love The relative speeds will quite likely depend on the number of assigned entries (and possibly on the type, etc, of the indices). Only Rouben can say what his use cases are, naturally.

Unless the code had an explanatory comment then I'd suggest that is not best programming practice to use so less well-known a feature to eke possibly nonessential performance gains when a clear alternative is in common use. Someone may look at the code down the road... That is just an opinion, of course. Again, naturally, only Rouben can know whether the query is performance critical to the programming.

@Carl Love For fun.. in Maple 2015 one could do something like the following with embedded components.

As coded, it pauses each time though the loop with a dark red box until either the box is pressed or maxwait*1 second elapses. Well, that was my intention. I used 2015.1, and maybe it'll work for someone else too.

With Sleep(1) there can be a delay of up to that duration of 1 second between pressing the box and the return. I hard-coded the Sleep(1), but that could be adjusted or made optional (with the maxwait adjusted accordingly, depending on the step, etc).

Of course, the source for defining PauseBox could go in a Startup Code region or a .mla archive, or read from file, etc.

restart:

PauseBox:=module()
  export Blank;
  local ModuleApply, but, imgs, imgu;
  ModuleApply:=proc({maxwait::posint:=5})
    local butaction, count, tb;
    uses DocumentTools, DocumentTools:-Layout, DocumentTools:-Components;
    tb := InsertContent(Worksheet(Table(Row([ToggleButton(':-identity'="foo",
                                                          ':-unselectedimage'=imgu,
                                                          ':-selectedimage'=imgs)]),
                                        ':-exterior'=':-none')),
                        ':-output'=:-table);
    but := tb["foo"];
    count := 0;
    while GetProperty(but, ':-value')="false"
      and count < maxwait do
      Threads:-Sleep(1);
      count := count+1;
    end do;
    return NULL;
  end proc:
  imgu := Array(1..20, 1..20, 1..3, (i,j,k)->`if`(k=1,0.5,0), ':-datatype'=float[8]):
  imgs := Array(1..20, 1..20, 1..3, 1.0, ':-datatype'=float[8]):
  Blank:=proc()
    uses DocumentTools, DocumentTools:-Layout;
    InsertContent(Worksheet());
    return NULL;
  end proc:
end module:

for i from 1 to 7 do
  print(i);
  PauseBox( maxwait=10 );
end do;
PauseBox:-Blank();

@Carl Love Hi Carl, may I ask what you mean by, "the box often obscures the output"? Do you mean that it obscures the main window (only) until it is dispelled? Are you talking about popup dialogues?  Thanks.

I haven't yet been able to do anything meaningful with the hypergeom term, and have so far only gotten the whole down to forms like,

  - 1/25*Pi*(25+5*5^(1/2))^(1/2)*2^(1/10)*binomial(-1/2,-3/10)
  + 2^(4/5)*hypergeom([-1/5, 1/5],[6/5],1/2)
  - 1/2*2^(3/5)
  + 1/2

By the way, in at least Maple 2015 it seems that the original splitting of the integral might be done by just,

int(convert(abs(x-(-x^5+1)^(1/5)),piecewise), x = 0 .. 1);

It might be that some tricky, key manipulation (of the summand) might be done when it's in a form like this, but I don't know...

/infinity                                           \
| -----   /      (4/5 - _k1)                       \|
|  \      |     2            GAMMA(- 1/5 + _k1)    ||
|   )     |- --------------------------------------||
|  /      \  (5 + 25 _k1) GAMMA(4/5) GAMMA(_k1 + 1)/|
| -----                                             |
\_k1 = 0                                            /

                      1/2         1/2  1/10    3/5
            Pi (5 Pi 5    + 25 Pi)    2       2
     - 1/25 ------------------------------- - ---- + 1/2
                GAMMA(4/5) GAMMA(7/10)         2

I used subsindets to change the hypergeom (only) to a Sum, above. That was after things like this,

simplify(expand(convert(combine(J),radical)));

acer

@sanorinko You can do,

seq(V[i], i=1..10);

to get those entires as a sequence.

The seq command has special evaluation rules and so can accept V[i], where `i` is just a symbolic name, as its argument.

@StefKi Thanks, that is useful information.

It may match a type of expression which I was (somewhat successfully) trying to simplify a while back.

Your comment contains an image of an expression. Could you use the green up-arrow on the comment editor here to upload a worksheet that contains your candidate expression? It's a bit long for typing out by hand.

Can you not provide a shorter example of the kinds of expression you have?

Or tell us what kinds of function calls it has inside it? (elementary functions, trig functions, radicals, special functions, or what...)?

Have you tried simplify(expr, size) where expr is your long expression? Do you expect that some function calls will combine? These are just guesses, because you've provided so few details.

acer

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