Re: [eigen] Compile error with nested arrays in Eigen 3.3 |

[ Thread Index | Date Index | More lists.tuxfamily.org/eigen Archives ]

*To*: eigen <eigen@xxxxxxxxxxxxxxxxxxx>*Subject*: Re: [eigen] Compile error with nested arrays in Eigen 3.3*From*: Gael Guennebaud <gael.guennebaud@xxxxxxxxx>*Date*: Fri, 9 Jun 2017 17:25:25 +0200*Dkim-signature*: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=kED9ZFEzkV2WjPNx+RLTmUWO9mEVsCBVUOwiR66nynY=; b=X8jeUksctPzSvlO8KSJE/3jUdwuefcgfv/Ct2oSMYSmecHZD70cN5Snkflv6905k/Y zGhOvnFhObyHuBoiUqTtFSWFt5jURtUwuwNoURFjGX2jS5QcmWW7kFR/jvmLBq9orq3q +7a8apY5ZZ7KR0nlghPPT6TheZkskwfWQh8Yu3mbsbzRSiSyW0clCuMhCaelcpNaLSgb T9AjqaPO7DDyDSGOPO7pPQJRTaCa4eaVvY466tbOc5LYXmfyMhw85b2abhn5Z/Oqxp3m ARBs4mZaArKTZmdBzqCwovpRhOzLGdc29Hwyc2iy6dg6Fik2T3IscayOb/TL6mco+88/ R8CQ==

Hi,

sorry for extremely late reply. I guess you managed to workaround this issue on your side, but we still need to figure-out something on Eigen's side.

What happens is that this operation is ambiguous because it can be interpreted in three different ways:

(1) The one you probably expect: Array<Array3> + Array<Array3> -> Array<Array3>

(2) a + b is interpreted as the addition of b to each "scalar" of a, thus leading to a result of type Array< Array<Array3> >. This is the same operator instantiated for something like ArrayXf + float

(3) same as (2) but inverting the role of a and b.

Actually, the 2 and 3 options might be valid interpretations because it is perfectly fine to do: Array<Array3> + Array3 but in theory our type promotion rules should not allow that. What deeply happens is that, because the implicit ctor:

template<typename OtherDerived> Array(const EigenBase<OtherDerived> &other);

Array<Array3> and Array3 are seen as if they are convertible to each other wrt std::is_convertible. Of course, any attempt to actually convert a Array<Array3> to a Array3 will fail, and and an Array3f is not implicitly convertible to a Array<Array3>. So the remedy would to to disable this ctor when the underlying scalar types of this and OtherDerived are not compatible. Unfortunately, for ctor there is no other way than adding an ugly enable_if as a last parameter:

template<typename OtherDerived>

Array(const EigenBase<OtherDerived> &other,

typename internal::enable_if<internal::is_convertible<typename OtherDerived::Scalar,Scalar>::value,UGLYTYPE>::type = UGLYTYPE())

I cannot think about a better solution to really solve this issue. I introduced a UGLYTYPE (instead of using a classic void* to prevent unexpected calls to this ctor.

cheers,

gael

On Tue, Mar 14, 2017 at 10:45 PM, Kevin Wampler <kwampler@xxxxxxxxx> wrote:

I’ve encountered some cases involving some nested arrays where code that used to compile in Eigen 3.2 no longer compiles in 3.3, and I’m wondering if there’s something I’m doing wrong or if support for this was intentionally removed. Here’s an example:

Eigen::Array<Eigen::Array3d,

Eigen::Dynamic,1> a(7), b(7), c; for(int i = 0; i < 7; ++i) {

a[i] = Eigen::Array3d::Random();

b[i] = Eigen::Array3d::Random();

}

c = a + b; // this line no longer compiles in 3.3

The marked line causes a compiler error complaining that the + operator cannot be unambiguously resolved. It looks like there is a NumTraits specialization for Eigen::Array, so it *

seems* like this sort of operation is supposed work, but it’s admittedly a bit non-standard so perhaps there’s something I’m missing.

Obviously I could rewrite the above code to avoid nested arrays, but it would be convenient for me is there was a way to keep the nested arrays but fix the compiler error. Any suggestions?

**Messages sorted by:**[ date | thread ]- Prev by Date:
**RE: [eigen] ENigMA uses Eigen.** - Next by Date:
**[eigen] Bug in pow function** - Previous by thread:
**RE: [eigen] ENigMA uses Eigen.** - Next by thread:
**[eigen] Bug in pow function**

Mail converted by MHonArc 2.6.19+ | http://listengine.tuxfamily.org/ |