Subject: Re: [EXTERNAL] Re: Linear algebra library proposal
From: p groarke (philippe.groarke_at_[hidden])
Date: 2019-06-18 11:19:04
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,
From: Hoemmen, Mark
Sent: Tuesday, June 18, 2019 11:24 AM
Cc: Philippe Groarke
Subject: Re: [EXTERNAL] Re: [SG14] Linear algebra library proposal
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.)
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
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:
Here is a design discussion and justification:
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:
The first two are LONG so maybe fix yourself a nice beverage beforehand ; - ) .
SG14 list run by email@example.com
Older Archives on Google Groups