Complex conjugate of a tensor in btas::contract

[shiozaki]

What was the consensus on the complex conjugate? In other words do we allow the users to specify complex conjugation in the interface? As far as I see there is no such things in the generic interface.

[evaleev]

Don't see an issue with this.

[shiozaki]

I mean how do you specify whether or not to conjugate a tensor through the following interface?

193 template<
194    typename _T,
195    class _TensorA, class _TensorB, class _TensorC,
196    typename _UA, typename _UB, typename _UC,
197    class = typename std::enable_if<
198       is_tensor<_TensorA>::value &
199       is_tensor<_TensorB>::value &
200       is_tensor<_TensorC>::value &
201       std::is_same<typename _TensorA::value_type, typename _TensorB::value_type>::value &
202       std::is_same<typename _TensorA::value_type, typename _TensorC::value_type>::value
203    >::type
204 >
205 void contract(
206    const _T& alpha,
207    const _TensorA& A, std::initializer_list<_UA> aA,
208    const _TensorB& B, std::initializer_list<_UB> aB,
209    const _T& beta,
210          _TensorC& C, std::initializer_list<_UC> aC)

[evaleev]

Not sure what you are asking ... pass them as additional params to contract?

we don't have Tensor expressions (that's a big chunk of work ... e.g. see
Eigen or TiledArray), but if we did we could just have user pass
TensorExpression generated by Tensor::complex_conjugate(). Then contract
could figure out if it's possible to merge complex conjugation into the
contraction, or temp copy needs to be created.

On Mon, Jun 23, 2014 at 12:54 PM, Toru Shiozaki [email protected]
wrote:

I mean how do you specify whether or not to conjugate a tensor through the
following interface?

193 template<
194 typename _T,
195 class _TensorA, class _TensorB, class _TensorC,
196 typename _UA, typename _UB, typename _UC,
197 class = typename std::enable_if<
198 is_tensor<_TensorA>::value &
199 is_tensor<_TensorB>::value &
200 is_tensor<_TensorC>::value &
201 std::is_same<typename _TensorA::value_type, typename _TensorB::value_type>::value &
202 std::is_same<typename _TensorA::value_type, typename _TensorC::value_type>::value
203 >::type
204 >
205 void contract(
206 const _T& alpha,
207 const _TensorA& A, std::initializer_list<_UA> aA,
208 const _TensorB& B, std::initializer_list<_UB> aB,
209 const _T& beta,
210 _TensorC& C, std::initializer_list<_UC> aC)

—
Reply to this email directly or view it on GitHub
#45 (comment).

web: valeyev.net

[shiozaki]

Yes what I had in mind was those in Eigen etc. Easier and nasty way is to add params to contract. I am not aware of any discussions on this, hence opened the issue.

[shiozaki]

And this is performance critical.

[evaleev]

I have to think about TensorExpressions ... at some point there is no way
to avoid DAGs if we want to be expressive and/or concurrent. The big
question is how much we want to happen at compile time. I'm staring at
Eigen for design pointers. Also for design ideas related TensorBase.

On Mon, Jun 23, 2014 at 1:13 PM, Toru Shiozaki [email protected]
wrote:

And this is performance critical.

—
Reply to this email directly or view it on GitHub
#45 (comment).

web: valeyev.net

[gkc1000]

I think TensorExpressions should be something outside of our "standard". In the case of complex conjugation, passing as an argument seems fine. One can always build a more expressive layer on top of the base we are creating.