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/

Dear Michal,

Thank you for keeping your eye on toolbox development (and sorry for delay in reply).

Our main development platform is Windows meaning that hotfixes and new features usually appear on Windows first.

Usually updated GNU Linux & MacOSX versions follow the Windows release timely (within several days to 1-2 weeks at max).

Situation is different with the current release - 4.4.5.12698, since we also want to try new workaround for famous MATLAB issue on GNU Linux, see [1]. This needs full re-built of GCC (we maintain our version to make it usable) and all related code. This causing delay in releasing new toolbox for Linux.

References.

[1] https://www.advanpix.com/2016/02/22/matlab-error-cannot-load-any-more-object-with-static-tls/