Hi,
> We actually need two sets of files: One for dumping the benchmark
> results, one for holding the 'best' parameter configuration. For
> dumping results, we probably want something more lightweight than XML:
> - JSON
> - Just CSV files with a metadata section, e.g.
> #
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 gi
Hi Karl,
Karl Rupp 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
Hi Toby,
> 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
>
Hi Karl,
Karl Rupp writes:
> Hmm, NumPy probably won't win a user API consistency award for this
> choice ;-) As you say, in such case I opt for using the NumPy matrix
> convention, particularly as the PyViennaCL object is also of type Matrix().
Right :)
> Coming back to the original question
Hi Toby,
> At the moment, I have the following semantics for *:
>
>Matrix * Matrix -> Matrix (matrix product)
>Matrix * Vector -> Vector (matrix product)
>Matrix * Scalar -> Matrix (scalar product)
>
>Vector * Vector -> Matrix (outer product)
>Vector * Scalar -> Vector (scalar
