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. 

Hi Pavel, you are right.

I just testing all my MEX files. TMW changed the MEX API so massively, that significant number of third-party MEX files I use (~20% in my case)  does not work with R2018a. This is terrible situation for all third-party matlab toolbox users!!!

I am a bit disappointed, how quietly is TMW  able to change the MEX API, without any warning to all third-party toolbox developers.