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

Add Anderson's tests of NRM2 #925

Merged
merged 1 commit into from
Nov 12, 2023
Merged

Conversation

angsch
Copy link
Collaborator

@angsch angsch commented Nov 2, 2023

The existing tests of NRM2 cover only the branch where squaring does not require scaling. This commit adds Edward Anderson's tests in slightly modified form. His tests include arrays with extreme numbers such that the branches that require scaling are tested. The pass/fail threshold is the same as in Anderson's tests.

The original tests are included in the archive provided alongside with

Anderson E. (2017)
Algorithm 978: Safe Scaling in the Level 1 BLAS
ACM Trans Math Softw 44:1--28
https://doi.org/10.1145/3061665

This commit modifies the tests such that they could be integrated into the existing BLAS-1 tests. It hardcodes the constants rather than computing them at compile time because some of the required intrinsics are not included in f2c. The original idea was to make it easy for dependent projects to integrate the tests, either in this form or in C. However, I could not find a way to include Inf and NaN tests without breaking f2c, more below.

In the current form, test coverage improves as follows.

[D,S]NRM2 [DZ,SC]NRM2
lines 59.1% -> 100.0% 67.0% -> 100.0%
branches 30.0% -> 90.0% 41.7% -> 91.7%

Limitations:

  • The case incx = 0 is included in Anderson's original test, but is not included in this commit. Adding non-positive incx to the loop over incx introduces compiler errors (computed indices in arrays < 1) in the existing tests. I have not looked into this.
  • This commit breaks f2c because of the handling of Inf and NaN. It uses the workaround proposed by Anderson to avoid the compiler from complaining about overflow and division by zero when Inf and NaN are (intentionally) generated. HUGE is a function that is not permitted in f2c. If the tests of Inf and NaN are removed, f2c works.

Since Inf and NaN are covered by the TLAPACK tests, I would be happy to remove these two tests and keep the xBLAT1 tests f2cable. Further, is there any opinion about testing incx = 0? It could of course be added as a special case only for NRM2.

Copy link

codecov bot commented Nov 2, 2023

Codecov Report

Attention: 176 lines in your changes are missing coverage. Please review.

Comparison is base (7a29cfe) 0.00% compared to head (1c1de69) 0.00%.
Report is 32 commits behind head on master.

❗ Current head 1c1de69 differs from pull request most recent head 26df4b3. Consider uploading reports for the commit 26df4b3 to get more accurate results

Additional details and impacted files
@@           Coverage Diff            @@
##           master     #925    +/-   ##
========================================
  Coverage    0.00%    0.00%            
========================================
  Files        1918     1918            
  Lines      188645   188757   +112     
========================================
- Misses     188645   188757   +112     
Files Coverage Δ
SRC/cgedmd.f90 0.00% <ø> (ø)
SRC/cgedmdq.f90 0.00% <ø> (ø)
SRC/dgedmdq.f90 0.00% <ø> (ø)
SRC/sgedmdq.f90 0.00% <ø> (ø)
SRC/zgedmdq.f90 0.00% <ø> (ø)
SRC/clarfgp.f 0.00% <0.00%> (ø)
SRC/dlarfgp.f 0.00% <0.00%> (ø)
SRC/slarfgp.f 0.00% <0.00%> (ø)
SRC/zlarfgp.f 0.00% <0.00%> (ø)
SRC/dgedmd.f90 0.00% <0.00%> (ø)
... and 16 more

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

@langou
Copy link
Contributor

langou commented Nov 2, 2023

Thanks @angsch. This is great and very impressive. Great to check a larger range of input. Impressive to improve test coverage from 41.7% to 91.7%.

I do not have a strong opinion on either (a) compatibility with F2C and (b) testing INCX = 0.

(a) WRT F2C, on the one hand, it bothers me to maintain compatibility with a software (F2C) that, I think, is not maintained anymore. On the other hand, we do not have to purposely go out of our ways to break compatibility. And it is true that testBLAS tests for NaNs and Infs. I'd rather be self-content (and break F2C), but we do not have to do this now.

Note: One reason some NaNs and Infs checks were moved to testBLAS (as opposed to the BLAS test suite) was that the behavior for some BLAS subroutine was not defined in the presence of Infs and Nans, and so we were leery to move this to the BLAS test suite. But it feels like for NRM2, the expected behavior with NaNs and Infs is clear. (There were other reasons for testBLAS, namely, for example, a more modern test suite.)

(b) WRT INCX = 0, it feels like if this is a valid input this should be tested. I think that testBLAS tests for INCX=0. So maybe this can wait too.

@angsch
Copy link
Collaborator Author

angsch commented Nov 2, 2023

Makes sense. I will fiddle in incx=0 and let's see if someone has a strong opinion on f2c.

@angsch
Copy link
Collaborator Author

angsch commented Nov 3, 2023

  • incx=0 is added to the tests
  • I've tested with gfortran and ifort that that the tests trigger if the NRM2 implementation is flawed

My only remaining concern is if the NaN check, currently inlined as a.ne.a should be done in a separate routine. LAPACK's xISNAN does so to avoid overly aggressive compiler optimization according to the comment. In my tests the inlined check worked.

appveyor couldn't find flang, so CI is stil ok.

@langou
Copy link
Contributor

langou commented Nov 11, 2023

incx=0 is added to the tests. I've tested with gfortran and ifort that that the tests trigger if the NRM2 implementation is flawed

Thanks!

My only remaining concern is if the NaN check, currently inlined as a.ne.a should be done in a separate routine. LAPACK's xISNAN does so to avoid overly aggressive compiler optimization according to the comment. In my tests the inlined check worked.

Right. Maybe we just add a comment in the TESTING then to explain that this can be improved. I think, for now, it is enough to leave at that. That is leave it at "inline a.ne.a" for checking for NaNs.

Note that testing for NaNs in BLAS is also done by the project https://github.com/tlapack/testBLAS

@langou langou marked this pull request as ready for review November 11, 2023 02:15
langou
langou previously approved these changes Nov 11, 2023
@weslleyspereira
Copy link
Collaborator

Note that testing for NaNs in BLAS is also done by the project https://github.com/tlapack/testBLAS

And we are trying to get the tests working with LAPACK's continuous testing framework, see #913.

Add tests covering arrays with extreme numbers provided in
Anderson E. (2017)
Algorithm 978: Safe Scaling in the Level 1 BLAS
ACM Trans Math Softw 44:1--28
https://doi.org/10.1145/3061665

[D,S]NRM2 coverage improves
lines     59.1% -> 100.0%
branches  30.0% ->  90.0%.

[DZ,SC]NRM2 coverage improves
lines     67.0% -> 100.0%
branches  41.7% ->  91.7%
@angsch
Copy link
Collaborator Author

angsch commented Nov 12, 2023

Based on my testing, everything is fine if the tests are compiled even with -O3. Some NaN checks appear to be dropped if the tests are compiled with -ffast-math, which is documented as unsafe optimizations. The code now has a comment that the NaN checks rely on a not too aggressive compiler. I guess it is recommended to compile the tests at a moderate optimization level (-O2) and the code to be tested with whatever flags are suited.

I consider this PR finalized, so please merge if you agree.

@langou langou merged commit ae9c818 into Reference-LAPACK:master Nov 12, 2023
12 checks passed
@langou
Copy link
Contributor

langou commented Nov 12, 2023

Thanks @angsch!

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.

3 participants