@Glowing wrote:

• Some users of Maple actually enjoy this design, so the Maple guys may never fix it, this is really sad.

Whether they enjoy it is largely irrelevant. The significant point is that people have relied on a particular design for years for a huge amount of code that's still in use. The doctrine of backwards compatibility says that a command cannot be changed in a way that will cause existing programs to act differently than what the offcial documentation originally specified.

@Glowing 

I agree with you wholeheartedly that the special evaluation rule of evalf(..., n) or evalf[n](...) is not properly documented on its help page. I've learned what I know about it mostly by experimentation. These commands establish a computational "environment" that changes the way that the stuff between the parentheses are evaluated. This is in contrast to the vast majority of commands, which first evaluate what's between the parentheses and then apply the command (as we've been taught to do in elementary arithmetic and algebra).

I think that this is something that cannot be "fixed", due to the need to maintain backwards compatibility. That is, making the desired change to evalf would cause decades of old programs to act differently. 

The alternative would be a new command akin to Mathematica's N or Scot Gould's sigfig.

@Stretto Any name---a, b, x---is inherently a monic, first-degree, one-term polynomial. The a and b in gcd(a,b) are simply themselves; they're not placeholders for anything else, such as possibly some more-elaborate polynomials. There needs to be some way to distinguish whether one wants the GCD of integers or polynomials. That's why there are two commands: gcd and igcd. In the case of igcd(a,b), the a and b are placeholders for integers, which is why that command returns unevaluated.

All this is nothing new and has nothing to do with any upgrade. It's explained on the help pages for those commands, and it always has been, as far as I can recall. 

@fatemeh1090

If you look at the matrix extracted from Excel (as shown in the attached worksheet), it's clear that the 1^st row is just labelling and the last 10 rows are garbage, not data at all. Thus, I have

R:= upperbound(XL,1) - 11:

to exclude 11 rows. That's the only change that's needed. The end results are very close to the first case because the data for the subsequent three cases are very close to the first case.

Download 3dModelFit.mw

MaplePrimes apparently can't display my worksheet due to the fully displayed matrices, but you should see what I mean when you download it. Here's the plot:

@fatemeh1090 Maple worksheets alone don't contain the data; they only contain what's shown on the screen. In order to duplicate your results, I need the Excel file. Obviously, you need to filter out the Matrix entries that are just labels like "Y" instead of numeric data.

@Kitonum You wrote:

• It seems that in the second case Maple first rounds each of the operands to 2 digits, and only then performs the calculation.

Yes, that's exactly what happens, and that's by design. This is nothing new.

@fatemeh1090 Please organize the data into a single matrix in Excel. I don't use Excel, so I can't look all over your worksheet for 4 separate groups of data.

Or, put 4 Excel worksheets in your file with each worksheet having a matrix starting in its upper left corner.

@Scot Gould Yes, that's right, they're substituted first. Arithmetic operations between exact rationals (including integers) are done without regard to floating-point arithmetic. So 1014-1007 is reduced to 7 before it's processed by evalf, and 7 can be adequately represented in 2-digit precision.

@fatemeh1090 Great, you have a model that's linear in its parameters, so it should be easy to find the optimal solution.

Can you get the data into Maple with package ExcelTools?

@fatemeh1090 Yes, there's a few things Maple can do. Do you have a theoretical model to fit to this data? Or do you just want a smooth plot of the surface? Or something else? 

@Magma Thanks, all is clear now.

@Magma What is the upper limit of m? Obviously m <= n^2 - 2*n + 1. But it's trivial to find solutions for m <= (n^2 - n)/2.

@Magma I'm confused by your Reply immediately above. Can the r x r matrices be indentified with a field embedding, i.e., an injective function phi: GF(2,r) -> GF(2,1)^(r x r) that preserves field operations? And, if so, can a formula for phi be given? Is the image of phi simply the diagonal matrices?

@Magma It is surprising that Maple 2019 shows a substantial speedup of my code, but not much change for VV's. I can't believe that RowReduce has been substantially improved, because it was already extremely efficient. Using the 80x80 matrix that you just posted, I get

CodeTools:-Usage(VVMDS(A,8)): #VV's procedure
memory used=3.82GiB, alloc change=0 bytes,
cpu time=39.83s, real time=39.52s, gc time=5.38s

CodeTools:-Usage(IsMDS(A,8)): #Carl's procedure
memory used=2.65GiB, alloc change=-4.00MiB, 
cpu time=18.56s, real time=17.56s, gc time=5.59s

@Kitonum Thanks for the shorter syntax. I see now that that syntax is mentioned on the page ?Line, but I missed it before.