Hi Karl, Karl Rupp <r...@iue.tuwien.ac.at> writes: > I suggest to do the same for pyViennaCL: Follow conventions. Now, > conventions in the Python ecosystems are different from those in the C++ > world, so I don't think we should apply the reasoning from C++ to > Python. So, despite the issues with the * operator, I suggest to make it > compatible with NumPy. If a user writes > x = y * z > then I consider it beneficial if the semantics for NumPy and ViennaCL > are the same. Why should it be different? If > A = B * C > leads to elementwise products in NumPy, but matrix-matrix > multiplications in pyViennaCL, this will certainly cause confusion for > users. So, even though NumPy's handling of operator* may be > inconsistent, I think it's still worth keeping the same syntax where > possible.
The main difficulty with following the conventions is that it's not clear which is the convention to pick. NumPy provides both a matrix() class and a ndarray() class -- the former has semantics closer to matrix algebra, whilst the latter is designed to be closer to having more generalised tensor semantics; there is no vector primitive in NumPy. The NumPy matrix class has matrix product semantics for the * operator, and I think sticking with that shouldn't cause confusion, because in (py)ViennaCL, one knows what rank one's object is: you create a Matrix() object, and then follow the numpy matrix() convention -- not the ndarray() convention; if you have a rank-n tensor ndarray instance, then you'd expect different semantics from an explicitly rank-2 Matrix instance. I think that, because the different types keep the semantics clear, and there is a precedent in numpy.matrix(), it should be OK to stick to the matrix product for *. In a NumPy guide for MatLab users, the authors say, "You can use array for the bulk of your code, and switch over to matrix in the sections where you have nitty-gritty linear algebra with lots of matrix-matrix multiplications"[1]. I think that's probably a reasonable expectation for pyViennaCL users, too. [1] http://wiki.scipy.org/NumPy_for_Matlab_Users Best, Toby ------------------------------------------------------------------------------ Get your SQL database under version control now! Version control is standard for application code, but databases havent caught up. So what steps can you take to put your SQL databases under version control? Why should you start doing it? Read more to find out. http://pubads.g.doubleclick.net/gampad/clk?id=49501711&iu=/4140/ostg.clktrk _______________________________________________ ViennaCL-devel mailing list ViennaCL-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/viennacl-devel