This bugzilla service is closed. All entries have been migrated to https://gitlab.com/libeigen/eigen

Bug 1257

Summary: Support for custom scalar types with expression templates in numext
Product: Eigen Reporter: Gael Guennebaud <gael.guennebaud>
Component: Core - generalAssignee: Nobody <eigen.nobody>
Status: NEW ---    
Severity: Feature Request CC: chtz, gael.guennebaud, jacob.benoit.1, taylor
Priority: Normal    
Version: 3.3 (current stable)   
Hardware: All   
OS: All   
Whiteboard:
Attachments:
Description Flags
proof of concept for the c++14 auto approach. none

Description Gael Guennebaud 2016-07-20 16:40:15 UTC
Created attachment 717 [details]
proof of concept for the c++14 auto approach.

Currently, our numext wrappers/helpers does not play well with scalar types implementing expression templates. A typical exemple is boost::multiprecision that you can try by modifying et_off to et_on in test/boostmultiprec.cpp. The problem is in calls such as:

Scalar x;
numext::sqrt(abs(x))
numext::sqrt(2*x)

because the prototype of numext::sqrt is:

template<typename T> T sqrt(const T&);

and in the previous example abs(x) or 2*x return an expression.

For Eigen's types and some numext functions (like abs), we workaround the issue with some complicated mechanism to specialize the return type for Eigen's type. But this cannot scale to arbitrary scalar types.

I see tow solutions:

1 - explicitely tell the desired scalar type to any calls to numext::foo, e.g., the above example would become:

  numext::sqrt<Scalar>(2*x);

this disabling expression template also for Eigen's Array/Matrix as scalar type.

2 - enable support for ET for C++14 only by defining the return type of all numext method with 'auto'. See the attached patch for a proof of concept. This approach is not perfect yet. For instance, we cannot fully apply it to maxi/mini for which both arguments must have the same type to make sure we can call the std:: versions.
Comment 1 Gael Guennebaud 2016-07-21 12:33:00 UTC
nevermind, since expression template at scalar level are disabled at the Array/Matrix level, I don't really see why we should bother too much to preserve it at the scalar level, and so solution 1 is probably good enough.
Comment 2 Nobody 2019-12-04 16:00:29 UTC
-- 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/1257.