Can index annotation be somehow compile-time?

[shiozaki]

As long as it is specified by initialier_list of constexpr int, there must be a way in theory (In practice I do not know). If it would be very powerful for optimization... The following is the current 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)

[shiozaki]

Note that this is kind of related to #44.

[naokin]

I think this is basically not doable at compile time, unless annotation is defined by template parameter (not 100% sure). Even if it can be done by template, I guess a large number of instances of contract function w/ different annotation cases will be created, thus, compilation takes a very long time and executable size becomes large. One possible solutions is, if contraction is trivial, e.g. contract(a, {i,j,k}, b, {j,k,l}, c, {i,l}), you may use gemm(a, b, c) instead for performance.

On Tue, Jun 24, 2014 at 7:21 AM, Toru Shiozaki [email protected] wrote:

Note that this is kind of related to #44 https://github.com/BTAS/BTAS/issues/44.

— Reply to this email directly or view it on GitHub https://github.com/BTAS/BTAS/issues/46#issuecomment-46909968.

[shiozaki]

I think we need to think of how to make this interface robust. Typical bugs I have created in this few days are calling contract with wrong annotation (an overly simplified version is the following)

Tensor2<double> a, b, c;
contract(1.0, a, {0,1,2}, b, {2,3}, 0.0, c{0,3});

I believe this should be checked at compile time (yes I can throw at runtime, but it's not quite beautiful in terms of philosophy).

[evaleev]

I assume you don't mean the error due to the lack of comma between c and {0,3}. Validating contraction indices is doable at compile time. Checking matching dimension ranks is only runtime with the current Tensor.

On Wed, Jun 25, 2014 at 3:29 PM, Toru Shiozaki [email protected] wrote:

I think we need to think of how to make this interface robust. Typical bugs I have created in this few days is calling contract with wrong annotation (an overly simplified version is the following)

Tensor2 a, b, c; contract(1.0, a, {0,1,2}, b, {2,3}, 0.0, c{0,3});

I believe this should be checked at compile time (yes I can throw at runtime, but it's not quite beautiful in terms of philosophy).

— Reply to this email directly or view it on GitHub https://github.com/BTAS/BTAS/issues/46#issuecomment-47147161.

web: valeyev.net

[shiozaki]

This is related to adaption of C++14. In C++14 std::initializer_list<T>::begin and end are constexpr, which makes this check possible.

@evaleev of course (sorry for a typo)

[emstoudenmire]

There would still be a version that works for dynamic annotation lists, correct? In ITensor the contraction info is only known at runtime.

[shiozaki]

Yes, I think we need to support both. But the following check can be done in both cases?

static_assert(a.rank() == aA.size(), "annotation inconsistent);