This bugzilla service is closed. All entries have been migrated to
Bug 405 - Patch to add cwise bit operators to Array
Summary: Patch to add cwise bit operators to Array
Status: NEW
Alias: None
Product: Eigen
Classification: Unclassified
Component: Core - expression templates (show other bugs)
Version: 3.0
Hardware: All All
: Normal Unknown
Assignee: Nobody
Depends on:
Reported: 2012-01-13 14:17 UTC by John Roll
Modified: 2019-12-04 11:23 UTC (History)
4 users (show)

hg exported patch. (6.25 KB, patch)
2012-01-13 14:17 UTC, John Roll
no flags Details | Diff
hg exported patch w/test cases. (9.67 KB, patch)
2012-01-13 23:00 UTC, John Roll
no flags Details | Diff

Description John Roll 2012-01-13 14:17:15 UTC
Created attachment 247 [details]
hg exported patch.

May fix complaint in [272]?
Comment 1 John Roll 2012-01-13 15:36:16 UTC
It seems that the patch is missing the test case code.  I'll add this file over the weekend.

Comment 2 John Roll 2012-01-13 23:00:16 UTC
Created attachment 248 [details]
hg exported patch w/test cases.

Updated patch
Comment 3 Jitse Niesen 2012-01-22 18:45:05 UTC
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 @@
> +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 @@
> +  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 <>.
> +
> +#define EIGEN2_SUPPORT

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?
Comment 4 Christoph Hertzberg 2013-08-19 12:38:05 UTC
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);
Comment 5 Chen-Pang He 2017-07-24 08:07:09 UTC
Shifting operator<< collides with inputting operator<<, other operators are fine.  Perhaps we have to shift with <<= and >>= or member functions for symmetry.
Comment 6 Nobody 2019-12-04 11:23:47 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to'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:

Note You need to log in before you can comment on or make changes to this bug.