I am afraid, that this suggestion is a bit out of scope for MCT. All above mentioned commercial solvers are realized typically at C/C++ and available Matlab toolboxes (all supports only double-precision class) plays only a role of interface between these low-level solvers (implemented as C/C++ MEX files) and Matlab environment.

The only way, in this case, is incorporation of multi-precision computing libraries (like MPIR  C Library for Multiple Precision Integers and Rationals, MPFR C Library for Multiple-Precision Floating-point computations with correct Rounding, MPC C Library for the Arithmetic of Complex numbers with arbitrary high precision, MPFR C++ multi-precision floating point number class, etc.), to these low-level solvers source code, which is definitely not simple task at all.

By my best knowledge of MCT, the only possible way, how to perform multi-precision optimization via MCT is modification of suitable optimization solvers, which are completely implemented at MATLAB to use mp class. But, I am sure (!!!), that for above mentioned commercial solvers are not available any strictly MATLAB coded solvers.

I did not observed this problem with any other matlab algorithms (linear algebra, FFT, statistics, etc.). Degradation of ODE's algorithm is so significant (benchmark problem is only very simple example to show this problem in natura), that  is really not acceptable.

Finally, to avoid this problem, you propose only remove MCT from the path? Am I right?  But this is off/on solution. In a case of active MCT user will be always suffered by significant ODE's slowdown.

I am afraid that you are not right in this case. Please extract from standard matlab function bench.m the following content to the file bench_ode.m

--------------------------bench_ode.m-------------------------------------

function [t, n] = bench_ode
% ODE. van der Pol equation, mu = 1
F = @vanderpol;
y0 = [2; 0];
tspan = [0 eps];
[s,y] = ode45(F,tspan,y0);  %#ok Used  to preallocate s and  y
tspan = [0 450];
n = tspan(end);
tic
[s,y] = ode45(F,tspan,y0); %#ok Results not used -- strictly for timing
t = toc;
end

function dydt = vanderpol(~,y)
%VANDERPOL  Evaluate the van der Pol ODEs for mu = 1
dydt = [y(2); (1-y(1)^2)*y(2)-y(1)];
end

-----------------------------------------------------------------------------------

In a case of MCT on the path:

>> time = bench_ode

time =

0.0775

but in a case without MCT on the path:

>> time = bench_ode

time =

0.0238

MCT has some slowdown impact on ODE's functionality in general ... This is not acceptable behavior of presence MCT on path! So, I think that this behavior is a bug.

This is what is the really strange ... there were no additional processes just MATLAB.

I think we can forget this strange episode ...

OK ... I am happy now :)

Just one observation: during this problem all cores (+ logical threads) were fully used when MCT fft related (fft, ifft, fft2, ifft2) functions was tested by mp.Test. But these functions was terribly slow (~100x slow down).

I have Matlab R2018a + update 2 working well with MTC. After install of R2018a_update3 I have got the above mentioned problem even after restart and Matlab warm up, so the cache should be already build. Then I reinstall all updates 1 + 2 + 3 again over this current Matlab installation and then everything works very well again.

When re-apply all 3 available R2018a updates the situation is again normal ... now significant slow-down. Strange!!!???

Hi Pavel,

I desperately need any multi-precision linprog matlab code, because my optimization problem has a very specific numerical behavior. Now, I have a simple dual-simplex algorithm based code, which works "well".

Could you help me to modify the attached pure Matlab code LinProg.m to the efficient mp-like code?

Thank you and your team for excellent support. Now is MCT again fully compatible with Matlab R2018a.

Pavel ... well done!!!

New pre-release version 4.4.6 Build 12725 (Linux) works well on Matlab releases R2016b, R2017b and R2018a (Ubuntu 16.04 64bit).

Thanks for your quick response and effort!

Michal

P.S. I just solve the same incompatibility problem with TOMLAB toolbox and few other third-party commercial matlab toolboxes :)

﻿