Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Update LAPACK/LAPACKE to Reference-LAPACK 3.10.1 #3609

Merged
merged 12 commits into from
Aug 6, 2022
Merged

Update LAPACK/LAPACKE to Reference-LAPACK 3.10.1 #3609

merged 12 commits into from
Aug 6, 2022

Conversation

martin-frbg
Copy link
Collaborator

fixes #3495 and fixes #2154

@h-vetinari
Copy link
Contributor

Hey @martin-frbg, do you think it would make sense to include this PR in 0.3.21?

@martin-frbg
Copy link
Collaborator Author

I remember seeing a handful of new failures in the LAPACK testsuite with this, which is why it is not merged yet. Seems some of the new algorithms are a lot more sensitive to numerical accuracy of the underlying BLAS than before.

@martin-frbg
Copy link
Collaborator Author

martin-frbg commented Jul 4, 2022

Current state on Haswell for reference (used to be just 1 each in REAL/COMPLEX due to ?TFSM) - additional errors are in SGS/CGV/ZGV (with significant error values, in the 1.e6 and 1.e16 range). ARMV8 is clean but with a low test count.

                        -->   LAPACK TESTING SUMMARY  <--
SUMMARY                 nb test run     numerical error         other error  
================        ===========     =================       ================  
REAL                    1308531         2       (0.000%)        1       (0.000%)
DOUBLE PRECISION        1318689         0       (0.000%)        0       (0.000%)
COMPLEX                 768751          5       (0.001%)        0       (0.000%)
COMPLEX16               776246          21      (0.003%)        0       (0.000%)

--> ALL PRECISIONS      4172217         28      (0.001%)        1       (0.000%)

@brada4
Copy link
Contributor

brada4 commented Jul 6, 2022

Well FMA and parallel accumulators almost guarantee different result. I suppose those tests impose exact result.

@martin-frbg
Copy link
Collaborator Author

Tests are not meant to impose exact results - in fact the input files define thresholds and the netlib faq explains that even further deviations in about the same order of magnitude can be expected to arise from harmless numerical differences. I guess there is a risk that more involved calculations, e.g. iterative ones, may be derailed to give a perturbed result. In any case, errors of 1e+16 will warrant a closer look.

@brada4
Copy link
Contributor

brada4 commented Jul 6, 2022

It is to look at each test individually why rounding particularities do not cancel out correctly.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Update LAPACK to 3.10 Hidden ABI problems in calls from C to FORTRAN
3 participants