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

What does it mean, your question about Sage on a Maple forum?

Are you trying to ask a question about SageMath usage or syntax? Because, if you are, that has nothing to do with Maple.

Are the contents of those particular Matlab files (of yours) stored purely in plain text?

Perhaps you are describing a pure OS phenomenon on text files, which only MS-Windows controls?

@MapleUser2017 As mentioned, another possibility is an optional keyword parameter (which makes sense for using just a sole name to toggle on the alternate behavior).

Below, passing the name g acts the same as passing g=true (and omitting it acts the same as passing g=false).

restart;
graph := proc(fn::anything, {g::{truefalse, name}:=false})
   if g=false then return fn;
   else return plot(fn, gridlines);
   end if;
end proc:

graph(x^2);
graph(x^2,g);
graph(x^2,g=false);
graph(x^2,g=true);

Don't you suspect that this is a difference between the Classic and (possibly all versions of) the Standard Java GUIs?

@Christian Wolinski You originally started a Question thread (in which you described problems with lighting options in the Standard GUI, and compared with the Classic GUI in R5.4).

That thread had about 11 responses, links to Rouben's older Question, and other details and examples. It was mostly examples, report, and a very interesting discussion, although you didn't really ask any direct question in it. It appeared to describe a loss of functionality between Classic and Standard Java GUI related to multiple light sources in 3D plots.

You've now said that you deleted that thread (and all that lengthy conversation). Why did you delete it?

Before you deleted the long, original thread (which contained all that information) you also made a duplicate Post, which contained an example from the original threads. Why post the duplicate?

Why would anyone bother taking the time to answer your questions, when you respond to Answers by deleting your original question after the fact?

Was it your intention to call,

     LinearAlgebra:-Determinant(...)

or to load that package before you call its Determinant export?

    with(LinearAlgebra):

    Determinant(....);

and so on.

The problem seems to be this, specifically:

When opening a previously saved Worksheet or Document, the initialization file will not be read following any restart (either from the restart command or via the menubar icon).

Removing any restart call from the beginning of the worksheet does still allow the initialization file to be read, if the worksheet is re-saved and re-opened.

But then the (very useful, and fundamentally common) act of issuing any restart will not cause the initialization file to be re-read.

So, at present in Maple 2019.2, the functionality of restart and initialization files are mutually exclusive for previously saved worksheets.