Date: Tue, 10 May 2022 11:11:13 -0400
On Tue, May 10, 2022 at 9:13 AM Patrik Tegelberg via Std-Proposals
<std-proposals_at_[hidden]> wrote:
>
> I often use vector math and usually make a small vector class overloading the math operators. I always lack a good option for element wise multiplication (Hadamard product). Divide becomes element wise divide, multiplication becomes the dot product and % becomes the cross product. There are no more operators with the correct precedence to overload. I suggest making another symbol, with multiplication precedence, available for overloading.
It should be noted that shader languages that have built-in
vector/matrix functionality do not attempt to create new operators for
these. With the exception of explicit matrix multiplication, all
operators are element-wise. All other operations are performed by
function calls.
Many popular C++ matrix libraries (I checked Eigen and GLM) follow
this convention as well. So I'm not sure if it's a good idea to add
operators for something we have so much precedent in today.
<std-proposals_at_[hidden]> wrote:
>
> I often use vector math and usually make a small vector class overloading the math operators. I always lack a good option for element wise multiplication (Hadamard product). Divide becomes element wise divide, multiplication becomes the dot product and % becomes the cross product. There are no more operators with the correct precedence to overload. I suggest making another symbol, with multiplication precedence, available for overloading.
It should be noted that shader languages that have built-in
vector/matrix functionality do not attempt to create new operators for
these. With the exception of explicit matrix multiplication, all
operators are element-wise. All other operations are performed by
function calls.
Many popular C++ matrix libraries (I checked Eigen and GLM) follow
this convention as well. So I'm not sure if it's a good idea to add
operators for something we have so much precedent in today.
Received on 2022-05-10 15:11:54