Hi Mark!

I guess I should’ve prefaced my question with, great work! Certainly a good step forward for C++.

1 & 2 I’ve only skimmed the proposal, it’s a bit beefy 😉 I’ll go through it all soonTM. Since this is a free function API, I would imagine various industries will extend the library with domain specific operations. I also believe this is a stepping stone. If successful, it should be up to domain experts to propose additions to it. The library/proposal should (hopefully) be flexible enough to allow this.
3. Yes 😊 I’d be happy to be that person.

mdarray seems like a good choice if it supports alignment. No problem there.

The reason I bring up quaternions is, they should be treated quite differently than lets say a vec4 (mdarray<float, 1, 4> I believe). Affine matrices can also be treated differently. So the point isn’t so much about features (though quaternions should be considered a requirement for 3D), but how the APIs might be too general in accepting any rank-1 types, for example. There needs to be a way to specify extra mathematical properties that have no bearing on storage.

Have you considered tag dispatching for algorithm overloads? One simple example, multiplying a vec4 to a matrix vs. multiplying a quaternion to a matrix.

I guess my point boils down to : working on md_span and md_array directly seems too general as input. I would propose to accept more specialized wrappers, that contain an md_span or md_array and fulfill a required interface. For example, matrix_span<…>, matrix<…>, affine_matrix<…>, vec<…>, quaternion<…>, user_provided_type<…>.

Just as we implement iterator contracts, the same can be enforced here with traits. Food for thought.

Best and congrats on reaching this milestone,
Philippe

From: Hoemmen, Mark
Sent: Tuesday, June 18, 2019 11:24 AM
To: sg14_at_[hidden]
Cc: Philippe Groarke
Subject: Re: [EXTERNAL] Re: [SG14] Linear algebra library proposal

Greetings!

1. Think of the library as a C++ BLAS binding. I highly recommend reading the “design discussion and justification” document.
2. Please don’t feel like we don’t care about your use case if we left something out : - ) . We left out a lot of things that we would personally find very useful; the documents explain why.
3. Are you thinking of vectors / matrices of quaternions / octonions? Our functions have very few restrictions on matrix or vector element types, but we would need a design review by an expert in quaternions / octonions to ensure that the definitions make sense when multiplication is not commutative. Would you like to be the expert for us? : - )
4. In general, if there is some modest way in which the design could be changed to accommodate quaternions and octonions, please let us know. (We won’t provide those types in this proposal, but we don’t want to impose unnecessary restrictions.)

Thanks!
mfh

On 6/18/19, 1:54 AM, "SG14 on behalf of Philippe Groarke via SG14" <sg14-bounces_at_[hidden] on behalf of sg14_at_[hidden]> wrote:

There is no mention of affine matrices or quaternions/octonions. Are those being left out?
 
From: Hoemmen, Mark via SG14
Sent: Monday, June 17, 2019 2:16 PM
To: sg14_at_[hidden]
Cc: Hoemmen, Mark
Subject: [SG14] Linear algebra library proposal
 
Hi all! We submitted a proposal for a C++ Standard linear algebra library.
 
Here is the proposal itself:
https://github.com/mhoemmen/cpp-proposals-pub/blob/Pre-COL2019-BLAS/D1673/blas_interface.md
 
Here is a design discussion and justification:
https://github.com/mhoemmen/cpp-proposals-pub/blob/Pre-COL2019-BLAS/D1674/evolving-from-blas.md
 
We also have an “mdarray” proposal – that is a container variant of mdspan, that might be a better option for very small matrices and vectors:
https://isocpp.org/files/papers/P1684R0.pdf
 
The first two are LONG so maybe fix yourself a nice beverage beforehand ; - ) .
 
Best,
mfh