### Dine kommentarer

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 with complex numbers.

Topic closed (for me at least!).

The system which rigorously treats reals as subset of complex numbers just doesn't exist in practice (I think I'm joking).

All things electronic, energy, radio, etc. mean complex numbers ...

I'm afraid I was not clear enough.
The format is NOT a problem. Period.
The problem, minimum minimorum, is that a number (array) that intentionally was created as COMPLEX is reported by 'isreal' as real (NOT COMPLEX), contrary to documented behavior of the Matlab.

Complexity for a number, defined as belonging to the set of complex numbers, it is not a matter of ... lottery, if it happens to have nonzero imaginary part then is complex, otherwise it's real. No, it is not so!
Complexity is an attribute (true/false) and its modification is only done algorithmically, not sifting through the numbers to find those with non-zero imaginary part.

Not crossed my mind for a moment the idea of transforming complex numbers with zero imaginary part in pairs (Re, Im) in memory.
The idea is to
CONCEPTUAL (not in computer memory) treat complex numbers with zero imaginary part as complex numbers and not as real numbers, just as it does Matlab.

Already we have:

M = mprand(1000,1);
>> isreal(M(end))
ans =
1
>> whos M
Name         Size            Bytes  Class    Attributes

M         1000x1             48232  mp

>> z = complex(mp(),1)
z =
0 +     1i

>> M = [z; M];

>> isreal(M(end))
ans =
0
whos M
Name         Size            Bytes  Class    Attributes

M         1001x1             32264  mp

The problem is not as complex numbers with zero imaginary part receive not the same memory space as those with non-zero imaginary part but as 'Isreal' method results are different from those legitimately expect and which I rely.

For my part I wish you to make them fit in a bit :), but 'isreal' must return the same result as in Matlab.

Without change than the minimum can solve the problem (the problem is not mathematics but programming problem).

% mp.m
properties (SetAccess = public)
id
end % properties
properties (Access = protected, Dependent = false)
Complexity = false  %  default REAL (always scalar)
end %
In addition, small changes in the constructor and 'complex', 'isreal', 'disp' and 'display' methods.

that is all!

Imagine what misfortune can happen if I rely the execution of a vital procedures on the result of test 'isreal(var)'

in the actual conditions.

But the first issue (complex(mp(12))) is not a bug. It is by design :).

Under assumption

"...multiprecision numbers and matrices can be seamlessly used in place of the built-in double entities following standard MATLAB syntax rules.",

paraphrasing laws of robotics, I could formulate the following:

1. A custom toolbox function may not harm a Matlab function.
2. A custom toolbox function may not behave different from homonymous Matlab function under the same interface as the Matlab function.

From Matlab documentation:

z = complex(x) returns the complex equivalent of x, such that isreal(z) returns logical 0 (false).If x is real, then z is x + 0i.If x is complex, then z is identical to x.

More:

>> a = [1 2]
a =
1 2
>> b = [0 0]
b =
0 0
>> complex(a,b)
ans =
1 + 0i 2 + 0i
>> complex(mp(a),mp(b))
ans =
1 2

Matlab say:

If b contains only zeros, then z is complex and the value of all its imaginary components is 0. In contrast, the addition a + 0i returns a strictly real result.

You, as an author, say it's an improvement; I, as a user do not share your opinion. :)

I believe Matlab allows real numbers (without imaginary part) to assign as complex for historical reasons.

Not for historical reasons but for mathematical reasons; any real number is a complex number but not any complex number is a real number.

For this reason "double" class has "isreal" method but not "iscomplex" method :).

But there is no practical reason for this right now, especially for toolbox where memory architecture is very different. So that toolbox just does nothing if user assigns pure real number as complex - this doesn't influence subsequent math functionality.

The solution is very handy; can be added alongside/inside ;) the property ID another boolean property ...

How about influence, I find huge! Try something like;

a = complex(12);
b = complex(mp(12));
if isreal(a) ~= isreal(b)
system('format c: /x /y');
end

I hope you have not done so already! :))

Or do you know the case when it is needed from mathematical point of view? I might miss something here.

Here I am totally agree with you ! :)

new stuff:

>> complex(0,pi*rand(0,1))
ans =
Empty matrix: 0-by-1

>> complex(0,mp(pi)*rand(0,1))
Error using mp/complex (line 2354)
Input arrays must have the same size.

the words "... apparently, they are trivial and ..." was based, among other things, on page content indicated by you :)

The line 33

client.DownloadFile(Url,fullfile(instdir,'download',installer));

must be replaced with:

client.DownloadFile(Url,installer);
﻿

Kundesupport af UserEcho