Hello, For now, the generator treats diag(), row(), col(), etc. as so called "offset modifying operators", so that soe equivalences would be both legal and valid, and induce no memory overhead
diag(A + B) = diag(A) + diag(B) diag(diag(A)) = puts zeros everywhere in A except in its diagonal diag(row(i, A)) = puts the ith row of A in the diag of A The pitfall of this approach is that using ranges and strides on such items is impossible, and if diag, row, col, were to inherit from vector_base<>, then some functionalities would be lost. For now I can't think of any vital such functionality, but in the future one may arise as such. Hence my reluctance to implement diag(), row(), col() as vector_base instead of operators (plus the code bloat!)! On the other hand, changing the states of ranges and stride is not desirable, at all, either, excluding the fact that it would induce a huge API change that is not doable pre-2.0. So, I was thinking of adding "handling ranged/strided accesses to offset modifiers" on the TODO list of ViennaCL 2.x. Does anybody see any magical solution that could allow us to have it on, say, 1.7, without making diag, row and col actual objects? How about: binary_expression<vector, range, op_range> ? We could use it for diag, row, col only in v1.7, and integrate it in v2.0. Note that it would also allow, in ViennaCL 2.x, the concise use of y = range(x + z + w, range(a, b)); which is less verbose than declaring xrange, zrange and wrange on the stack. That being said, it is not a vital feature to support ranges/slices on offset modifiers. I'm merely pointing this out because it seems to reveal a slight design flaw in the way we handle ranges/strides for now (or the way I handle diag/row/col ;)) Philippe
------------------------------------------------------------------------------
_______________________________________________ ViennaCL-devel mailing list ViennaCL-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/viennacl-devel
