Add tests for ?pteqr, #11224

[swallan]

Reference issue

Adds tests to lapack's ?pteqr wrapper: scipy#11224

What does this implement/fix?

Additional information

@mdhaber

[swallan]

Two small issues:

• incorrect shape of z does not raise ValueError, instead prints ** On entry to SPTEQR, parameter number 6 had an illegal value. Is this expected behaviour?
• the test from the NAG manual has a few z eigenvectors that are positive instead of negative and vice versa. The d eigenvalues are correct. I checked, and the inputs' signs are the same in the manual and in the test. Are there additional steps that I should do in the NAG test that would change the results?

Other than that, good, randomly generated tests pass.

Should I break this one up as well? The setup for this test making the inputs is what takes up the most of the test.

[mdhaber]

the test from the NAG manual has a few z eigenvectors that are positive instead of negative and vice versa.

Generally, the only important thing about an eigenvector is a direction; the magnitude doesn't really matter. Here, we want to make sure they are all unit magnitude, but then there is still a choice of sign, so I wouldn't worry about it.

[mdhaber]

the test from the NAG manual has a few z eigenvectors that are positive instead of negative and vice versa.

Generally, the only important thing about an eigenvector is a direction; the magnitude doesn't really matter. Here, we want to make sure they are all unit magnitude, but then there is still a choice of sign, so I wouldn't worry about it.

I'll let @Kai-Striega answer the rest.

[Kai-Striega]

The error for z with incorrect shapes is not correct - I'll fix it when I get back from work today. (Edit: This is wrong, see the below comment) And yes, I think that the test will be better of split.

…

On Wed., 26 Feb. 2020, 00:08 Matt Haberland, ***@***.***> wrote: the test from the NAG manual has a few z eigenvectors that are positive instead of negative and vice versa. Generally, the only important thing about an eigenvector is a direction; the magnitude doesn't really matter. Here, we want to make sure they are all unit magnitude, but then there is still a choice of sign, so I wouldn't worry about it. I'll let @Kai-Striega <https://github.com/Kai-Striega> answer the rest. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#5?email_source=notifications&email_token=AHFOJNJUXJZL4IOZGIUSUMLREU7BTA5CNFSM4K3BIKZKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEM4RXUQ#issuecomment-590945234>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AHFOJNPLQUNOH5XJEGFESTTREU7BTANCNFSM4K3BIKZA> .

[Kai-Striega]

@swallan the behaviour with z is correct, but a little more complicated than I had thought. For compz=N it should (and does) pass. For compz of V or I it should return with an exit code (info) of -6. This can be seen by looking at the checks near line 204:

ELSE IF( ( ldz.LT.1 ) .OR. ( icompz.GT.0 .AND. ldz.LT.max( 1,
$         n ) ) ) THEN
info = -6
END IF
IF( info.NE.0 ) THEN
CALL xerbla( 'ZPTEQR', -info )
RETURN
END IF

However, the "correct" behaviour can lead to segfaults when reading the z matrix. So I'm inclined to write a check in spite of the default behaviour. @mdhaber do you have any thoughts on this?

Also while looking at your tests it looks like there is another error. This just looks like a very small tolerance error:

=================================== FAILURES ===================================
_______________________ test_pteqr[V-complex128-float64] _______________________
[gw3] linux -- Python 3.7.5 /mnt/c/Users/Kai/develop/venv-wsl/scipy37/bin/python
scipy/linalg/tests/test_lapack.py:1839: in test_pteqr
    rtol=rtol, atol=atol)
E   AssertionError: 
E   Not equal to tolerance rtol=5.55112e-14, atol=2.22045e-14
E   
E   Mismatched elements: 2 / 100 (2%)
E   Max absolute difference: 2.49922314e-14
E   Max relative difference: 2.39808173e-14
E    x: array([[ 1.000000e+00+0.000000e+00j, -4.996004e-16-1.631291e-15j,
E            4.215378e-16-7.799317e-15j, -9.575674e-16+8.264223e-15j,
E           -1.006140e-15-7.299716e-15j,  1.249001e-15-3.771289e-15j,...
E    y: array([[1., 0., 0., 0., 0., 0., 0., 0., 0., 0.],
E          [0., 1., 0., 0., 0., 0., 0., 0., 0., 0.],
E          [0., 0., 1., 0., 0., 0., 0., 0., 0., 0.],...
________________________ test_pteqr[V-float64-float64] _________________________
[gw1] linux -- Python 3.7.5 /mnt/c/Users/Kai/develop/venv-wsl/scipy37/bin/python
scipy/linalg/tests/test_lapack.py:1839: in test_pteqr
    rtol=rtol, atol=atol)
E   AssertionError: 
E   Not equal to tolerance rtol=5.55112e-14, atol=2.22045e-14
E   
E   Mismatched elements: 20 / 100 (20%)
E   Max absolute difference: 5.59005217e-14
E   Max relative difference: 2.80886425e-14
E    x: array([[ 1.000000e+00, -2.258285e-14,  9.830301e-15, -1.450336e-14,
E            7.119861e-15, -1.386724e-14,  8.246308e-16, -5.143612e-15,
E           -2.495473e-15,  3.792739e-14],...
E    y: array([[1., 0., 0., 0., 0., 0., 0., 0., 0., 0.],
E          [0., 1., 0., 0., 0., 0., 0., 0., 0., 0.],
E          [0., 0., 1., 0., 0., 0., 0., 0., 0., 0.],...

[swallan]

@Kai-Striega I will loosen the tolerance a little bit! I don't get those issues on my my system, but I'll bump it from e-14 to e-13.

[mdhaber]

So I'm inclined to write a check in spite of the default behaviour.

Yes, I think it's best to catch it early! We don't want the possibility of a segfault if we can avoid it.

[mdhaber]

@swallan it doesn't look like you changed the tolerances. Otherwise, how's this looking @Kai-Striega? If you're able to make the tolerance change yourself, are they passing tests?

[mdhaber]

See scipy#11665