Could be a problem with operator[] quirks in general (see below). There's always at least one more level of indirection for multi-dimensional (>=2D) arrays, compilers have finite optimization depth, so perhaps not everything is optimized. Someone has also noted that multi_array gets better depends on whether you use col-major or row-major order.There's plenty of non-performance reasons to use operator() in general (switching between row-major and column-major orders, switching from dense to sparse data -- all with the same interface, the client code doesn't have to worry), so I didn't worry that much about operator[] since I don't think it should be used for multi-dimensional data / tensors at all :-)http://www.parashift.com/c++-faq-lite/o ... -13.12"The array-of-array solution obviously works, but it is less flexible than the operator() approach. Specifically, there are easy performance tuning tricks that can be done with the operator() approach that are more difficult in the [][] approach, and therefore the [][] approach is more likely to lead to bad performance, at least in some cases.For example, the easiest way to implement the [][] approach is to use a physical layout of the matrix as a dense matrix that is stored in row-major form (or is it column-major; I can't ever remember). In contrast, the operator() approach totally hides the physical layout of the matrix, and that can lead to better performance in some cases. "

QuoteSomeone has also noted that multi_array gets better depends on whether you use col-major or row-major order.C is rm, Fortran is cm. A hunch is [] is creating copies???

Cuch and C++ is ag (anything goes) ;] depending on how the operator() is implemented -- which is a good thing.Configurability is a plus for interoperability (w/ FORTRAN code, for instance) or when some of your algos inherently depend on a given storage order already:http://eigen.tuxfamily.org/api/TopicSto ... htmloutrun, as you can see in the posts, "Collection of indices, operator(), () ; boost::multi_array" performed better than "C array notation, operator[], [][] ; boost::multi_array" (which for 3D is completely unacceptable, IMHO, see the benchmark results), but still not as good as "double[] // offset calculation".

QuoteOriginally posted by: outrunoffset = i + A*j + B*kwith A and B either compile time or runtime constants. I guess constexpr would be ideal here for all of the above (i# and N# in my notation, see below)?For non-C++11 compilers perhaps we could deal with it similarly to ">Boost.Chrono:http://www.boost.org/doc/libs/release/b ... nfig.hpp// scroll down until you see "// define constexpr related macros ------------------------------//"I suppose your "i + A*j + B*k" corresponds to mine "(i0 * N1 * N2) + (i1 * N2) + i2" ?// I use "i#" for index # and "N#" for Number of elements in # dimension -- easy to remember and no guessing

outrun, Looks interesting!BTW, since you have compile-time integer traits for offset_ ... stride_, did you consider using something similar for stride_type? So, something along the lines of typedef stride_<1> stride_type -- perhaps that would allow for greater flexibility for compile-time queries w.r.t. stride-types?BTW', just a note -- natively (in C++11) constexpr is not a macro but a new keyword that allows for easy compile-time programming, see:http://kaizer.se/wiki/log/post/C++_constexpr/ // checking substring containment at compile time.http://kaizer.se/wiki/log/post/C++_constexpr_foldr/ // I think this one is pretty cool -- foldr (right fold) illustrated with summation, minimization, zero-containment-test algorithms over initializer-lists, all at compile-time! :-)The macro stuff I referred to was merely a fall back for older compilers, not the way it-should-be-done.

So far I like the generic bindings, one concern is that a container and any of its advantages is reduced to a simple C array. This restriction is fine for initial versions, but needs to be addressed in the future.QuoteMy bindings start to look a lot like boost::multi_array_refIn my other thread, containers that allow external memory mean that a user's container can be transformed into qfcl internal's format with no copying.Quote have seen that multiarray [][][] is very inefficientI have looked at the muliarray internals, and it does not look like any rewrite or major updates have happened in many years. some of the techniques performed look to ensure compatibility over speed.Quote=================================================RFC=================================================1.1) get the dimensionality of the container: vector = 1, matrix = 2, etc.1.2) dimension sizes, the number of elements along a dimension.1.3) a way for element acces via (i,j,k,..) or via [ i][j][k].. doesn;'t matter as long as it gets formalized1.4) base either base 0 or base 1 indicesI really like outrun's TensorIndex interface. It is lightweight, generic, and fast. In fact, I had considered lifting a version of that code for some of the tables for computing general finite differences. Now, I am planning on the matrix_interface<T> instead since all I need is 2-D.Cuchulainn has said this already, but an arbitrary bas index would be helpful. Finite difference or PDE grids can become more readable with this ability.Otherwise, these requirements look to be a good start. Right now, I am not sure performance or fancy features matter. We need a consistent, agreed upon interface to building algorithms.

Question: will the second option also be possible: