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?

LinProg.m

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 :)

Great!

Thank you very much for quick response ...!!!

Hi Pavel,

during last days I tried to clarify the above mentioned problem with "incompatibility" of your mex file on Matlab R2018a.

If I understand well information available here: https://www.advanpix.com/2013/07/19/undocumented-mex-api

you are using exactly this kind of undocumented functions and recent "incompatibilty" problem with R2018a could be caused by any change in these undocumented functions by TMW. Am I right?

In this case, is very important your statement:

"Please note that there is a risk in using the functions – MathWorks can

change / remove some of them in next versions. It is additional burden
for developer to stay tuned and update their toolboxes on time."

And moreover, undocumented function mxGetPropertyShared is called via C++ API (not via C API which is already exist for this function, but again as undocumented). This is already two serious reasons for potential problems! Direct calling via C interface is definitely more stable in every cases and scenarios.

I fully understand your main reason to choose these undocumented functions to get speed-efficient code. But on the other hand, you should definitely provide more thorough testing with latest Matlab version compatibility.