Date: Thu, 20 Jun 2019 22:05:40 +0000
Greetings and thanks for the feedback!
On 6/18/19, 4:08 PM, "Gael Guennebaud" <mailto:gael.guennebaud_at_inria.fr> wrote:
> As the main developer of the Eigen library I follow those LA proposals with great interest. I do support the idea of a low-level C++ BLAS-like API as I ended up writing something similar within Eigen’s internals.
We thought of libraries like Eigen as a big target audience for this proposal, so it's good to hear that. P1674 explains how we ended up developing similar (but uglier) libraries in Trilinos.
> I appreciated reading the detailed discussions on design choices, but I did not find any on the “Side” parameters. In my opinion, they are dangerous and error prone because they make harder to parse which operation is going to be performed (have you to reverse the arguments or not?), and they are also (slightly) ambiguous (which one is on the left/right of the other?). So I strongly advice to find a way to get rid of the “Side” parameters.
This is helpful feedback -- thanks! I can see the value of having the function order express the order of mathematical operations, rather than introducing a tag or enum.
> To this end, the most obvious solution is probably to follow your “option 2” of paragraph "Retain view functions?" [1]. This option also makes it easier to generalize beyond BLAS limits, but that’s another topic!
I've CC'd Philippe because both of you gave feedback along these lines. Philippe asked whether we've considered tag dispatching for algorithm overloads, as a way to add overloads for e.g., quaternions. You suggested property tagging as a way to avoid a "Side" argument, by marking a matrix as "triangular" etc.
We went back and forth about a property tagging - based design. In the end, we decided against it. The main issue we see is that property tags "look like" iterator categories, but don't behave like them. You can write generic algorithms using iterator categories, but you can't write generic algorithms using arbitrary mathematical properties. (Just imagine the many generalizations of symmetry, for example.) This would make our proposal into a bunch of customization points, instead of a bunch of generic algorithms with high-performance implementations. In our view, a library customizable on mathematical properties is a high-level library, something more like Eigen and less like the BLAS. We wanted to be the low-level thing that higher-level code calls to get good performance and reasonable accuracy.
Anyway, I keep defending the proposal instead of soliciting more feedback ; - ) . How do you feel about this? Does the lack of property tagging and custom mathematical properties make this proposal a "no" vote for you? Does this "low-level" / "high-level" architecture make sense, or would it be better for a single library to try to cover both?
Thanks!
mfh
On 6/18/19, 4:08 PM, "Gael Guennebaud" <mailto:gael.guennebaud_at_inria.fr> wrote:
> As the main developer of the Eigen library I follow those LA proposals with great interest. I do support the idea of a low-level C++ BLAS-like API as I ended up writing something similar within Eigen’s internals.
We thought of libraries like Eigen as a big target audience for this proposal, so it's good to hear that. P1674 explains how we ended up developing similar (but uglier) libraries in Trilinos.
> I appreciated reading the detailed discussions on design choices, but I did not find any on the “Side” parameters. In my opinion, they are dangerous and error prone because they make harder to parse which operation is going to be performed (have you to reverse the arguments or not?), and they are also (slightly) ambiguous (which one is on the left/right of the other?). So I strongly advice to find a way to get rid of the “Side” parameters.
This is helpful feedback -- thanks! I can see the value of having the function order express the order of mathematical operations, rather than introducing a tag or enum.
> To this end, the most obvious solution is probably to follow your “option 2” of paragraph "Retain view functions?" [1]. This option also makes it easier to generalize beyond BLAS limits, but that’s another topic!
I've CC'd Philippe because both of you gave feedback along these lines. Philippe asked whether we've considered tag dispatching for algorithm overloads, as a way to add overloads for e.g., quaternions. You suggested property tagging as a way to avoid a "Side" argument, by marking a matrix as "triangular" etc.
We went back and forth about a property tagging - based design. In the end, we decided against it. The main issue we see is that property tags "look like" iterator categories, but don't behave like them. You can write generic algorithms using iterator categories, but you can't write generic algorithms using arbitrary mathematical properties. (Just imagine the many generalizations of symmetry, for example.) This would make our proposal into a bunch of customization points, instead of a bunch of generic algorithms with high-performance implementations. In our view, a library customizable on mathematical properties is a high-level library, something more like Eigen and less like the BLAS. We wanted to be the low-level thing that higher-level code calls to get good performance and reasonable accuracy.
Anyway, I keep defending the proposal instead of soliciting more feedback ; - ) . How do you feel about this? Does the lack of property tagging and custom mathematical properties make this proposal a "no" vote for you? Does this "low-level" / "high-level" architecture make sense, or would it be better for a single library to try to cover both?
Thanks!
mfh
Received on 2019-06-20 17:07:31