Teie kommentaarid

1. The usual commands save/load works with "mp" variables:

A = mp(rand(100));
B = A;

save('A.mat','A')
clear A;

load('A.mat','A');
norm(A-B,1)
ans =     
     0

Use them if you intend to load/save matrices on the same computer using the same version of MATLAB/toolbox.


2. If you want to transfer mp-matrices from one computer to another, it is better to convert it to text.

Toolbox provides two special commands for file I/O with preserving accuracy and cross-platforms compatibility:


mp.Digits(34);
A = mp(rand(25));

mp.write(A,'matrix.txt');  % Write mp-matrix to the text file
B = mp.read('matrix.txt'); % Read it back

norm(A-B,1) % check accuracy - difference should be 0
0

Linearize n-diminsional array before saving: mp.write(A(:),'matrix.txt')

New version of toolbox (with sortrows) has been released for Windows. Please download it from here:

http://www.advanpix.com/wp-content/plugins/download-monitor/download.php?id=1

Yes, I meant next version of toolbox for Windows, Linux and Mac OSX.

We support all three platforms and new versions of toolbox are released for Windows first.


It will be released in Windows version first, then in Linux & MacOSX.

The 'sortrows' in MATLAB is hard-coded to double type, as it calls the internal MEX module which accepts only double inputs.


Please do the following changes to fix this:


1. Open sortrows.m in editor:

>> open sortrows

2. Find & change the line:

if isreal(x) && ~issparse(x) && n > 3

to


if false && isreal(x) && ~issparse(x) && n > 3

This disables call to internal MEX, switching to pure m-language implementation which is able to work with mp-matrices.


After the fix, 'sortrows' will start working for multiprecision objects:

>> A = mp(floor(gallery('uniformdata',[6 7],0)*100));
>> A(1:4,1) = 95;  A(5:6,1) = 76;  A(2:4,2) = 7;  A(3,3) = 73;
>> D = sortrows(A,[1 7])
D =
         76        79        91         0        19        41         1
         76        61        93        81        27        46        83
         95         7        73         5        19        44        20
         95         7        73        89        20        74        52
         95         7        40        35        60        93        67
         95        45        92        41        13         1        84

I will include proper implementation of 'sortrows' into next version of toolbox (will be released in few days)

The 'subs' is part of Symbolic Math Toolbox and it requires input to be of 'sym' type.

To use it with multiprecision toolbox, please use explicit conversion function: mp2sym.


So that the code becomes:

digits(mp.Digits()); % make sure we use the same precision for 'sym' as in multiprecision toolbox.

....

t=subs(T,{'A','B','C'},{mp2sym(a),mp2sym(b),mp2sym(c)})

Reverse conversion can be done with sym2mp function.


Let me know if this fixes the issue.

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.