Date: Mon, 1 May 2023 20:21:52 +0000
Hi Guy,
On May 1, 2023, at 4:54 AM, Guy Davidson via SG19 <sg19_at_[hidden]> wrote:
This message was sent from a non-IU address. Please exercise caution when clicking links or opening attachments from external sources.
Hello everyone
I'm just putting together a first pass at the wording for P1385, A proposal to add linear algebra support to the C++ standard library<https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2022/p1385r7.pdf>. If you look at the latest revision you will infer that at Kona in November and at Issaquah in February I addressed SG6 and LEWG about withdrawing the vector class entirely and simply offering a matrix class, where a vector is a special case of a matrix, with a single row or column. There were no objections to this approach.
While there were no objections raised in the meeting, others have come in, and I want to use the reflectors to gather opinion about the matter. The heart of the problem is: what does the vector product signify? Is it an inner or outer product? Is vector orientation significant?
With my mathematician's hat on, multiplying a row vector by a column vector is an inner product, yielding a scalar value if both vectors have the same number of elements. Appearing much more rarely, multiplying a column vector by a row vector is an outer product yielding a square matrix.
However, in the domains where I most make use of linear algebra, what is more significant is that the vector-matrix product treats the vector as a row vector, the matrix-vector product treats the vector as a column vector, and the vector-vector product treats the operation as an inner product. Orientation is irrelevant, and transposing vectors is a tedious waste of time.
The proposal is, under the hood, a way of bringing together element types, element conversions, extents and kernels into a single type, borrowing parts from mdspan. All of these items are template parameters. My current intent is to restore row and column vectors to the proposal, with additional motivation, and supply Orientation-Significant Kernels. I intend to offer Orientation-Agnostic Kernels in a subsequent paper (unless someone beats me to it, which you are all really, REALLY welcome to do) to enable this use-case as standard, allowing users to decide whether orientation is significant. Example code to follow in the fullness of time.
As someone that worries a lot about tensor algebra and calculus DSLs, I agree that representing a vector as a restriction of a matrix class template, where one extent has size 1, can cause more problems than it solves. A vector is a first order tensor and you shouldn’t be able to pass two indices to it, and specializing the matrix template template for static size 1 is terribly unappealing.
We use explicit index notation with implied summation, which bypasses entire the orientation and discussion (it’s explicit what you mean when you say `v(i)*v(i)` vs `v(i)*v(j)`), but it seems to me that it’s an important distinction in LA and I wouldn’t want to be forced to use a transpose operator to go from the “blessed” version to the other orientation, even if the operator is evaluated lazily and is sometimes free.
Luke
Speaking of which, time is tight: I have a fortnight until the Varna paper deadline, so I would appreciate any commentary sooner rather than later.
Cheers,
G
--
SG19 mailing list
SG19_at_[hidden]
https://lists.isocpp.org/mailman/listinfo.cgi/sg19
On May 1, 2023, at 4:54 AM, Guy Davidson via SG19 <sg19_at_[hidden]> wrote:
This message was sent from a non-IU address. Please exercise caution when clicking links or opening attachments from external sources.
Hello everyone
I'm just putting together a first pass at the wording for P1385, A proposal to add linear algebra support to the C++ standard library<https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2022/p1385r7.pdf>. If you look at the latest revision you will infer that at Kona in November and at Issaquah in February I addressed SG6 and LEWG about withdrawing the vector class entirely and simply offering a matrix class, where a vector is a special case of a matrix, with a single row or column. There were no objections to this approach.
While there were no objections raised in the meeting, others have come in, and I want to use the reflectors to gather opinion about the matter. The heart of the problem is: what does the vector product signify? Is it an inner or outer product? Is vector orientation significant?
With my mathematician's hat on, multiplying a row vector by a column vector is an inner product, yielding a scalar value if both vectors have the same number of elements. Appearing much more rarely, multiplying a column vector by a row vector is an outer product yielding a square matrix.
However, in the domains where I most make use of linear algebra, what is more significant is that the vector-matrix product treats the vector as a row vector, the matrix-vector product treats the vector as a column vector, and the vector-vector product treats the operation as an inner product. Orientation is irrelevant, and transposing vectors is a tedious waste of time.
The proposal is, under the hood, a way of bringing together element types, element conversions, extents and kernels into a single type, borrowing parts from mdspan. All of these items are template parameters. My current intent is to restore row and column vectors to the proposal, with additional motivation, and supply Orientation-Significant Kernels. I intend to offer Orientation-Agnostic Kernels in a subsequent paper (unless someone beats me to it, which you are all really, REALLY welcome to do) to enable this use-case as standard, allowing users to decide whether orientation is significant. Example code to follow in the fullness of time.
As someone that worries a lot about tensor algebra and calculus DSLs, I agree that representing a vector as a restriction of a matrix class template, where one extent has size 1, can cause more problems than it solves. A vector is a first order tensor and you shouldn’t be able to pass two indices to it, and specializing the matrix template template for static size 1 is terribly unappealing.
We use explicit index notation with implied summation, which bypasses entire the orientation and discussion (it’s explicit what you mean when you say `v(i)*v(i)` vs `v(i)*v(j)`), but it seems to me that it’s an important distinction in LA and I wouldn’t want to be forced to use a transpose operator to go from the “blessed” version to the other orientation, even if the operator is evaluated lazily and is sometimes free.
Luke
Speaking of which, time is tight: I have a fortnight until the Varna paper deadline, so I would appreciate any commentary sooner rather than later.
Cheers,
G
--
SG19 mailing list
SG19_at_[hidden]
https://lists.isocpp.org/mailman/listinfo.cgi/sg19
Received on 2023-05-01 20:21:56