Created attachment 247 [details] hg exported patch. May fix complaint in [272]?
It seems that the patch is missing the test case code. I'll add this file over the weekend. John
Created attachment 248 [details] hg exported patch w/test cases. Updated patch
Comment on attachment 248 [details] hg exported patch w/test cases. Review of attachment 248 [details]: ----------------------------------------------------------------- I am not so sure about operator<< and operator>> to indicate bit shifts. We already use << in the comma-initializer: A << 1,2,3,4 means that A should be filled with these values. You also guard the definition with EIGEN_INCLUDE_ARRAY_BIT_SHIFT, so I guess you're not that happy with them either. Perhaps it's better to use .bitShiftLeft() or something like that? On the other hand, operator& and operator| and operator^ seem fine to me. ::: Eigen/src/plugins/ArrayCwiseBinaryOps.h @@ +181,5 @@ > +#define EIGEN_MAKE_SCALAR_CWISE_BINARY_BITOP(OP,FUNCTOR) \ > +template<typename OtherDerived> \ > + inline const CwiseBinaryOp<FUNCTOR<Scalar>, const Derived, const OtherDerived> \ > + operator OP(const EIGEN_CURRENT_STORAGE_BASE_CLASS<OtherDerived> &other) const \ > + { return CwiseBinaryOp<FUNCTOR<Scalar>, const Derived, const OtherDerived>(derived(),other.derived()); } There is a EIGEN_MAKE_CWISE_BINARY_OP macro in Macros.h which does something very similar to the above macro. Is it possible to use that instead? ::: Eigen/src/plugins/ArrayCwiseUnaryOps.h @@ +202,5 @@ > > +#define EIGEN_MAKE_SCALAR_CWISE_UNARY_BITOP(OP,FUNCTOR) \ > + inline const CwiseUnaryOp<FUNCTOR<Scalar>, const Derived> \ > + operator OP(const Scalar& scalar) const { \ > + return CwiseUnaryOp<FUNCTOR<Scalar>, const Derived>(derived(), FUNCTOR<Scalar>(scalar)); } Bug 402 proposes the introduction of a EIGEN_MAKE_CWISE_UNARY_OP macro. Would that be helpful here? ::: test/array_bit_ops.cpp @@ +22,5 @@ > +// License and a copy of the GNU General Public License along with > +// Eigen. If not, see <http://www.gnu.org/licenses/>. > + > +#define EIGEN2_SUPPORT > +#define EIGEN_NO_STATIC_ASSERT Why do you need the two #define's above here? @@ +36,5 @@ > +#endif > + > +#ifdef max > +#undef max > +#endif Why do you need to undef the min/max macros?
I think these operators will be very useful, especially, when vectorized. Further operators which should be defined are |=, &=, ^= and ~. And it might be useful to directly allow these operators on any POD type, maybe also a POD type and a boolean type, where the boolean is automatically interpreted as all 1 or all 0 (for true or false, resp.) Or, maybe it would be useful to define types such as internal::boolean<float>, internal::boolean<double>, etc which directly reflect the result of a corresponding comparison operation, and can then efficiently be used for select() operations involving these types. Arbitrary example: ArrayXf A, B; (A>B ^ A>=0.0f).select(B, A);
Shifting operator<< collides with inputting operator<<, other operators are fine. Perhaps we have to shift with <<= and >>= or member functions for symmetry.
-- GitLab Migration Automatic Message -- This bug has been migrated to gitlab.com's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.com/libeigen/eigen/issues/405.