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).

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

This is very good question. I am asking it myself everyday.

From one point of view it would make existing code porting to mp much easier at some cases.

However, in the same time, this might cause hard-to find errors of accuracy loss.

For example, MATLAB scripts include many use cases of:

zero(m,n,class(a))

ones(..,class(a))

eps(class(a))

If class(a) return "double" for mp-objects - all the commands will create double objects silently, which is obviously will lead to hard-to-find errors. Especially with "eps".

Perfect way would be to overload the built-ins "zeros, ones, eps, etc." completely, for all arguments (not only mp). And add support for 'mp' class to all these functions. However MATLAB screams on this overloads.

Do you know, or could you suggest on how to overload all the system functions, so that MATLAB will not go crazy with all the warnings?

***

Cast is in my TODO list - thank you for sharing your code!

I will make this thread public, if no objections.

Actually it might indicate few things (in case of ordqz) - problem is too ill-conditioned and transformed matrices might be too far from generalized Schur or just indicate wrong inputs (mismatching matrix dims or else). In any case toolbox will just return 1 in case of extra output parameters.