The eigs produced wrong result / shows error because it didn't handle such small matrices (up to now).

Krylov iteration methods are robust when search subspace is large ( > max(2*evals,20)). That is why eigs must switch to full QR to compute spectrum of matrices smaller than some threshold. This safeguard was not included in the toolbox up to this moment.

I have just added this workaround to the mpeigs.m.  I will send you new mpeigs.m by email in a few minutes. Just copy it to the toolbox directory (overwrite the old file).  Next toolbox versions will include the new mpeigs.m in the bundle.

P.S.

This kind of special cases (small matrices, small K, special structure) - are not indicative of eigs performance on large/real-life matrices. Because all of these are corner cases, which are handled accordingly by separate codes. 

The only way to be confident is to check math. properties of the results, e.g.:

mp.Digits(34);
A = sparse(eye(4,'mp'));
[V,D] = eigs(A);
norm(A*V - V*D,1)/norm(A,1)

Hello, 

Do you save to "mat" file? It is MATLAB's responsibility to save data/matrices to "mat" files (unless you use mp.wrire/mp.read) .

Please provide minimal, complete, and verifiable example, so that situation can be reproduced.

Most likely it is possible. If YALMIP code is precision-independent then porting might be easy. Please try to port the functionality you need to MCT. 

Or maybe you can suggest authors of YALMIP to check/add compatibility with MCT. All they need is to write precision-independent code, e.g.: https://www.advanpix.com/2016/07/21/how-to-write-precision-independent-code-in-matlab/

This will make sure YALMIP can work with any toolbox.

No, there is no progress on this. High-quality solvers are commercial without access to source code (CPLEX, KNITRO, etc.). So this thread was just a discussion of wishful possibilities, not a realistic commitment/promise for development.

Besides, good solver enabled with extended precision capability would take years of efforts to design and implement. In fact, it would be comparable to toolbox itself by amount of work required. So we need some serious investor to come by and fund this work.

We have fixed the issue in EIGS, see https://www.advanpix.com/documentation/version-history/ 

The issue was is that for some badly-structured matrices (like pure diagonals or similar very sparse) our two-step re-orthogonalization of Krylov subspace was not enough. Now we use 5-step process with random restarts as a fall-back. Because of this EIGS has became slower (will improve this in next version), but handling of such matrices is much better now.

You can re-download toolbox using the same links provided in after-purchase email. Version of the toolbox are the same, but it has new EIGS.

Hello Eduardo,

Yes, this is possible, but would require special re-distribution license. 

At the moment, the "eigs" in toolbox is targeted primarily for solving unsymmetric matrices (where ill-conditioning is the most probable). Symmetric/Hermitian matrices require special handling (to keep the symmetry/Hermitian property, etc.) - but this is not implemented yet in toolbox.

This is in our TODO list for "eigs", but it needs some time to be implemented.

Thank you for the report, investigating...

Yes, unfortunately, this is expected behavior, at least for now. MATLAB doesn't allow overloading sparse data types, so we must use workarounds to add our own sparse matrix type. This comes with copy overhead in each operation (even in indexed access).

That is why, for maximum speed, please try to avoid element-wise access operations for sparse matrices (assignment/reading).

For example, when assembling sparse matrix, generate arrays of non-zeros and their indices separately, and then convert them into sparse matrix using command "sparse".

***

Starting from September, we have been working on new ideas on how to reduce copy-overhead further (now we are using undocumented functions in MATLAB, etc.). I hope this will allow us to reduce timings in future versions.