Opened 10 years ago
Last modified 10 years ago
#8360 new Bugs
Multiplication operator should allow non-commutative version
Reported by: | Owned by: | Daniel Frey | |
---|---|---|---|
Milestone: | To Be Determined | Component: | operators |
Version: | Boost 1.53.0 | Severity: | Problem |
Keywords: | Cc: |
Description
The multipliable2 template in boost/operators.hpp
is defined with the BOOST_BINARY_OPERATOR_COMMUTATIVE
macro. This macro defines multiplication of types T and U in both orders in terms of T *= U
.
This assumes that multiplication is commutative, which is not generally true. For example when T is a nxn matrix type with double entries and U a nxn matrix with integer entries, then T *= U
makes sense, but operators.hpp
would define U * T
using T *= U
. Since matrix multiplication is not commutative, this would give wrong results.
Suggested solution: make multipliable2
use the NONCOMMUTATIVE macro, or add another multipliable2_nc
template.
Change History (2)
comment:1 by , 10 years ago
comment:2 by , 10 years ago
I haven't started using Boost.Operators yet, but it was useful to have a look at the implementation, and I've used some of its ideas.
I'll have a look at your v2 library and let you know if I have any issues or comments (I'm using GCC versions 4.4 and higher btw.).
Thanks for the report, but I think the problem is a bit larger than that. I started working on a successor for Boost.Operators which has explicit versions for commutative and non-commutative operators (for where is makes sense). This library also takes advantage of rvalue references, thus eliminating superfluous temporaries. If your compiler has support for rvalue references and this would be an option for you, have a look at https://github.com/d-frey/operators/. With rvalue references, there are additional optimization opportunities if the operator in question is indeed commutative, so yes, that property just got a priority bump.
Any feedback on the library is welcome. I'll also post an announcement of this library on the Boost list shortly, with any luck (and probably some more work), I hope that this can become the base for Boost.Operators v2.
If this is not a viable solution for you, please let me know.