Hi Karl, (looks like I never did get around to this that next morning..!)
Karl Rupp <r...@iue.tuwien.ac.at> writes: > As long as you're a student, you're eligible to apply for GSoC. ;-) > However, I don't give any guarantees, your application will be treated > equally. You certainly have an advantage with respect to how things > work, but no other student should be excluded upfront. It would definitely be great to be able to finish what I've started! >> My list of features to complete in PyViennaCL (as separate from ViennaCL >> itself) is centered around interoperability and further integration with >> the ecosystem. For instance, I want to enable interaction with PyOpenCL >> and PyCUDA (as discussed before), which would entail providing access to >> the underlying memory buffers, contexts, programs, etc. I also need to >> add simple (for the user!) support for SciPy sparse matrix types. Then, >> with these two features I'd much more easily be able to work on better >> integration and competition with systems like Theano. > > Yep, that's definitely a nice-to-have! I was thinking about another nice-to-have feature. I'd quite like to make it possible (if it is in fact possible..) to play with prototyping implementations of other algorithms for ViennaCL in PyViennaCl using PyOpenCL and PyCUDA; for instance (just picking a recently discussed example) to implement using PyOpenCL a cl_program for sparse matrix multiplication, and be able to use the resultant buffer like any other PyViennaCL matrix object. I don't know if it would be worthwhile to hook into the generator or scheduler at this point. Just personally, I'd quite like this functionality, because I do find rapid development easier in Python than C++, and I would like to play with implementing matrix algorithms at some point in the future. > I'm still convinced that libviennacl is the better choice once it is > reasonably feature-complete. It will avoid quite a bunch of hassle when > dealing with a C++-ABI as well as Boost. Yes; I'll need to investigate this. At the moment, I quite enjoy the object-oriented nature of ViennaCL, and there are parts of PyViennaCL which are inelegantly not-OOP. So I'd probably want to think about which way is going to be most elegant overall. Presumably, the C++ API isn't going to disappear? > Fair enough. Python is just a too vibrant ecosystem, so we should > dedicate an appropriate amount of attention. Yes! Cheers, Toby ------------------------------------------------------------------------------ Android apps run on BlackBerry 10 Introducing the new BlackBerry 10.2.1 Runtime for Android apps. Now with support for Jelly Bean, Bluetooth, Mapview and more. Get your Android app in front of a whole new audience. Start now. http://pubads.g.doubleclick.net/gampad/clk?id=124407151&iu=/4140/ostg.clktrk _______________________________________________ ViennaCL-devel mailing list ViennaCL-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/viennacl-devel
