P1673 R13 A free function linear algebra interface based on the BLAS

wg21bot commented 5 years ago

P1673R0 A free function linear algebra interface based on the BLAS (Mark Hoemmen, Daisy Hollman, Christian Trott, Daniel Sunderland, Nevin Liber, Siva Rajamanickam, Li-Ta Lo, Graham Lopez, Peter Caday, Sarah Knepper, Piotr Luszczek, Timothy Costa)

tituswinters commented 5 years ago

This R0 needs to be forwarded by some/all of the relevant SGs before going to LEWG for design review. Removing the LEWG label.

brycelelbach commented 5 years ago

Mark, if you want some early design review, we can look at this in LEWGI.

brycelelbach commented 5 years ago

Cologne 2019-07 LEWGI Minutes

P1673R0 & P1674R0 C++ BLAS Library: Design Feedback

Champion: Christian Trott

Minute Taker: Tobias Loew

Start Overview: 07-16 8:52

Start Review: 9:20

Algorithms are parameterized on a concept, iterators. The proposed linear algebra algorithms are parameterized on a concrete view type, mdspan.

Do people need to spell scaled_scalar? Can it just be an implementation-defined type with certain properties.

SG1 needs to review this from a parallelization/vectorization angle.

How should we handle outputs in the API?

Explore a range-style lazy view API.

End: 10:17

CONSENSUS: Bring a revision of P1673R0, exploring conceptification of mdspan and a range-style lazy API, to LEWGI for further design feedback.

wg21bot commented 4 years ago

P1673R1 A free function linear algebra interface based on the BLAS (Mark Hoemmen, Daisy Hollman, Christian Trott, Daniel Sunderland, Nevin Liber, Siva Rajamanickam, Li-Ta Lo, Graham Lopez, Peter Caday, Sarah Knepper, Piotr Luszczek, Timothy Costa)

Cpp-Lisa commented 4 years ago

Removing SG6 tag

brycelelbach commented 4 years ago

Note that the LEWGI feedback from Cologne didn't make it clear that SG1 needs to see this, but they certainly do. Sorry, my mistake.

brycelelbach commented 4 years ago

This was forwarded to LEWG by SG14 at Cologne.

brycelelbach commented 4 years ago

Belfast 2019-11 LEWGI Minutes

P1673R1 Free Function Linear Algebra Library

Champion: Mark Hoemmen

Minute Taker: Andreas Weis

Start Review: 11-05 8:55

Are the algorithms inplace (like sort) or non-modifying (like transform)?

Should dimensional errors be checked? If we know them all at compile time, we should check them.

Make these constexpr? May not be possible/easy in version 1 - constexprification is ongoing, and you may have dependencies on that.

Walking through the matrix multiply code example was very useful.

Add more examples showing the use of the views.

Do we need to have the mdarray overloads in version 1?

Start Polling: 10:12

POLL: We are comfortable with the design of "mdspan transformations" in P1673 (scaled_view, transpose_view, etc).

Strongly For	Weakly For	Neutral	Weakly Against	Strongly Against
0	11	0	0	1

Attendance: 16

That's got consensus.

POLL: Dimensional errors should be checked at compile time (e.g. Mandates clauses) if all dimensions are known at compile time; otherwise, they should be preconditions (e.g. Expects clauses).

NO OBJECTION TO UNANIMOUS CONSENT

Attendance: 16

POLL: Making the linear algebra algorithms in P1673 constexpr should be a priority for the initial release.

Strongly For	Weakly For	Neutral	Weakly Against	Strongly Against
1	2	7	3	0

Attendance: 16

No consensus.

POLL: mdarray overloads should be a priority for the initial release.

Strongly For	Weakly For	Neutral	Weakly Against	Strongly Against
1	1	4	3	1

Attendance: 17

Weak consensus against.

POLL: Conceptifying input and output arguments should be a priority for the initial release.

Strongly For	Weakly For	Neutral	Weakly Against	Strongly Against
1	2	3	3	1

Attendance: 16

No consensus.

Break: 10:22

Resume: 10:44

Start Polling: 11:15

POLL: Packed layouts are a priority for the initial release.

Strongly For	Weakly For	Neutral	Weakly Against	Strongly Against
3	6	4	0	1

Attendance: 18

SA: I want to start with something as simple as possible.

That has consensus.

POLL: We are comfortable with the design of layout_blas_general and layout_blas_packed in P1673.

NO OBJECTION TO UNANIMOUS CONSENT

Attendance: 18

POLL: Linear algebra algorithms that produce a single scalar output should return the output.

Strongly For	Weakly For	Neutral	Weakly Against	Strongly Against
2	8	2	1	2

Attendance: 18

That has consensus.

POLL: The intermediate type used for reduction-style linear algebra algorithms should be the type of the initial value, or the element type derived from the inputs if there is no initial value (e.g. what std::reduce/std::accumulate does).

Strongly For	Weakly For	Neutral	Weakly Against	Strongly Against
2	7	3	1	0

Attendance: 18

That has consensus.

A: I want an explicit template parameter.

POLL: Send P1673 (Free Function Linear Algebra Library) to LEWG and SG1.

Strongly For	Weakly For	Neutral	Weakly Against	Strongly Against
12	1	3	0	0

Attendance: 18

That has consensus.

After speaking with the SG1 chair, SG1 doesn't need to see this.

End: 11:31

CONSENSUS: LEWGI sends P1673R1 (Free Function Linear Algebra Library), with the guidance below, to LEWG.

Add the walkthrough of the matrix multiply code to the presentation.
Add more examples showing the use of mdspan transformations.
Rename "mdspan views" in the paper to something else (such as "mdspan transformations").
Propose batched linear algebra in a separate paper, not this one.
Remove mdarray overloads.
Check dimensional errors at compile time (e.g. Mandates clauses) if all dimensions are known at compile time; otherwise, make them precondition violations (e.g. Expects clauses).
Make linear algebra algorithms that produce a single scalar output return that output.
Make the intermediate type used for reduction-style linear algebra algorithms the type of the initial value, or the element type derived from the inputs if there is no initial value (e.g. what std::reduce/std::accumulate does).

wg21bot commented 4 years ago

P1673R2 A free function linear algebra interface based on the BLAS (Mark Hoemmen, Daisy Hollman, Christian Trott, Daniel Sunderland, Nevin Liber, Siva Rajamanickam, Li-Ta Lo, Damien Lebrun-Grandie, Graham Lopez, Peter Caday, Sarah Knepper, Piotr Luszczek, Timothy Costa)

FabioFracassi commented 4 years ago

2020-06-15 Library Evolution Telecon

P1673R2: BLAS Linear Algebra

2021-06-15 Library Evolution Telecon Minutes

Chair: Fabio Fracassi

Champion: Christian Trott

Minute Taker: Guy Davidson, Ben Craig

POLL: We want to put arguments in math order (result first) as opposed to C++/BLAS order (result last).

Strongly Favor	Weakly Favor	Neutral	Weakly Against	Strongly Against
2	0	4	10	5

Attendance: 29

Outcome: consensus against, leave parameter order as proposed in the paper

__POLL: We want the paper authors to investigate using existing C++20 concepts (e.g. move_constructible) to constrain the algorithms.__

No objection to unanimous consent.

Attendance: 29

Outcome: consensus.

POLL: We want to require the paper authors to investigate that the requirements/concepts match with the conceptified numerics algorithms.

Strongly Favor	Weakly Favor	Neutral	Weakly Against	Strongly Against
1	12	5	2	1

Attendance: 29

Outcome: consensus

Chair Notes:

We did not take the following polls, but the topics were discussed at length, so it is likely that questions along those lines will come up again. The next revision of the paper should do its best to address these:

We want the paper authors to explore using a dedicated namespace for this library.
We want to reserve the name scale_view/transpose_view (of mdspan) (for use with ranges)
We want to make the interface compatible with transpose_view/scale_view compatible with ranges transpose view.
Support for GPU/different memory regions?

The naming discussion uncovered a general issue, when there are names that might fit into different contexts. A informational or policy paper exploring this design space would be welcome.

The general theme of the discussion was integration into the C++ Standard Library. The Paper introduces new (specialized) algorithms, so naturally there is a question on how well they integrate with currently existing algorithms (especially the algorithms in the numeric header). Another concern is proper conceptification.

wg21bot commented 3 years ago

P1673R3 A free function linear algebra interface based on the BLAS (Mark Hoemmen, Daisy Hollman, Christian Trott,Daniel Sunderland, Nevin Liber ,Li-Ta Lo, Damien Lebrun-Grandie, Graham Lopez, Peter Caday, Sarah Knepper, Piotr Luszczek, Timothy Costa)

brycelelbach commented 3 years ago

2021-06-22 Library Evolution Telecon

P1673R3: BLAS Linear Algebra

Slides

2021-06-22 Library Evolution Telecon Minutes

Chair: Bryce Adelstein Lelbach

Champion: Mark Hoemmen

Minute Taker: Ben Craig

Start: 2021-06-22 10:05 Pacific

Does this proposal have:

Examples?
- Yes. They're at the end of the paper in an appendix; at least one should probably be moved up earlier.
Field experience?
- Implementation experience?
  - Yes. 1 reference implementation from spec, not in a major Standard Library implementation.
  - https://github.com/kokkos/stdBLAS
- Usage experience?
- Deployment experience?
Performance considerations?
- Yes.
Discussion of prior art?
- Yes. This is based on the the BLAS.
Changes Library Evolution previously requested?
- Yes. See slides and paper changelog.
Wording?
- Yes. Reviewed by wordsmith Daniel Sunderland.
Feature test macro?

The authors explored conceptification in two areas, and they believe that we should not pursue it for either area:

Element types (e.g. a number concept).
- They believe conceptification similar to P1813 is likely too constraining. Numerical linear algebra deals with the world of the digital representation of numbers, not the mathematical concept of numbers. People care about non-associativity and non-commutativity.
mdspan (e.g. a multi-dimensional span concept).
- They believe conceptification would likely require replicating much of the mdspan machinery and doesn't seem like it would have any real benefit.

Topics to Polls:

Which algorithms should be included in the first version of this?
Are the type constraints for the algorithms and how they are expressed correct?
Are we okay with not trying to constrain the element types with a number concept like those from P1813?

POLL: The linear algebra algorithms in P1673 do not need to be constrained on the mathematical concept of numbers.

Strongly Favor	Weakly Favor	Neutral	Weakly Against	Strongly Against
12	10	1	0	0

Attendance: 30

# of Authors: 5

Author Position: 5x SF

Outcome: Consensus in favor.

N: I want to see semantic requirements, not just syntactic requirements, and I don't see that today.

Investigate where (move) assignable / constructible requirements (etc) are missing.

POLL: The linear algebra algorithms in P1673 should only support integer types (including extended integer types), floating point types (including potential future extended floating point types), and complex types of the the preceding two categories.

Strongly Favor	Weakly Favor	Neutral	Weakly Against	Strongly Against
0	0	8	7	6

Attendance: 30

# of Authors: 5

Author Position: WAs and SAs.

Outcome: That has consensus against.

POLL: We are okay with the style of constraints used in the linear algebra algorithms in P1673R3, which are solely syntactic, aside from assignment and construction.

Strongly Favor	Weakly Favor	Neutral	Weakly Against	Strongly Against
4	15	2	1	0

Attendance: 30

# of Authors: 5

Author Position: WFs and SFs.

Outcome: That has consensus in favor.

WA: This says that there's not really any requirements. It's not clear what these algorithms do.

End: 11:39

Paper Feedback

Add a table of contents to paper.

Add a summary table of which algorithms are included and not included.

Make the examples more prominent in the paper. Move some of them earlier in the paper into the design section.

Slides Feedback

Publish slides as a P paper.

Add slide numbers.

Slide typo: "Open-source impl.s" on "Basic Linear Algebra Subprograms" slide.

Some of the fonts in the slides render oddly ("ExecutionPolicy", for example). Please embed the fonts.

Summary

We reviewed P1673, which proposes Standard C++ linear algebra algorithms inspired by the BLAS, a standard for linear algebra. We've seen this proposal a few times now, and the authors have been diligent in responding to the changes and explorations Library Evolution as requested.

One of those explorations consumed much of our time today. In our previous review, we had asked the authors to explore constraining the element types in linear algebra algorithms using number concepts similar to those in P1813.

The authors considered this, but they believe that this will be overly constraining; numeric linear algebra doesn't necessarily deal in the formal notion of numbers. Library Evolution had a preference to not use number concepts such as those from P1813.

We also discussed what exact requirements should be placed on element types in these algorithms, and subsequently what we can say about what these algorithms do. Two different options were identified:

We could define the effect and results of the algorithms, and then describe the syntactic and semantic requirements that arise from that definition.
We could say that the algorithms are equivalent to whatever happens when you apply a certain series of operations, and then describe the syntactic requirements that are implied by those operations.

Library Evolution had a preference for the second option, describing the the algorithms in terms of what operations they are equivalent to and constraining the element types based on what syntax is needed by those operations.

It was noted that some requirements are missing, in particular for assignability and constructibilty. The authors will address this in the next revision.

Outcome

Bring a revision of P1673R3 (BLAS Linear Algebra), with the guidance below, to Library Evolution for further design review.

Add a table of contents.
Make examples more prominent in the paper; at least some of them should appear early in the paper.
Add a table summarizing which BLAS routines are included as algorithms and which are omitted.
Audit all requirements and add any missing assignability and constructibility requirements.
Consider using exposition-only concepts and requires clauses to express requirements more clearly.

Publish the presentation slides for P1673R3 (Linear Algebra) as a P paper, with the guidance below.

Add slide numbers.
Fix "Open-source impl.s" typo on "Basic Linear Algebra Subprograms" slide.

wg21bot commented 3 years ago

P1673R4 A free function linear algebra interface based on the BLAS (Mark Hoemmen, Daisy Hollman,Christian Trott,Daniel Sunderland,Nevin Liber,Alicia KlinvexLi-Ta Lo,Damien Lebrun-Grandie,Graham Lopez,Peter Caday,Sarah Knepper,Piotr Luszczek,Timothy Costa)

wg21bot commented 2 years ago

P1673R5 A free function linear algebra interface based on the BLAS (Mark Hoemmen, Daisy Hollman,Christian Trott,Daniel Sunderland,Nevin Liber,Alicia KlinvexLi-Ta Lo,Damien Lebrun-Grandie,Graham Lopez,Peter Caday,Sarah Knepper,Piotr Luszczek,Timothy Costa)

wg21bot commented 2 years ago

P1673R6 A free function linear algebra interface based on the BLAS (Mark Hoemmen, Daisy Hollman,Christian Trott,Daniel Sunderland,Nevin Liber,Alicia KlinvexLi-Ta Lo,Damien Lebrun-Grandie,Graham Lopez,Peter Caday,Sarah Knepper,Piotr Luszczek,Timothy Costa)

wg21bot commented 2 years ago

P1673R7 A free function linear algebra interface based on the BLAS (Mark Hoemmen, Daisy Hollman,Christian Trott,Daniel Sunderland,Nevin Liber,Alicia KlinvexLi-Ta Lo,Damien Lebrun-Grandie,Graham Lopez,Peter Caday,Sarah Knepper,Piotr Luszczek,Timothy Costa)

brycelelbach commented 2 years ago

2022-04-26 Library Evolution Telecon

P1673R7: Linear Algebra

2022-04-26 Library Evolution Telecon Minutes

Chair: Fabio Fracassi

Minute Taker: Inbal Levi

Champion: Mark Hoemmen

Summary

The Paper was presented in a detailed High level overview.

Next Steps

Discussion will continue in a future telecon

wg21bot commented 2 years ago

P1673R8 A free function linear algebra interface based on the BLAS (Mark Hoemmen, Daisy Hollman,Christian Trott,Daniel Sunderland,Nevin Liber,Alicia Klinvex,Li-Ta Lo,Damien Lebrun-Grandie,Graham Lopez,Peter Caday,Sarah Knepper,Piotr Luszczek,Timothy Costa)

brycelelbach commented 2 years ago

2022-05-24 Library Evolution Telecon

P1673R8: Linear Algebra

2022-05-24 Library Evolution Telecon Minutes

Chair: Fabio Fracassi

Minute Taker: Ben Craig

Champion: Mark Hoemmen

Summary

High level design overview has been continued and finished.

The design of BLAS views has been analysed in some detail. There was no opposition to this design. BLAS views do not share the same ownership problems that earlier designs in the realm of expression templates had, and its ownership model has precedence in range views.

We also want the full set of BLAS1 operations, even though some of the operations could be expressed in terms of more generic (range) algorithms. The full set is more ergonomic (especially for users already familiar with BLAS) and offers easier optimisation opportunities .

LAs conjugation conj needs to be analysed how it acts as a customization point.

Next Steps

Update the paper and return to Library Evolution for additional review.

mattkretz commented 2 years ago

2022-06-09 SG6 Telecon

D1673R9: A free function linear algebra interface based on the BLAS

2022-06-09 SG6 Telecon Minutes

Chair: Matthias Kretz

Champion: Mark Hoemmen

Minute Taker: John McFarlane

no quorum; no polls taken; no objections to below statements on conj on SG6 reflector

Summary

Support for custom complex number types (std::conj "customization")?

Not only complex numbers require conjugation. (quaternions, dual numbers, ...) I.e. there's no obvious type constraint.

SG6 position on conj:
1. The feature (conjugated(A) or conjugate_transposed(A) of matrix or vector of user-defined types) is reasonably integral to the proposal; we generically oppose deferring it based on the hope that we’ll be able to specify it in a nicer way in the future [with new customization point syntax].
2. There exists a simple rule, which is one possible path forward, we’re pointing out its simplicity because it engenders teachability: Do ADL-ONLY lookup (preventing finding std::conj for primitive types) for conj (as with ranges); if you find something you use it, and if you don’t, you do nothing. (“Primitives aren’t that special.” Benefit is that custom real types work out of the box.)
3. The alternative: say that if you choose to use conjugated or conjugate_transposed, that you MUST supply the conj ADL-findable thing, else ill-formed; this is a safety mechanism that may not have been considered previously by LEWG. (Make primitives special, to regain safety. The cost is that custom real types need to have a conj ADL-findable, if you’re using conjugated or conjugate_transposed.)
How to perform generic division (left vs. right division)?
- Left division vs. right division could be chosen by the caller by providing a division BinaryOp parameter. If none is given, operator/ is used.
- Explore tying the division op to DiagonalStorage.

wg21bot commented 2 years ago

P1673R9 A free function linear algebra interface based on the BLAS (Mark Hoemmen, Daisy Hollman,Christian Trott,Daniel Sunderland,Nevin Liber,Alicia KlinvexLi-Ta Lo,Damien Lebrun-Grandie,Graham Lopez,Peter Caday,Sarah Knepper,Piotr Luszczek,Timothy Costa)

brycelelbach commented 2 years ago

2022-07-05 Library Evolution Telecon

P1673R9R9: Linear Algebra

2022-07-05 Library Evolution Telecon Minutes

Chair: Fabio Fracassi

Minute Taker: Inbal Levi

Champion: Mark Hoemmen

Summary

No polls were taken.

Next Steps

Review will proceed in a breakout task group.

wg21bot commented 1 year ago

P1673R10 A free function linear algebra interface based on the BLAS (Mark Hoemmen, Daisy Hollman,Christian Trott,Daniel Sunderland,Nevin Liber,Alicia KlinvexLi-Ta Lo,Damien Lebrun-Grandie,Graham Lopez,Peter Caday,Sarah Knepper,Piotr Luszczek,Timothy Costa)

FabioFracassi commented 1 year ago

2022-11-10 13:00 to 15:00 UTC-10 Kona Library Evolution Meeting

P1673R10: A free function linear algebra interface based on the BLAS

2022-11-10 13:00 to 15:00 UTC-10 Kona Library Evolution Minutes

Champion: Christian Trott (in-person)

Chair: Bryce Adelstein Lelbach & Corentin Jabot

Minute Taker: Steve Downey

Start: 2022-11-10 13:10 UTC-10

Could in_vector_t be a contiguous range? No, we need access to things like stride.

Open Questions:

Conceptification.
- Of element types.
- Of mdspans.
Named type requirements vs concepts for expressing constraints.
get_mdspan customization point.
Interoperability with P1385.
What and how should we specify that the operations do?

Action Items:

Use CamelCase for the type requirement names.
Remove the _t from the type requirement names.
Rename the named type requirements to avoid matrix/vector terminology to avoid conflicts with P1385.
Explore expressing constraints with concepts instead of named type requirements.

POLL: The specification of linear algebra algorithms can be hand-wavy (draft poll not taken).

POLL: The specification of linear algebra algorithms can be in terms of operators that must exist (draft poll not taken).

David Stone formulated the options for this poll.

POLL: The description of linear algebra algorithms should be (vote for the options you can tolerate, vote as many times as you like):

Options	Votes
Syntax only (status quo)	15
Hand wavy do math	27
Do math	2

Break: 15:00

Resume: 15:24

End: 15:57

Next Steps

Revise the paper, with the guidance below, and return to Library Evolution for further design review.

Use CamelCase for the type requirement names.
Remove the _t from the type requirement names.
Rename the named type requirements to avoid matrix/vector terminology to avoid conflicts with P1385.
Explore expressing constraints with concepts instead of named type requirements.

wg21bot commented 1 year ago

P1673R11 A free function linear algebra interface based on the BLAS (Mark Hoemmen, Daisy Hollman,Christian Trott,Daniel Sunderland,Nevin Liber,Alicia KlinvexLi-Ta Lo,Damien Lebrun-Grandie,Graham Lopez,Peter Caday,Sarah Knepper,Piotr Luszczek,Timothy Costa)

brycelelbach commented 1 year ago

2023-02-10 13:00 to 17:30 Issaquah Library Evolution Meeting

P1673R11: Linear Algebra

2023-02-10 13:00 to 17:30 UTC-8 Issaquah Library Evolution Minutes

Champion: Mark Hoemmen (R)

Chair: Bryce Adelstein Lelbach (IP) & Billy Baker (IP)

Minute Taker: Steve Downey (IP)

Start: 2023-02-10 13:04 UTC-8

Break: 15:15

Resume: 15:32

Does this paper have:

Examples?
- Yes.
Field experience?
- Implementation experience?
  - Yes, reference implementation and in NVC++.
- Usage experience?
  - Yes, reference implementation and in NVC++.
- Deployment experience?
  - Yes, reference implementation and in NVC++.
Performance considerations?
- Yes.
Discussion of prior art?
- Yes.
Changes Library Evolution previously requested?
- Yes.
Wording?
- Yes.
Breaking changes?
- No.
Feature test macro?
- Yes.
Freestanding?
- ?
Format and/or iostream support?
- Not applicable
Hash support?
- Not applicable
Allocator support?
- ?

Should this be freestanding?

Can any algorithms allocate? If so, should they support allocators?

Should out-vector subsume in-vector? Should we add a base vector exposition-only concept? We don't seem to have strong feelings on this - it's exposition only.

POLL: Vote once for the names you like:

Option	Votes
`vector_norm2`, `matrix_one_norm`, `matrix_inf_norm`	0
`vector_two_norm`, `matrix_one_norm`, `matrix_inf_norm`	14
`vector_norm2`, `matrix_norm1`, `matrix_norm_inf`	1
`vector_norm_two`, `matrix_norm_one`, `matrix_norm_inf`	2

Attendance: 19 (in person) + 6 (remote)

# of Authors: 3

__POLL: Explore replacing symmetric_matrix_vector_product with an overload of matrix_vector_product.__

Strongly Favor	Weakly Favor	Neutral	Weakly Against	Strongly Against
0	0	2	4	11

Attendance: 20 (in person) + 7 (remote)

# of Authors: 3

Author Position: 3 SA

Outcome: Consensus against.

__POLL: Use words instead of digits for numbers in linear algebra function names - matrix_rank_1_update would become matrix_rank_one_update, symmetric_matrix_rank_2k_update would become symmetric_matrix_rank_two_k_update.__

Strongly Favor	Weakly Favor	Neutral	Weakly Against	Strongly Against
2	3	6	8	1

Attendance: 18 (in person) + 7 (remote)

# of Authors: 3

Author Position: WA, 2 N

Outcome: No consensus for change.

__POLL: Replace symmetric_matrix_(left|right)_product with symmetric_matrix_product(B, A, tri, C) and symmetric_matrix_product(A, tri, B, C).__

Strongly Favor	Weakly Favor	Neutral	Weakly Against	Strongly Against
7	9	1	0	1

Attendance: 19 (in person) + 7 (remote)

# of Authors: 3

Author Position: 2 SF, 1 WF

Outcome: Consensus in favor.

SA: I think the original made more sense to me.

__POLL: Remove the constexpr variables of `(row	column)_major_t`type and rename`(row	column)_major_t`to`(row	column)_major`.__	Strongly Favor	Weakly Favor	Neutral	Weakly Against	Strongly Against
0	2	8	7	2

Attendance: 19 (in person) + 8 (remote)

# of Authors: 3

Author Position: 1 WA, 2 SA

Outcome: No consensus for change.

Wording Volunteers:

Zach Laine
David Olsen

Editorial Action Items:

Split [linalg.reqs.val] into two sections: one on requirements on the value type and one on implementatio nfreedom.
Rephrase [linalg.reqs.val] (3.7) to use "The type T must" language.
Fix typo in [linalg.reqs.val] (1.1): delete "and reference".
Change the name of the T init parameters and the parameter to sum_of_squares_result to allow simplification of [linalg.reqs.val] 1.
In [linalg.reqs.val], say "a value initialized object acts as the additive identity".
Move the reference to "Fast Linear Algebra Is Stable" into the bibliography.
Remove "Throws: Nothing" from givens_rotation_setup because it doesn't need to be explicitly stated.
Remove const from by-value parameters.
Hoist ExecutionPolicy wording to apply to both this and the parallel algorithms.
Simplify preconditions that can be stated as an equality comparison of the extents.
Add a requirement that if not otherwise permitted, in-vectors/in-matrixs may not be the same object as out-vectors/out-matrixs.
Change remarks about aliasing to say "object" instead of "vector" and "matrix".
Rephrase aliasing wording.
Audit "Equivalent to" wording and use the new "as if" wording.

Design Action Items:

In out-vector/inout-vector/out-matrix/inout-matrix, instead of checking if the element type is const, check if you can assign the element type to the reference type.
Make given_rotations_setup noexcept.
Consistently pass complex by value.
Rename vector_norm2 to vector_two_norm.
Replace (hermitian|symmetric|triangular)_matrix_(left|right)_product with (hermitian|symmetric|triangular)_matrix_product(B, A, tri, C) and (hermitian|symmetric|triangular)_matrix_product(A, tri, B, C).
Ensure the BLAS 3 *_update functions have an overload that does not take a scaling parameter.
Don't remove const from the element type in transposed when you have default_accessor.

POLL: Modify P1673R11 (Linear Algebra) as described below, and then send the revised paper to Library for C++26 classified as B3 - addition, to be confirmed with a Library Evolution electronic poll.

In out-vector/inout-vector/out-matrix/inout-matrix, instead of checking if the element type is const, check if you can assign the element type to the reference type.
Make given_rotations_setup noexcept.
Consistently pass linear algebra value types by value.
Rename vector_norm2 to vector_two_norm.
Replace (hermitian|symmetric|triangular)_matrix_(left|right)_product with (hermitian|symmetric|triangular)_matrix_product(B, A, tri, C) and (hermitian|symmetric|triangular)_matrix_product(A, tri, B, C).
Ensure the BLAS 3 *_update functions have an overload that does not take a scaling parameter.
Don't remove const from the element type in transposed when you have default_accessor.

Strongly Favor	Weakly Favor	Neutral	Weakly Against	Strongly Against
16	5	0	0	0

Attendance: 19 (in person) + 7 (remote)

# of Authors: 3

Author Position: 3 SF

Outcome: Unanimous consensus in favor

End: 17:40

Summary

We extensively reviewed P1673, the BLAS Linear Algebra proposal. We've seen this paper a number of times before; our goal in this review was to identify any remaining open design questions.

We first reviewed the exposition-only concepts, and decided to check if the element type can be assigned to the reference type, instead of checking if the element type is const. We also didn't remove const from the element type in transposed when you have default_accessor.

We found a number of places in the specification where linear algebra value types are passed by const reference where they should be passed by value. The authors will fix this so that we consistently pass these types by value.

We discussed some inconsistencies in the spelling of algorithms that contain "norm" in their name. To resolve this, we decided to rename vector_norm2 to vector_two_norm.

When reviewing the (hermitian|symmetric|triangular)_matrix_(left|right)_product family of algorithms, we decided that instead of having left and right versions, we should have a single overload of each that takes the triangle parameter in a different place in the parameter list.

We also wanted to add overloads that do not take a scaling parameter to the BLAS 3 *_update functions.

At the conclusion of our review, we had not identified any significant open questions or design changes. So, we took a vote to make the requested modifications to the paper and then send it to Library for C++23, and we had unanimous consensus in favor.

Next Steps

Modify P1673R11 (Linear Algebra) as described below, and then take a Library Evolution electronic poll to send the revised paper to Library for C++26 classified as B3 - addition,

In out-vector/inout-vector/out-matrix/inout-matrix, instead of checking if the element type is const, check if you can assign the element type to the reference type.
Make given_rotations_setup noexcept.
Consistently pass linear algebra value types by value.
Rename vector_norm2 to vector_two_norm.
Replace (hermitian|symmetric|triangular)_matrix_(left|right)_product with (hermitian|symmetric|triangular)_matrix_product(B, A, tri, C) and (hermitian|symmetric|triangular)_matrix_product(A, tri, B, C).
Ensure the BLAS 3 *_update functions have an overload that does not take a scaling parameter.
Don't remove const from the element type in transposed when you have default_accessor.

wg21bot commented 1 year ago

P1673R12 A free function linear algebra interface based on the BLAS (Mark Hoemmen, Daisy Hollman,Christian Trott,Daniel Sunderland,Nevin Liber,Alicia KlinvexLi-Ta Lo,Damien Lebrun-Grandie,Graham Lopez,Peter Caday,Sarah Knepper,Piotr Luszczek,Timothy Costa)

brycelelbach commented 1 year ago

2023-05 Library Evolution Electronic Poll Outcomes

Poll 1: Send [[P1673R12]] BLAS Linear Algebra to Library Working Group for C++26.	Strongly Favor	Weakly Favor	Neutral	Weakly Against	Strongly Against
5	9	2	1	1

Outcome: Consensus in favor.

wg21bot commented 9 months ago

P1673R13 A free function linear algebra interface based on the BLAS (Mark Hoemmen, Daisy Hollman,Christian Trott,Daniel Sunderland,Nevin Liber,Alicia KlinvexLi-Ta Lo,Damien Lebrun-Grandie,Graham Lopez,Peter Caday,Sarah Knepper,Piotr Luszczek,Timothy Costa)

cplusplus / papers