New pre-release version of toolbox for GNU Linux is available for download.

Could you please download and test it with R2018a and older MATLAB(s) you have?

Thank you in advance, this would help us a lot.

Hi Michal,

Well, pre-release version of 2018a didn't have the issues. 

TMW introduced the changes only in the final release without any heads-up for toolbox developers (as they always do).

As for technical side - first of all, thank you for reading our blog :).

Changes in undocumented functions is just tip of the iceberg. In fact, fix is quite trivial for this issue alone.

TMW has also changed: (a) compilers they use for MATLAB, (b) the way they re-destribute CRT, (c) the way they re-distribute Windows API (on Windows they moved to universal CRT, which is compatible only with MSVC2015). These are what I referred to as "massive" changes/incompatibility.

We are working on making toolbox compatible with all these, without loss in speed.

But, still, this is also only part of the equation - unlike to TMW we must be backward compatible with previous versions of MATLAB. Almost every version of MATLAB has its own glitches in MEX interface and now we are including extra workarounds for R2018a.

In any case, updated version of toolbox for Windows is already available for download (was released in the morning).

GNU Linux & MacOSX versions will follow very shortly, if no new surprises will be found.  

Hi Michal,

R2018a has introduced massive changes in MEX API. 

(MEX API defines how third-party toolboxes interact with MATLAB's kernel. TMW has changed the API without any thought of backward compatibility and existing third-party toolboxes.)

We are investigating the situation in search for reliable workarounds. I hope to release update soon.

Please use R2017b for the moment.

Dear Michael,

Thank you for your question.

I use different approaches to compute H1 and H2 functions - with the purpose to handle various cases, argument combinations, etc. Overall code is quite convoluted and it clearly can be simplified. This is in my long to-do list for Bessels.

At the moment, as a quick workaround, you can replace besselh in mp.m to rely on J+/-i*Y formulas (value2). Switching to these formulas needs further test of accuracy loss, but they showed good results when I tested them last time - I think it is safe.

But, please note, the K-formula (value3) is valid only for the part of complex plane, as far as I recall.

No way, we dropped support for 32-bit systems years ago (as TheMathWorks did).

Btw, fixed version for Windows is already available (please download it using big green button on our webpage).

Hello Michael, 

Please convert mp-values into doubles for use with graphic-related routines (e.g. double(X), double(Y)).

All of such routines are hard-coded to doubles and distributed as compiled code. Which, in fact, has solid reason. 

Resolution of physical devices (displays, printers, etc.) is not capable to cover even single-precision floating-point resolution.

So it has sense to fallback to double type for display (unless your numbers go beyond min/max limits of double type - which is very rare).

Let me know if this is acceptable solution for your situation.

Pavel.

Dear Michael,

Thank you for reporting this (nasty) bug!

It has been fixed in trunk - fix will be included in next updates for all platforms.

Please use M-language workaround until then (e.g. use imag(x)==0 in isreal routine in mp.m).

Thank you!

You are absolutely right - this is non-trivial task to do.

However, please let me know what parts of toolbox you find trivial to implement :)?

Full re-implementation of MATLAB's core for matrix computations in arbitrary precision? Or n-dim arrays, sparse matrices, special functions or FFT?  With all optimizations and parallelism in native language....

The main issue is not the implementation difficulty itself, but restrictions and overhead imposed by MATLAB for third-party plugins. For example, MATLAB simply crashes when we call M-function (with nested calls to other M-language functions) from within MEX. This basically prevents direct and efficient implementation of optimization methods in native language (we use C++). Special workarounds are needed - like in ARPACK, or similar.

After quick evaluation - I think it is impossible at the moment.

The linprog uses a lot of compiled p-code functions, hard-coded to double precision only.

See for example this directory: [matlab root]/toolbox/optim/+optim/+algorithm/ 

It contains all main solvers, and all of them are stored as unmodifiable p-code.

Optimization routines are of high demand and we consider to add more homegrown functionality in this area.

The only issue is that it takes really long time to develop full-featured solver(s), test them and maintain. Basically we must re-write optimization toolbox from scratch without having its source code.