Thank you very much for excellent report(s)!

The second issue (complex(0,mp(pi)*rand(0,1))) has been fixed in our trunk - will be available in a few days.

Corner cases with empty inputs are nightmare - code becomes macaroni type.

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

Toolbox automatically detects if numbers are complex or real. There is no point to push the user to do this manually.

I believe Matlab allows real numbers (without imaginary part) to assign as complex for historical reasons. Probably they needed to pre-allocate planar memory or similar.

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.

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

Thank you very much for correction!

I have added both types of cast to mp class - cast(A,'mp') and cast(A,'like',B).

But I prefer to avoid intermediate conversion to double like this:

try r = eval([newclass,'(A)']);
catch, r = eval([newclass,'(double(A))']); end    %<-----

Also I added test matrices - hilb, invhilb, hadamard, pascal, magic, rosser, wilkinson. Now all of them can create mp-matrices with last parameter classname='mp':

>> magic(3,'mp')

Would greatly appreciate if you would test the new version. Let me know if you find anything strange

Guaranteed bit-to-bit matching has been added to generalized eigen-solver as of 3.9.4.10458 version, hence I am closing the ticket.

The cplxpair fails because it has hard-coded checks allowing only 'double'/'single' inputs.

I have changed the cplxpair to accept the mp-parameters as well. Will send it by email in a few sec.

I am not sure if EIG should return perfect conjugate pairs to last digits though, but it returns them grouped:

>> mp.Digits(34);
>> test_ee
ee = 
        0.9851486373638723693809204675873853 +                                       0i    
          99.9999998743453462896070441576835 +       100.00000000000015525899193951503i    
         99.99999987434534628960704415768347 -     100.0000000000001552589919395150301i    
         199.9999999999999523395305332254016 +                                       0i
ans = 
          99.9999998743453462896070441576835 -     100.00000000000015525899193951503i    
          99.9999998743453462896070441576835 +     100.00000000000015525899193951503i    
        0.9851486373638723693809204675873853 +                                     0i    
         199.9999999999999523395305332254016 +                                     0i

Second output is from modified cplxpair - it just finds and truncates pairs by tolerance (100*eps be default).

As it turned out, MATLAB allows overloading zeros, ones, etc. in recent versions :).

http://www.mathworks.com/help/matlab/matlab_oop/class-support-for-array-creation-functions.html

This changes everything.

Yes, I know about @double directory and placing all overloads there. But is it reliable?

@"By the way, on what grounds 'mp' inherits not 'double' ?"

Would it be more useful? Could you please show code example which can benefit from this?

Now mp-numbers have 'mp' class, different from 'double'.

Thanks to this difference, now it is easy to detect cases like zeros(m,n,class(a)). When a have 'mp' type - MATLAB screams with error, and we can fix this code.

If mp-objects would have 'double' class - MATLAB would create array of zeros in 'double' precision.

To overcome this, we would need to provide overloads for built-in functions - zeros, ones.

Which will return 'mp'-objects even for plain integer parameters. E.g zeros(10) will return 'mp'-matrix.

I don't know reliable way of such global overloading built-ins, ones, zeros, eps, etc.

Do you know?

Undocumented syntax has been implemented for both routines, ordqz and ordschur (in trunk).