Simple switching to using hardware "double" instructions is impossible. MATLAB, Intel, etc. have been working on implementing "double" precision math functions for decades. To make it efficient, fast, with small memory footprint, to utilize CPU cores, etc. etc. This is enormous work, very difficult to replicate.

We are focusing on doing the same for arbitrary precision computations - to make them as fast as possible on modern CPU. This requires a lot of efforts from deriving new algorithms capable of doing extended precision to low-level software optimizations. The algorithms and code are inherently created for arbitrary precision. No simple switching to "double" is possible. We have been working on this for more than 10 years with long todo list for the next 10 years :)

No special hardware instructions exist for quadruple precision. It is all emulated in software using 64-bit integer CPU instructions. We created it exactly because quadruple is not implemented in hardware.

Double precision is already implemented in hardware, and its functionality has been polished very well. So that, for adequate comparison it is better to use existing "double" precision libraries, provided in MATLAB, MKL, etc.

It is possible to write precision-independent code, so that it can run with "double" or "mp" scalars. Please check the page for more details: https://www.advanpix.com/2016/07/21/how-to-write-precision-independent-code-in-matlab/

The mp.Digits(16) is not equivalent to "double" since we are using wider exponent range and our arithmetic/basic math. functions are done with guaranteed accuracy. In other words, mp.Digits(16) is delivering more accurate results compared to native "double".

I agree, the extended precision must be applied carefully, to the parts where ill-conditioning is observed (cancellation, accumulating rounding errors, etc.). Or to verify the results and study asymptotic properties of the algorithms. 

Hello Michal,

Good timing! We have just finished all the features we planned for major release, please download 4.9.2.

It includes all the optimization work for (full) matrix computations we have been working on lately.

In this regard the 4.9.1 was transitional with partial results integrated (basic matrix operations only).

Please use the 4.9.2.

Jon,

Thank you very much for the excellent question.

The main overhead in such loops are indexed access to the elements of array.
MATLAB makes this operation slow for third-party toolboxes. In short, it requires the toolbox to make a copy of the whole array, even if only one element is requested (MEX API restrictions).

That is why we always suggest vectorizing code as much as possible (avoid loops and process data as a whole).
However application of IIR filter cannot be easily vectorized. We have been planning to add it to the toolbox core with all possible optimizations for a long time. Your request motivated us to prioritize this. Thanks!

Please download a new version of the toolbox (4.9.0.14753) from our website. Among other changes it includes the function 'filter' which implements IIR filter.
Thus your example becomes:

tic
r1 = filter([0], [1 -cosom], y1, [y1(1)]);
r2 = filter([0], [1 -cosom], y2, [y2(1)]);
toc

However, if you need to apply same filter on several arrays simultaneously, we would suggest to process them altogether:

y = [y1 y2];
tic
r = filter([0], [1 -cosom], y, [y1(1) y2(1)]);
toc

This will allow the toolbox process each array (column) in parallel, using different CPU cores.

@"The fft() respects input precision of the arguments."
All functions provided in toolbox respect precision of the input arguments.

However, user-written functions might behave differently - this is responsibility of the user who writes the code. See my previous reply for the cases when precision might be different inside user-written function (e.g. when mix of different precisions is used).

Could you please provide minimal, complete, and verifiable example of the improper behavior of the toolbox?

This would help a lot.

Edit:

@"This leads to an expectation of consistency; i.e, a subroutine (user-written or otherwise) should always be executed in precision of the arguments."

All functions in toolbox provide this consistency. But toolbox has no control of user-written code. All user's M-code is executed by MATLAB interpreter by following the object programming rules (it calls functions from toolbox when it encounters mp-variables). We cannot change this and force the MATLAB interpreter to behave differently.

In order to have this consistency in user-written functions, please use the same working precision everywhere. This is the only simple rule.

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"))?