Hi, > Suppose we have vectors v1 and v2. Then, we have four options for the > semantics of "v1 * v2": > > 1) Element-wise product > 2) Dot product > 3) Outer product > 4) Leave undefined > > Most of the time, in the rest of PyViennaCL, I've chosen semantics for > the * operator that make sense given the context. For instance, for > matrices m1 and m2, "m1 * m2" is the matrix product (not element-wise). > > So, I don't want to choose option (1), even though NumPy does this in > places. NumPy is actually quite inconsistent: its "array" type is > elementwise for all operators (*, /, +, etc; providing matrix product > semantics for the "dot" method), but its "matrix" type has various > semantics -- / is elementwise, but * is not, being the matrix product. > > This leaves (2) to (4). It seems ViennaCL itself leaves the * operator > undefined, leaving the user to be explicit. I think I'm leaning towards > this choice, for consistency, and to minimise confusion. But then why > should I define the * operator for /any/ type? I think the answer is > that, when someone has m1 and m2, "m1 * m2" is an operation they will > want to be convenient -- more so than elementwise multiplication, or > either the inner or outer product of vectors. > > But I'm not sure, hence this post.
When it comes to user APIs, I'm a big supporter of staying with established conventions. Since the ViennaCL API was decided to be uBLAS-compatible whenever possible, the decisions with respect to treating the multiplication operator within C++ were immediate, i.e. use prod(). 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. Best regards, Karli ------------------------------------------------------------------------------ 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
