Hey again, I realize that these features are actually accessible by calling diag, row, col, on a matrix range/stride rather than a matrix.... it seems like the API is complete, then!
2014-08-09 4:52 GMT+02:00 Philippe Tillet <phil.til...@gmail.com>: > 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
