@sand15 I recommend getting Maple 2019.

It comes bundled with LLVM.

For the very best experience in terms of stability and performance I'd also recommend it (or any modern version) on Linux.

@mmcdara For fun, here using Threads:-Seq and a few other storage twists.

Here, 602.30ms for the Box-Muller versus 466.70ms for the default Sample method and 2.31s for Sample's envelope method, in real-time, at N=10^7.

CodeTools:-Usage(Statistics:-Sample(Normal(0,1), 10^7, method=envelope), iterations=10):
memory used=95.36MiB, alloc change=0.52GiB, cpu time=2.33s, real time=2.31s, gc time=21.52ms

CodeTools:-Usage(BoxMuller_ac3(10^7), iterations=10):
memory used=79.96MiB, alloc change=0.78GiB, cpu time=938.50ms, real time=602.30ms, gc time=0ns

CodeTools:-Usage(Statistics:-Sample(Normal(0,1), 10^7), iterations=10):
memory used=76.31MiB, alloc change=0.75GiB, cpu time=466.30ms, real time=466.70ms, gc time=0ns

I was disappointed with the speedup under Threads:-Seq, though I did not try to find the optimal splitting length, given that there is overhead that can swamp if too many threads are allowed for tasks that are too small.

Using Threads:-Task and binary splitting seems a bookkeeping headache, although perhaps a spot in each subvector could store its length and the number of relevant entries.

Also, as written these procedures could actually return more than N values, although it would not be much effort to restrict this efficiently to at most N.

[edit] Apparently I forgot to attach the revision. I'll do that later today.

[edit] I also realize that another 5-10% of the time (and some memory overhead) can be shaved off by forming result R with exactly N entries, and quitting the loop early once N results are attained, etc. I will revise this evening.

@Carl Love I think that you're right, in the sense that it's not clear whether the OP's example is input or the result of some earlier computations. Since the OP asked just last week about substituting into the result of a series call, this Question is less clear than it could be.

@mmcdara Ok, so you are getting 64ms for N=10^5 with _ac2 under evalhf mode. That's a good start.

On 64bit platforms recent versions of Maple are supposed to use the LLVM compiler by default (unless the inmem=false options is passed to Compile, in which case it tries to use gcc from the OS). The LLVM compiler is bundled with the installation of Maple itself.

If your Maple version is "older" you might have to install gcc on your OSX (or Linux) box. It's free.

I don't recall which was the first Maple version to ship with LLVM bundled on the 64bit installs.

If you cannot get the Compiler to work in any version, including 2019.2 say, then there must be some internal problem that prevents it from working. It'd be nice to get this resolved for you.

Mac Dude showed you convert(...,polynom) in his Answer to your series Question from one week ago.

@dharr 

Yes, that is an alternate, convenient syntax for obtaining a procedure T which (just like in my second worksheet) returns unevaluated for nonnumeric argument c.

The overall time to compute can be reduced by about a factor of 2 by giving it option remember (just as in my revision of my second worksheet). That is,

   T := unapply('fsolve'(m(t, c) = -1, t = 0 .. 1/2*Pi), c, numeric, proc_options = [remember])

This is a crude revision, without any effort to handle the excluded entries better.

(I'm in a hurry just now. Later, I'll look at it more carefully. Please don't consider this as mu "submission". It's just to show some simple ideas, keeping the natural style somewhat... Quite a bit more optimization is possible.

But there is also an X1,X2 aspect that I'm not content with.)

BoxMuller_ac1 := proc(N)
  local V, S, X1, X2:
  V  := Statistics:-Sample(Uniform(-1, 1), [ceil(2*N/3), 2]):
  S  := V[..,1]^~2 +~ V[..,2]^~2;
  map[evalhf,':-inplace'](proc(t)
                           if t>1.0 then return Float(infinity); end if;
                           (-2*log(t)/t)^(1/2);
                         end proc,S);
  X1 := select[':-flatten'](type, S *~  V[..,1], numeric);
  X2 := select[':-flatten'](type, S *~  V[..,2], numeric);
  return < X1 , X2>:
end proc:

Tell us the URL for the website of this course, so that we can download the complete details, including the definitions of those procedures.

@mmcdara 

A considerable speedup can be had from using just evalhf (as I showed). True, the Compiler brings more (as I also showed), but evalhf can be quite handy.

The Compiler is still bundled and working in my Maple versions 2018 and 2019.

The is command is not builtin, and is not fast. Even use of a custom anonymous operator as the first argument to select or Select means you've moved away from builtins. Pure builtin use would more like, say,

     select(`>`,S,q)

When you do both Heaviside and subtraction as separate elementwise operations you produce a garbage Vector of length N for each operation. Overhead costs add up.

Apart from your concerns with the behavior of Sample (with its default method), I am surprised by the performance of add on a float[8] Vector.

In the examples below the only difference is the approach to adding up the numbers of outliers in the generated samples. The results concur, but the performance varies.

I would have expected that the first of these would perform comparably to the second.

(I include the others for your interest.)

Download mmc_comp.mw

That was Maple 2019.1 on 64bit Linux. I also tried Maple 2017.2, in which the relative performance was similar.

@Carl Love That's also what I was trying to drive at.

I'd rather see the original problem then some concocted (series?) approximation. And the use of limit as y->infinity on the pade approximation is also odd. The whole thing looks shaky.

@Puneeth Anyone can observe your final call to solve(...,[a,b]) and figure out that you're trying to find a and b. 

What does your computation represent? What do the expressions (which you pass to `pade`) represent? What does n=11 represent?

One mistake is that you set Digits too low. Another is that you use `sum` in some places where `add` would be better.

Another is that (in the statement that assigns to F[k+3] in the loop) you have an instance of F(k+2) which is likely a typo for F[k+2].

Another is that you're missing the closing brace } in the call to solve.

But a bigger mistake is in not telling us properly what you're trying to accomplish.

Is there a question here?

Here is a copy of one of the uploaded images: in case the OP unhelpfully deletes it once again.