Iterators

[bassoy]

I am not sure if iterators need to be visible for the user of the library. Does a physicist or mathematician want to deal with iterators instead of indices?

[stefanseefeld]

I have yet to understand the exact differences between iterators and indices, but my experience tought me that while indices are convenient, they don't perform very well. Thus whenever a user needs to add a new algorithm involving iteration over an entire tensor, being able to use iterators may yield vastly better performance. (It might be useful to write a benchmark that does some whole-tensor computation, based on iterators vs indices, to compare performance.)

[bassoy]

I was thinking of users who only need built-in functions. Also there is a discussion comparing iterator-based approaches versus ranges discussion1 and discussion2. So maybe we could design multidimensional ranges instead of multidimensional iterators?

In case of new algorithm, pointers and iterators are definitely advantageous. Actually this is part of my dissertation and I have published and discussed runtime results of different implementations of entry-wise tensor operations in LNCS 10860. I'll link the paper as soon as it is online. So I think we can use my findigs here.

[stefanseefeld]

Very good ! So to come back to your original question: Are you wondering whether / how to expose iterators to users ? Perhaps we can frame the question as "how to extend ublas with custom algorithms ?".

[bassoy]

Yes. In other words, what API layer / data structure should provide iterators?

1. We could place begin() and end() functions within the Data data structure using the nomenclature of VSIPL++.
2. We could also offer overloaded free begin() and end() or even range() functions with which users could interact with std::transform like algorithms.