Assuming you are running in the standard interface.

Once you have set a breakpoint, Maple will stop at that point and fire up a debugger window. You can now do all sorts of interesting things (eg query the values of any variables at that point) or just hit the 'continue' button, and Maple will carry on executing

I'm a Maple user, just like you. So I have no idea about future enhancements.

If I run your original code, the stopwatch function on my certified Swiss chronometer (aka overpriced wristwatch) says it takes about 33secs from hitting the execute button to the point where output appears on the screen

If I run the slightly modified code which I supplied, the same piece of Swiss engineering says 32secs - so no way is the overall timng 100x slower

I would normally try to debug this but your whole approach to timing seems "wrong" to me, and I'd need to restructure a lot of stuff.

The best way to obtain accurate timings is to use the

CodeTools:-Usage( procName(procArgs))

command. (It even has an option to allow for repeats!)

There are three steps which you need to time separately

1. Your "trick" procedure for producing matrix inverses
2. The inbuilt Maple routines for producing the same(?) results
3. The procedure which compares/prints the outputs of (1) and (2) above

ctrl-c/ctrl-v still works for me.

Easiest way is probably to save/read the matrix in Maple language format.

In the source worksheet

restart;
m:=Matrix(3,3, [[1, cos(x), "astring"],
                           [int(sin(x),x), 1.23e-23, 17],
                           [x->sqrt(x), "anotherString", x*y*z]
                         ]
                );
save(m, "C:/Users/TomLeslie/Desktop/testmat.mw");

and in the target worksheet

read "C:/Users/TomLeslie/Desktop/testmat.mw";

This will return

m := Matrix(3, 3, [[1, cos(x), "astring"], [-cos(x), 0.1230000000e-22, 17], [proc (x) options operator, arrow; sqrt(x) end proc, "anotherString", x*y*z]])

So if the name 'm' is already defined in the target worksheet, it will be overwritten

and if I strip the output from the OP's original post, and run the exeutable parts, I get

C__A := .75;
a := tau = (C__A0-C__A)/(-r__A);
b := tau = (C__B0-C__B)/(-r__B);
c := tau = (C__C0-C__C)/(-r__C);
d := tau = (C__D0-C__D)/(-r__D);
sol := fsolve([a, b, c, d], {C__B = 1, C__C = .2, C__D = .2, tau = 50});

which, obviously fails with the error

Error, (in fsolve) {C__A0, C__B0, C__C0, C__D0, r__A, r__B, r__C, r__D} are in the equation, and are not solved for

Now i'm not too surprised by this error message - after all there are four equations in the OP's original post - carefully labelled 'a', 'b', 'c' 'd' and (as the error message ffrom Maple specifies), aside from the four variables whose initial guesses are supplied ( ie C__B, C__C , C__D , tau) there are eight further unknowns, ie C__A0, C__B0, C__C0, C__D0, r__A, r__B, r__C, r__D

Now perhaps I tried to provide too much information in my original response, so here I'll keep it simple::OP supplies four equations, with twelve unknowns< Four of the twelve unknowns, are given 'initial' guesses in the OP's fsolve() command. Eight of the twelve unknowns are unspecified in any way

If you have four equations containing twelve unknowns, then no solution is possible (even if you provide a good guess for four of the latter)

I tried (NB forcing the argument k to be of tyoe float)

restart;
Digits:=10;
to 10 do
evalf(add(sin(k), k = 1.0 .. 10000.0)) od;

and got

                               Digits=10
                          1.633890998
                          1.633890998
                          1.633890998
                          1.633890998
                          1.633890998
                          1.633890998
                          1.633890998
                          1.633890998
                          1.633890998
                          1.633890998

Likewise, with higher Digits settings, as in

restart;
Digits:=18;
to 10 do
evalf(add(sin(k), k = 1.0 .. 10000.0)) od;

I get

                               Digits=18
                      1.63389102179246230
                      1.63389102179246230
                      1.63389102179246230
                      1.63389102179246230
                      1.63389102179246230
                      1.63389102179246230
                      1.63389102179246230
                      1.63389102179246230
                      1.63389102179246230
                      1.63389102179246230

Note in neither of the above do I actually need the evalf() wrapper - but this begs the obvious question,- should there really be a difference between

restart;
Digits:=18;
to 10 do
add(sin(evalf(k)), k = 1 .. 10000)
od;

and

restart;
Digits:=18;
to 10 do
evalf(add(sin(k), k = 1 .. 10000))
od;

because there is!!!

In my first response to this question I stated that

When performing DFTs, window functions are often used. Using a "Rectangular Window" is often considered as equivalent to using no window at all. However there are cases where its definition is useful. Consider a continuously operating DSP system, so that the "signal" has essentially of infinite length. It is often necessary to perform analysis on a finite "segment" of the infiniite-length signal. Selection of the finite segment is often referred to as "windowing" the signal. In this context, the concept of a finite-length Rectangular Window is meaningful

The wikipedia article you cite states that

The rectangular window (sometimes known as the boxcar or Dirichlet window) is the simplest window, equivalent to replacing all but N values of a data sequence by zeros, making it appear as though the waveform suddenly turns on and off:

So far as I am concerned the Wikipedia article just confirms my original statement about selecting a finite segment of an infinite signal

In the Mathematica help page  which you cite, you will find reference to a "Dirichlet Window" - this is the clever (obscure?) name for a rectangular window. So Mathematica also defines the "completely pointless"  rectangular window, just as Maple does.

Do either of them need to do it- No!

As my second response to this issue stated

If the RectangleWindow() were removed from Maple, would it bother me - well NO!

Can I imagine cases where the existence of the RectangleWindow() command makes life a *little* easier - well YES!

I really can't get very excited about it either way

Let us consider

LIST={0, 0, 0, 0, 0, 0, 0, a^2 b m (-1 + n) n (a^2 + b^2 - 2 E), ... ,0,0, a^3 n(l+1+m) ... }

Now the rhs of this expression is encased within curly braces ie {}, which implies a set: but there are multiple '0' entries, and a set cannot contain duplicate entries, so guess number one is that this is a list and should be written as

LIST=[0, 0, 0, 0, 0, 0, 0, a^2 b m (-1 + n) n (a^2 + b^2 - 2 E), ... ,0,0, a^3 n(l+1+m) ... ]

For the first few entries in the above it would seem that they are comma-separated: but then how does one interpret

a^2 b m (-1 + n) n (a^2 + b^2 - 2 E)

which seems to be space-separated. Maybe this is some kind of "implied multiplication" thing, and (guess number 2) this term should actually be

a^2*b*m*(-1 + n)*n*(a^2 + b^2 - 2*E)

which would make the list

LIST=[0, 0, 0, 0, 0, 0, 0,a^2*b*m*(-1 + n)*n*(a^2 + b^2 - 2*E), ... ,0,0, a^3 n(l+1+m) ... ]

Now the final entry ie a^3 n(l+1+m). Looks like a space-separted issue again, which may (guess number 3) be an implied multiplication, so this entry becomes a^3*n(l+1+m), However, what is one to make of the sub-expression n(l+1+m). Is this really the function n() with the argument l+1+m, or (guess number 4) is this another implied multiplication whihc should read a^3*n*(l+1+m), makin the list

LIST=[0, 0, 0, 0, 0, 0, 0,a^2*b*m*(-1 + n)*n*(a^2 + b^2 - 2*E), ... ,0,0, a^3*n*(l+1+m),... ]

Now obviously for any practical implementation one cannot handle the ellipsis, so the "final" version of this list becomes

LIST:=[0, 0, 0, 0, 0, 0, 0, a^2*b*m*(-1 + n)*n*(a^2 + b^2 - 2*E),0,0, a^3*n*(l+1+m) ];

(Note I have replace the simple equality sign '=' with a Maple assignment symbol ':='

One can store the above in a file, such as LISP.mpl, then read it, and remove zero elements with

restart:
read "D:/Users/TomLeslie/myMaple/LIST.mpl";
remove(x->x=0,LIST);

which returns

[a^2*b*m*(-1+n)*n*(a^2+b^2-2*E), a^3*n*(l+1+m)]

ie the non-zero terms - but I cannot even guess what is meant by your comment

" process the non zero elements and assign them to a function (COEF) "

Hmmmm assign non-zero elements to a function??? Well I've been doing a lot of guessing so far, but I cannot guess what you want at this stage

Consider

restart;
f:=x->piecewise( x>=0 and x<=2000,
                             -0.005*x^2+10.4*x-1230-624*sin(0.002*x),
                             undefined
                           );
plot(f, -100..3000);
f(-100);
f(1000);
f(2500);

When you say

"unbased words again: no file with the executed code, no info about the used OS, even no correct plots. Roly-poly toy."

The operating system is Win7 64-bit

The files with executable code (and I have added version() statements, just so that you can be sure which Maple version was running) are

windows3a.mw

(which as the embedded version command will confirm is Maple 2016.2)

windows3b.mw

(which as the embedded version command will confirm is Maple 2015.2)

windows3c.mw

(which as the embedded version command will confirm is Maple 18.02)

Now when you say

"no file with the executed code" exactly  which file do you want, other than those supplied above?

"no info about the used OS": the OS is Win7 64-bit

"even no correct plots": each one of the above 'mw' files contains correct plots.

The only combination anyone has found (so far) producing incorrect plots is your OS/ your Maple installlation

I'm running 64-bit windows 7 and 64-bit Maple 2016.2, Build ID1194701 - I can't reproduce the "breaks" in the plots which you show.

Your 32-point plots also display correctly on my Maple2015 and Maple18 installations

Sorry, but I don't think I can help with this one

Output using Bartlett-Hann window is highly oscillatory (which is why with 1024 bins) it looks "black". Try 128/256 point DFTs/Plots

The case of a 32-point DFT/PLOT doesn't show any 'breaks' for me (64-bit, Maple 2016.2) - just more obvious oscillatory behaviour

Extended my original resonse (slightly) so that not only is the minimum value returned, but also the "index" and "argument" where the minimum value occurs. What am I missing?

restart;
f:=x->cos(x): # function whose minimum is required
a:=0: # lower limit
b:=evalf(2*Pi): # upper limit
n:=50: # number of steps
min([seq( f(j), j=a..b, (b-a)/n)]); # minimum value obtained
minInd:=min[index]([seq( f(j), j=a..b, (b-a)/n)]); # index of minimum value
argMin:=a+(minInd-1)*(b-a)/n; # function argument where minimum occurs
f(argMin);# check value at argMin

I'm not exactly sure what the question is here: I see two possibilities, both of which are addressed in the attached worksheet

1. Is there a difference between the DFT of an unwindowed signal and one subject to a rectangular window. The answer is no! The first execution group in the attached (hopefully) demonstrates this. I have chosen for this demonstration to use a sinusoid as the signal, for the simple reason that everyone "knows" what the spectrum of a sinusoid actually is, and hence the results are easy to interpret
2. From (1) above, there is an obvious question - if a rectangular window does nothing at all, then why bother having one? One (very poor) reason is that the terminology exists in many texts discussing DFTs, so a naive user might expect to see the capability, even if it does nothing useful! A second (better?) reason is that, if one wants to consider the different spectra which arise for the same signal, when subject to different windowing functions. The second execution group in the attached shows the spectrum of a sinusoid when three different windowing functions are applied: one of which is "Rectangle". If the "Rectangle" window function did not exist, this code would be (marginally) more difficult to produce, because one would have to treat the "unwindowed" (ie Rectangle window) as a "special case")

windows2.mw

If the RectangleWindow() were removed from Maple, would it bother me - well NO!

Can I imagine cases where the existence of the RectangleWindow() command makes life a *little* easier - well YES!

I really can't get very excited about it either way

Given the questions

1. "We see an uncommented code which (intentionally or unintentionally) produces two empty plots"
2. What is the aim of the RectangleWindow command which does nothing 
   but the conversion of a Matrix(1,N,...) /Array(1..N,...) to a Vector[row](N,...)?
3. Could such help be called friendly to Maple users?

The corresponding answers would be

1. The code is uncommented, but does not produce "two empty plots". It produces two plots, each of which consists of a single point, corresponding to the list index 1. The selected plot options means that this point is "not obvious". Adding a couple of plot options (as in the attached) may make this a little clearer
2. When performing DFTs, window functions are often used. Using a "Rectangular Window" is often considered as equivalent to using no window at all. However there are cases where its definition is useful. Consider a continuously operating DSP system, so that the "signal" has essentially of infinite length. It is often necessary to perform analysis on a finite "segment" of the infiniite-length signal. Selection of the finite segment is often referred to as "windowing" the signal. In this context, the concept of a finite-length Rectangular Window is meaningful
3. So far as I can tell, there is no error in the Maple help (or associated code). It is confusing (as is your revised version) because there are actually two "signals" and two essentially separate calculations being performed. Splitting these (as in the attached) may make things a little clearer

windows.mw