### Twoje komentarze

But cooperation with any commercial optimization solver developers is always very problematic task. My personal experience in this domain is very negative. Any idea how will the final product look like?

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?

Customer support service by UserEcho

I mean Matlab R2019b ... sorry for typo