@casperyc So Mma's SingularValueList would be the right one to test, since the full decomposition (into 3 matrices) provided by Mma's SingularValueDecomposition is not necessary to assess the rank. My supposition -- which I have not yet tried to confirm myself with timings -- is that in at least Mma 10.0.x and earlier the timings for SingularValueList would be very close to those of Rank.

Ok, since typing the above paragraph I went and looked at the Wolfram Language help page for MatrixRank. In its "Properties and Relations" section it says, "MatrixRank[m] is equal to Length[SingularValueList[m]]:". The essential aspect is that the singular values are computed and used.

So I would expect that either SingularValueList[m]; // AbsoluteTiming matches MatrixRank[m]; // AbsoluteTiming closely in Mma 10.1 or Wolfram has switched to another scheme for computing MatrixRank in Mma 10.1 (and not yet updated the online help).

The online Wolfram language help page for both MatrixRank and SingularValueList  currently say in their footers that they were last updated in 2007 (6.0).

@Preben Alsholm Not a coincidence, I suspect: I exchanged mail with two other people about that very example.

Anyway, it looks like a bug that's been around for some time.

@casperyc Thanks. The difference in timing that you report between Mma 10.0.x and 10.1 is interesting.

I'm unaware of any change in MKL 11.2 that would account a difference of that proportion. And also your i7 940X doesn't have AVX extensions. So now my best guess is that Mma 10.1 might be computing the rank of a float Matrix differently than it did before. Ever since I can recall all of Matlab, Maple, and Mma have computed such a rank by examing how many of the singular values are proportionally close enough to the largest singular value. That is very likely why, for example, the performance of double (machine) precision float matrix rank computation is essentially identical at almost all sizes up to at least n=8000 in Maple 2015, Mma 10.0, and the Matlab of the same year, as far as I know. Those are very likely all just using the same MKL function, in the same way, to compute all singular values and compare.

Now, some recent LAPACK versions have included some new functions for QR decomposition, and these may be now appearing accelerated in MKL 11.2. Those may also be rank-revealing and (hopefully) more robust than earlier QR implementations. (There is a reason why Maple's LinearAlgebra:-LeastSquares offers both SVD and QR methods. The QR approach -- historically -- traded off robustness for speed. So any new and robust and rank-revealing QR function would be quite appealing.)

Once I get my hands on Mma 10.1 I'll time their SingularValues command against their Rank command, and see how that pair compare in 10.1 versus how that pair compared in previous releases. It may take a little while since Wolfram don't have a good track record with making new releases available for download in a timely way to all customers. (This is not the first new release for which I've had to wait, for no good reason...)

@Preben Alsholm A bug report has been submitted.

The following basic example is interesting.

restart;
eq:=.4*eta-0.8e-1+(.1*(.4*eta+1))*(2-x)=0:
isolate(eq,x);

Conversion to rational is one way around the the above example's problem. Another (for that example, at least) is isolate(normal(eq),x).

@casperyc Thanks, the extra information from Mma 10.0.x would be useful for comparison to your Mma 10.1 data.

I think that total memory allocation (as reported by an OS tool rather than by the application) would also be useful for sizes as big as n=7000, n=8000 etc. Sure memory is cheap, but I do believe that with default settings (eg. history-length for Mma, gcfreq for Maple) it would serve to know how tractable large problems are. Even with a lot of RAM available it would serve to know the limit sizes possible.

@Alejandro Jakubi  I agree, gcfreq should be left as default, and similarly for UseHardwareFloats.

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.