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.

New version of toolbox is available for Windows: http://goo.gl/pMXV3

It includes fix for the bug.

Thank you very much for the bug report!

It has been fixed in development trunk. Updated toolbox installations will be available soon.

As a quick workaround, please copy file [1] into toolbox_root\private folder.

Thank you!

[1] https://goo.gl/YTFzqY

I replied to your question in different thread: http://mct.userecho.com/forums/1-general/topics/123-new-releases-policy/