Re: [eigen] Interesting C++ standard proposal

I don't see the proposal as a way of guessing what the user wants but as a means of being able to impose the type auto resolves to on the user.

Regarding the debug capabilities and code cleanness, it's an ongoing discussion. In my opinion the variables should be properly named. As for debugging I am in the lucky position that VS shows me the exact type behind any variable, including auto declared ones.

In general, I don't see things becoming worse but quite the opposite. Eigen is a linear algebra library and in my opinion the regular user should never see nor know about the template expressions. They are an implementation detail which allows the generation of most optimal code but nothing the user should ever really get in touch with.

According to the proposal, your example becomes:

auto mat = A+B*(C-2*D).cwisePow(2);

explicit auto expr = (A+B*(C-2*D).cwisePow(2));

The general case would be implemented such that auto resolves to (expr).eval() for any _expression_ expr - totally natural in my opinion.

Regards,

Hauke

On Mon, Nov 11, 2013 at 10:17 PM, Gael Guennebaud <gael.guennebaud@xxxxxxxxx> wrote:

in my opinion changing the behavior of auto by guessing what the user want to have when writing auto is a bit far fetched. Codes that make use of the auto keyword are often more difficult to read and debug. This proposal will make thing even worse because it will be even more difficult to guess what is the actual type of an auto variable. Users should be educated to use the auto keyword only when writing the actual type explicitly is really difficult. An Eigen _expression_ is a typical case. Writing 'auto' when one want a MatrixXd is ridiculous. Anyway, once bug 99 is finalized the use of auto with Eigen will be much clearer:

auto xpr = A+B*(C-2*D).cwisePow(2);
auto mat = (A+B*(C-2*D).cwisePow(2)).eval();

xpr will be a pure abstract _expression_
mat will be an object with storage holding the result of the _expression_.

Good enough for me.

Having the possibility to disable auto for some given types would be nice through.

gael

On Mon, Nov 11, 2013 at 3:22 PM, Christoph Hertzberg <chtz@xxxxxxxxxxxxxxxxxxxxxxxx> wrote:

Hi,

(browsing through unanswered mails ...)

On 11.09.2013 09:00, Hauke Heibel wrote:

I just thought some of you might be interested in this proposal:
http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2013/n3748.pdf

Yes, that looks interesting, but as you said, even if this gets accepted it will take a long time until we can profit from it.
Until then, we must rely on Gael to implement the _expression_-evaluator and educate our users that storing _expression_ trees is often not the most efficient solution (but that depends on the _expression_ and how often it is used)..

E.g.
MatrixXd A, B, C, X, Y, Z;

auto A_plus_B = A+B; // usually ok (not always ...)
auto A_times_B= A*B; // in many cases (A*B).eval() is better

X = A_plus_B + C; // more efficient than evaluating A+B.
Y.noAlias() = C + A_times_B; // currently fails, but efficient later.

// fails at the moment and inefficient (product gets evaluated twice):
Z.noAlias() = A_times_B + A_times_B.transpose();

Christoph

--
----------------------------------------------
Dipl.-Inf., Dipl.-Math. Christoph Hertzberg
Cartesium 0.049
Universität Bremen
Enrique-Schmidt-Straße 5
28359 Bremen

Tel: +49 (421) 218-64252
----------------------------------------------