The following forum entry make me though about the possibility to evaluate multiple expressions at once. By overloading DenseBase::operator,(DenseBase<Other>&), a possible API could be:
A,B = expression1, expression2;
If A and B appears to be compatible (same size, same alignement, etc.), then there evaluation could be merged in a single loop reducing cache misses if expression1 and expression2 access to same entries.
That sounds interesting indeed.
With that we could also provide mechanisms to write functions which return multiple expression, similar to Matlab's [Q,R]=qr(A) syntax.
I guess, we'd either need assignments return expressions as well (Bug 110), or we'll need to write either
(A,B) = expr1, expr2;
A,B = (expr1, expr2);
or a combination of all of them, to make this work.
I make this block 3.4, but we can postpone it to any later release if this turns out to be too complicated.
Could we simply rely on std::tie for implementing this in 3.4?
Unfortunately, std::tie would lose C++03 compatibility. But I agree that this would be a consistent syntax, otherwise.
Perhaps, we can simply implement Eigen::tie(...)?
I think we need our own tie/tuple anyway because we want our own implementation of operator= for such tuple...
Will be also useful to implement minmax, vectorwise-minmax, sincos...
Following the example given in bug 1680,
> StateSines = yi.array().sin();
> StateCosines = yi.array().cos();
It could be something like:
tie(S,C) = tie(yi.array().sin(), yi.array().cos());
tie(S,C) = vi.array().sincos();
guard with EIGEN_HAS_CPP17 and maybe add constexpr ;)
The goal is rather to fuse the evaluation loops to save on both computation and memory accesses. So instead of generating something like:
s[i] = sin(v[i]);
c[i] = cos(v[i]);
we would generate:
[s[i],c[i]] = sincos(v[i]);
My post was more about the syntax then the actual sincos implementation. Compilers can optimize it given the correct flags. But I was yet unable to get the calls to sincos in my program (might have to add .eval() to my code)
(increase size to 16 and gcc won't use sincos anymore)
-- 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/984.