Let me summarize the reasoning.

If you treat the calculations reliability in complex numbers as a whim of mine, you're wrong. Ask any other user Matlab (including Advanpix Toolbox) from the control systems, process simulation, energy transport, communications radio plus an infinite number of other high-tech fields if they need reliable computing withcomplex numbers.

Fact 1.

Storing real numbers as complex with zero imaginary part has no any influence on mathematical functionality of MATLAB itself:

>> A = complex(magic(3),0)
A =
            8 +          0i            1 +          0i            6 +          0i
            3 +          0i            5 +          0i            7 +          0i
            4 +          0i            9 +          0i            2 +          0i
>> lu(A)
ans =
            8            1            6
          0.5          8.5           -1
        0.375      0.54412       5.2941
>> sqrt(A)
ans =
       2.8284            1       2.4495
       1.7321       2.2361       2.6458
            2            3       1.4142

As you see, zero-imaginary part is not carried around. So that MATLAB itself doesn't support rigorous handling of complex numbers. This is very justified strategy, any mathematical software follows it. Toolbox follows this as well. Automatically detect where switching to complex is needed (sqrt(-1), eig, etc.), otherwise rely on reals for speed.

Fact 2.

The MATLAB doesn't support signed zeros - this is the only case where storing reals as complex numbers would have mathematical sense (to work with branch cuts, etc.)

Conclusion.

This feature was designed to optimize storage format, so that you can pre-allocate complex array before computations to avoid reallocations:

x = zeros(n)            % <-- preallocate real array
z = complex(zeros(n))   % <-- preallocate complex array

The only function which is affected by this functionality is isreal.

As follows from the above - isreal is designed to just check the storage format of a number.

Fact 3.

All these attempts to optimize storage format, pre-allocation, etc. for doubles - has very little sense for multi-precision numbers/arrays.

It is long story why - but in short it is because MATLAB doesn't allow creating objects of custom type and keeping them inside MEX, storing just pointers to the objects as property field.

As a result object data have to be moved MEX<-->MATLAB on every operation. In this case pre-allocation hurts a lot - actually it is better to keep size of the objects small (grow as needed) to minimize memory to be transferred.

Toolbox design.

- All complex-related functionality in toolbox is done exactly as in MATLAB, with the exception of isreal.

- We use different storage format, and we can use isreal for more meaningful purpose.

Now it checks if input has zero imaginary part. In fact it generates exactly the same output as original isreal in ALL cases, except when real is stored as complex - which is ignored by mathematical functions in MATLAB anyway, as you see above.

Critics.

In all years of translating MATLAB codes to multiprecision I haven't encountered the case where toolbox version of 'isreal' affected functionality. But there is always a possibility of mistake.

Therefore I would greatly appreciate if you would show computational code where this meaning of 'isreal' might be harmful.

Of course I meant the software, including programming languages and systems like MATLAB, Maple and similar.

You are absolutely right.

I changed semantic of 'isreal' on purpose, with the idea to improve MATLAB.

Now 'isreal' checks if array is pure real (imag(x)==0), independently of how it was created.

Back then I saw no serious consequences for this change. Probably I need to re-think this.

This is true for pure theoretical & rigorous world. But for computations, there are a lot of cases when algorithms change numbers from real to complex automatically. All matrix functions detect if input is pure real (even if it is stored as complex) to use real-tailored algorithms since they are way faster. Same for routines which might generate complex outputs, e.g. sqrt(-1), eig, etc.

The system which rigorously treats reals as subset of complex numbers just doesn't exist in practice (I think). Instead complex-rules are applied only where necessary, depending of situation. I tried to investigate this in short notes here: http://www.advanpix.com/2015/10/19/devnotes-1-multiplicative-operations-with-complex-infinity

I promise that I will implement this storage format as soon as I see its importance in some application :).

(The only important case I see is complex infinities, but again MATLAB converts real to complex automatically in this case - so should do the toolbox)

Also whole family of subs*** methods should be changed, and others. Plus overhead of detecting the pure reals before every operation (one pass over array) and many other complications.

Anyway it is doable of course, but the question is do we need this at all :).

Thank you very much for your insights!

Toolbox does follow MATLAB syntax and semantic to the maximum possible extent.

Along the way I add/remove some features (which do not harm the whole idea).

I thought about this particular feature of having real number as complex - I couldn't come up with any mathematical code which can benefit from this. Why it is needed?

I would understand if MATLAB would allow +/- zeros - then this feature would be vital for branch cuts, etc.

But now,when there is only one zero - this feature is pointless from computational point of view.

Could you please educate me with some computational/math code where this might be important?

I haven't seen one so far (possibly working with complex infinities?)

Other math systems have no such feature as well (as far as I know). Usually complexity of numbers are automatically detected and treated as such.

I would greatly appreciate example of real-life code where storage format of a real number is important.

In reality, complex(12) setups the storage format of a number, not the semantic - since it is treated as real number in all mathematical operations anyway. Thus I concluded it was related to legacy storage format in MATLAB.

Please teach me where my reasoning is wrong.

This happens because you added the line to double():

if ~(mp.OverrideDoubleBasicArrays && ismp(x))

Now ip = triperm('H',double(a)) in MSCALE doesn't work since double() produces mp-numbers anyway.

This is related to your another ticket: https://mct.userecho.com/topics/50-overridedoublebasicarrays-option-and-double-method/

@"On the other hand, in "classic" Matlab, no one uses the builtin function "double" with explicit intentionality to reduce the precision for data"

This is very true. However, in case of multiprecision, user needs double() for reducing precision in many cases.

For example, for plotting, or for passing mp-arrays to internal MATLAB's MEX modules (as we did for ip = triperm('H',double(a));)

My idea is to overload all implicit floating-point functionality.

But, user should have possibility to switch to double, by using explicit conversion function.