Hi Toby, >> * Found the PyViennaCL documentation, but it was *not* installed >> automatically, but listed as 'suggested' package. I think this can be >> addressed in the installation instructions and does not require a change >> in behavior. > Sure, I only listed it as suggested because the HTML docs are the same > as what you get if you do "import pyviennacl; help(pyviennacl)" in the > interpreter, which I expect people to do.
Makes sense :-) I expect people will use (and find) an online documentation anyway... >> * Okay, so let's try to print individual elements of A and B: >> A(1,1); # error! >> A.item(1,1); # error! >> A[1,1]; # returns pyviennacl.pycore.HostScalar information >> print(A[1,1]); # works! >> Okay, this was a bit lengthy, we should have some more 'newbie >> information' in the docs :-) > > Hmm.. I think I might set it so that doing 'A[1,1]' at the interpreter > prompt prints the object, rather than the class info; but see below for > more about this. Also be aware that PyViennaCL supports ranges and > slices :) numpy also just prints the element value, so that would be consistent if it's technically feasible without interfering with the underlying expression tree... >> * Let's assign some elements: >> A[1,1].assign(2.0); # error: Cannot assign to HostScalar >> A[1,1] = 2.0; # same >> Here I searched the docs and found that it's not possible to assign >> stuff directly. Okay, so I created a numpy array (which I had to look up >> how to do that, of course ;-) ) and got: >> Drow = numpy.array([1, 2, 3, 4, 5]); > > For convenience, the numpy.array function is aliased in PyViennaCL as > pyviennacl.array. Also, you can do this to be clear about the 'dtype': > > >>> Drow = p.array([1, 2, 3, 4, 5], dtype=p.float64) > > (which converts the integers to the float64 (double) type) Ah, makes sense :-) >> D = numpy.array([Drow, Drow, Drow, Drow, Drow]); >> C = B + A; # error! >> Type conversion tricked me, A became a matrix of integers. Here I see >> the motivation for allowing mixed precision operations in ViennaCL >> asap... Alright, so restart with >> Drow = numpy.array([1.0, 2.0, 3.0, 4.0, 5.0]); >> D = numpy.array([Drow, Drow, Drow, Drow, Drow]); >> C = B + A; > > Did you mean > > >>> C = D + A Yes. > > ? Because that works, too! (ie, you can add PyViennaCL and NumPy > matrices together, as long as they have compatible sizes and types) which is pretty nice. The downside is that it may introduce quite a bunch of performance regressions if not used with care, but well.. >> Okay, let's stop here for now. Summary: Great, simple operations just >> work nicely and it integrates well in the Python environment. What can >> be done to make the user experience even better? >> - Allow element-wise manipulation. Sure, this is terribly slow, but it >> helps a lot with prototyping, which is an important use case with >> Python. > > Mrrgh. OK :) :-) How tricky is this to implement? ViennaCL uses an entry_proxy object for this. >> - Provide a few 'first steps' tutorials with the documentation. If >> that's already there and I simply couldn't find it, make it more >> visible. This way more emphasis is on the 'get simple stuff going' >> rather than internals of the scheduler which people won't read through >> for a start. > > Yes, I should probably do this. In large part, I was relying on people > knowing NumPy and assuming that PyViennaCL would be similar -- but a few > such tutorials certainly wouldn't go amiss. The less expertise a package assumes from its users, the better and more useful it usually is :-) Python's success is the best evidence :-) >> - Think about numeric type conversions. If a numpy-array of numeric >> type T1 is assigned to a PyViennaCL matrix of type T2, should the >> PyViennaCL matrix change to T1? Maybe issue a warning? > > The thing is, in Python, you don't tend to create objects and then > assign values to them -- both happen at the same time, and the things > you manipulate are really just references. So if you create a Matrix A, > and then try to use the = operator to assign something else to it, you > just change the thing that A refers to (and if the old Matrix has no > other references, it is deleted). I think this is what is happening when > you talk about the PyViennaCL matrix "changing" :) Okay, then let's stick to the natural Python way of doing things. > In PyViennaCL, you can just about get around this, by doing something > like `A[:,:] = B`, but that at least forces you to be explicit about the > assignment. If you have A and B of different dtypes in this example, you > get a TypeError exception saying "Cannot assign across different > dtypes!". That should suffice as a remedy. > If you want to be very careful about the numeric types, you can wrap > every number you write in a dtype: > > >>> a = p.Matrix(5, 5, p.float32(0.5)) * p.float32(2.0) > >>> a.value > array([[ 1., 1., 1., 1., 1.], > [ 1., 1., 1., 1., 1.], > [ 1., 1., 1., 1., 1.], > [ 1., 1., 1., 1., 1.], > [ 1., 1., 1., 1., 1.]], dtype=float32) > > Also note that the way I recommend getting access to the values of > objects at the interpreter is by using the ".value" attribute, because > this does separate the container object A and whatever data A contains, > and because the expression-tree representation of a lot of PyViennaCL > stuff means that even if the object A contains matrix data, its type > might not be Matrix, but an expression Node subclass, like Add.. > > In any case, as I say, I could change this -- but I think it should be > easy to be aware of the slightly different semantics here, in case > debugging is needed. I suppose people always have the "type" keyword... I don't know how 'natural' it is for Python people to type >>> A and only get the information <pyviennacl.pycore.Matrix object at 0x1844410> instead of the values. With numpy I do get values, but maybe things are different in sympy, etc. If I want to get the type, type(A) is always available and more explicit. Either way, I think it's more important to have a consistent mechanism in the background for avoiding temporaries and other evil, so feel free to keep it as is if the change would result in troubles elsewhere. > This does remind me that there is one thing I ought to fix: > > >>> A = p.Matrix(10, 10, 0.5) > >>> B = p.Matrix(10, 10, 0.9) > >>> C = A + B > >>> D = p.Matrix(5, 5, 3.0) > >>> C[0:5,6:10] = D > Traceback (most recent call last): > File "<stdin>", line 1, in <module> > TypeError: 'Add' object does not support item assignment > >>> C[0:5, 6:10] > Traceback (most recent call last): > File "<stdin>", line 1, in <module> > TypeError: 'Add' object has no attribute '__getitem__' Shouldn't be too hard :-) Best regards and merry Christmas, Karli ------------------------------------------------------------------------------ Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk _______________________________________________ ViennaCL-devel mailing list ViennaCL-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/viennacl-devel
