This page is a snapshot from the LWG issues list, see the Library Active Issues List for more information and the meaning of New status.

4315. Insufficient specification of vector_two_norm and matrix_frob_norm

Section: 29.9.13.9 [linalg.algs.blas1.nrm2], 29.9.13.12 [linalg.algs.blas1.matfrobnorm] Status: New Submitter: Mark Hoemmen Opened: 2025-08-14 Last modified: 2025-08-16

Priority: Not Prioritized

View all issues with New status.

Discussion:

The wording for vector_two_norm 29.9.13.9 [linalg.algs.blas1.nrm2] and matrix_frob_norm 29.9.13.12 [linalg.algs.blas1.matfrobnorm] has two issues.

  1. Their Returns clauses say that the functions return the "square root" of the sum of squares of the initial value and the absolute values of the elements of the input mdspan. However, nowhere in 29.9 [linalg] explains how to compute a square root.

    1. 1.a. The input mdspan's value_type and the initial value type are not constrained in a way that would ensure that calling std::sqrt on this expression would be well-formed.

    2. 1.b. There is no provision to find sqrt via argument-dependent lookup, even though 29.9 [linalg] has provisions to find abs, conj, real, and imag via argument-dependent lookup. There is no "sqrt-if-needed" analog to abs-if-needed, conj-if-needed, real-if-needed, and imag-if-needed.

  2. The overloads that take an initial value parameter Scalar init return Scalar.

    1. 2.a. This may silently lose information if the function uses std::sqrt to compute square roots. For example, if Scalar and the input mdspan's value_type are both int, the square root computed via std::sqrt would return double. However, vector_two_norm and matrix_frob_norm returning Scalar would force a rounding conversion back to int.

Suggested fix:

The easiest fix for both issues is just to Constrain both Scalar and the input mdspan's value_type to be floating-point numbers or specializations of std::complex for these two functions. This presumes that relaxing this Constraint and fixing the above two issues later would be a non-breaking change. If that is not the case, then I would suggest removing the two functions entirely.

Proposed resolution: