We do not recommend to mix different precisions. That is because sematic of mixed-precision computations are not well posed/defined. Do we have to use maximum precision of two arguments, or minimum, or average or else? That is a long-standing and non-resolved question in scientific community.

If you want to compare different precisions, then do all computations using one precision, store results for each precision (mat/txt file). And finally use the highest precision to load and compare them.

For example, assuming B>A:

Setup mp.Digits(A), run all the computations and store final results for precision A. Then setup mp.Digits(B) and re-run all computations from the start and store results for precision B. Setup mp.Digits(B), load all the results from files, and compare results (do not re-run the computations).

"User-written subroutines are executed in quadruple precision (34 digits) regardless of number of digits possessed by arguments passed to the subroutine."

Yes, this is true, if all expressions in subroutine use only arguments, e.g. r = a+b.

But, if expressions use some constants, e.g. r = sin(mp('pi')*x) - the final precision will be different. Because toolbox uses default precision to convert entities of "unknown" precision, like double numbers. So that if your default precision is mp.Digits(34), then it will be used for mp('pi'), regardless of what precision x has.

I see, this was helpful, thank you!

Now situation is clear. MATLAB R2022a introduced incompatibility with previous versions of MATLAB. 

The issue is - R2022a chooses wrong function overload. MCT provides custom overload for 'eps' function which accepts only one argument. Two-argument calls must be re-directed to the built-in 'eps'. All previous versions of MATLAB handled this correctly. But starting from R2022a, MATLAB (incorrectly) tries to use one-argument overload for two-argument calls.

Obviously this leads to error "Too many input arguments".

Actually this issue is a bug. Overloads look-up rules are quite clear and strict in the world of OOP, it cannot be changed on a whim. Lots of existing MATLAB code might be broken because of this change.

We will add workaround for this issue to MCT, so that our overload will handle one and two-argument calls.

At the moment, please replace the content of [toolbox_dir]/@char/eps.m with the following code:

function r = eps( varargin )
    if strcmpi('mp',varargin{end}) || strcmpi('mp',class(varargin{end}))
        r = mpimpl(2000);
    else
        r = builtin('eps',varargin{:});
    end
end

Let me know if this fixes the issue.

Please ignore my previous reply because I was wrong and situation is completely different.

I have investigated this in more detail. This error has no relation to toolbox at all. Error happens in 'nthroot' for 'double' arguments.

Looks like you are using 'nthroot' from some old(er) version of MATLAB? Maybe it is somewhere in the search path?

The thing is, Mathworks changed syntax of 'eps' functions since around R2021b (at least this is what I find in my tests).

Two-argument call to 'eps' is not supported anymore.  So that eps('like', y) leads to error.

To fix this error, open your nthroot.m and change the call to 'eps' in line 35 from

eps('like',y)

to

eps(class(y))

Funnily enough,  web documentation still incorrectly shows that eps('like',y) is supported. 

But offline documentation states it is not (already for R2021b) - this is correct. 

By the way, 'eps' in toolbox still supports two-argument calls without any issues.

We didn't ensure compatibility with R2022a yet. 

Looks like now they enforce double quote strings instead of single as arguments.

This will affect a lot of functions - all elementary arrays, etc. Breaking this compatibility is the stupidest thing ever (!).

Do you see any way option to turn on the compatibility with old versions of MATLAB (so that we can still call eps('like') instead of eps("like"))? 

@"Change .txt to .mat in above; i.e"

This changes only the extension in file name (txt to mat), but file is still textual.

That is why Mathematica can read it.

Functions mp.write and mp.read were provided solely for the purpose of transferring toolbox's arrays to other software. This can be efficiently done only in textual format. In txt format we store only 2D slices for maximum compatibility with other programs.

The MATLAB's MAT files are of binary format, it is different beast. Toolbox's multiprecision arrays can be stored in binary MAT-files and loaded by toolbox on different OS - using MATLAB's standard commands, save/load. 

But Mathematica cannot read it (because there is no support for our toolbox there).

Textual format is quite limited and storing multidimensional arrays in one txt file is a pain (especially in transferrable way to other software). So this is not really a bug, this is limits of txt.

The quick workaround is to store 2D slices of multidimensional array in different txt files. And then load and assemble slices back into multidimensional array in Mathematica.

For example, you need to store 4 slices of A: A(:,:,1), A(:,:,2), A(:,:,3), A(:,:,4) and then merge them back after reading from files.

Sorry to hear about miscommunication with "big boys". But I am not surprised at all, as my experience with them was the same. I communicated with several top technical people, they tried to extract deep technical information about toolbox internals (and why it is so much faster), but never provided anything in return.  Later on, I saw they tried to implement some  of toolbox's technical "know-hows", but without much success, as I didn't reveal all the details :).

In any case, thank you very much for your time and efforts. Hopefully we can return to this topic later on.

By the way, you need to compute constants (1/3, 2/3) using extended precision: mp('1/3'), mp('2/3').

Otherwise MATLAB evaluates them using double precision. Of course, this must be pre-calculated once before the loop (same as m).

There is still a room for improvement in your code. 

Naturally, extended precision computations are slower compared to double (double run in hardware, extended precision is emulated in software). 

However, how much "slower" depends entirely on the particular code and how it is implemented.

Another important slow-down comes from the MATLAB overhead. Each operation in the M-code results in data copy and passing it to toolbox. This adds non-negligible overhead.

Thus, for higher speed, you might consider re-writing your code to avoid redundant calculations (e.g. b.^2 computed many times) and to use vectorization (when one operation works with vectors & matrices instead of crunching through scalars in the loop). This will reduce MATLAB overhead and allow toolbox to handle data in parallel. You will see nice speed-up.