Twoje komentarze
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 :)
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.
Customer support service by UserEcho
This is what is the really strange ... there were no additional processes just MATLAB.
I think we can forget this strange episode ...