Hi Toby, a few comments inline below.
Toby St Clere Smithe <m...@tsmithe.net> writes: > Expose remaining ViennaCL mathematical API (Week 1 - 2) > ======================================================= > > + preconditioners > + in-place solvers > + QR factorisation > + structured matrices > + diag(), row(), column() > > + get scalar result type operations (norms, dot prod) working with > scheduler > + not clear whether the bug is in my code or ViennaCL here > + inner_prod with tie > + prod(A, B) where A is sparse and B is dense > > + implement tests along the way! > > > Features from SciPy / NumPy that would be useful (Week 3) > ========================================================= > > + SciPy / NumPy convenience functions > + Improved SciPy / NumPy integration > - convenience functions > - sparse matrix support > > + Need to look over where features provided are same, and whether API > differences are warranted > + dtype, result_type, norm, diag, etc > + make classes provide compatible public attributes? > + provide in-place /and/ copy functions .. > > + Convenience functions > + eg scipy[.sparse] style solver / eigenvalue / etc interface Are you sure that duplicating numpy/scipy is worthwhile? I'd focus on offering the functionality that they don't already offer. I had a 'make an UBlas-based numpy clone' project: http://git.tiker.net/pylinear.git It's only once you try to reimplement it that you start understanding how much functionality really is in numpy. From fancy indexing, to ufuncs, to... Duplicating it is hopeless and pointless, adding onto it--not so much. > + Allow operations on ndarrays > + just convert to matrix / vector as appropriate This is powerful, if you can do it without having to copy storage. One consideration here is also *returning* numpy arrays if the input consisted of them. > Platform support and integration > ================================ > > Multi-platform support (Week 6 - 7) > ----------------------------------- > > + enable CUDA, OpenMP back-ends > + abstract back-end specific features / options into back-end > specific submodules, which should be loaded at runtime > > + useful to specify the backend details on creation of a ViennaCL > object (eg matrix) > + for instance, say pyviennacl.Matrix(..., context = c) or suchlike > + what about copying between back-ends? > > + how to define 'back-end'? > := context? (could be OpenCL, or CUDA equiv.) > := device? platform? > > + throw an exception if attempting to do an operation across > back-ends? It's important that the backend (including device and CL command queue choice) be made explicit somehow. > + Want to take advantage of PyOpenCL's int_ptr to access ViennaCL > objects in other (Py)OpenCL code and vice versa. > > + need to get the underlying OpenCL pointers out of ViennaCL -- > and be able to pass them back in One thing to watch out for here is ownership semantics. If ViennaCL insists on owning storage, then you may be forced to copy to preserve correctness. > + where PyOpenCL is not available, provide compatible minimal > surrogate classes > + in this case, integration functionality is clearly unnecessary > + don't want to depend on too many external bits, but also want to > provide useful functionality! I see what you're trying to say here, but I'm not sure duplicating PyOpenCL is worthwhile. Since PyViennaCL (in with-CL mode) and PyOpenCL have the same dependencies and can be configured the same way, I'd perhaps rely on setuptools to automatcially build PyOpenCL as a dependency (again, only if CL mode is enabled). > + convert between Matrix and pyopencl.array.Array types? Yes, you'd definitely want to do that. The array types are quite flexible on who owns the storage (they're pure Python after all). > + "The functionality in the module pyopencl.elementwise contains > tools to help generate kernels that evaluate multi-stage > expressions on one or several operands in a single pass" > -- http://documen.tician.de/pyopencl/algorithm.html > + sounds familiar? This is what we do in ViennaCL! pyopencl.elementwise works by throwing a snippet of C at the API though. It's a slight overlap in functionality, but not necessarily bad. > Nice-to-have > ============ > > + PyPy support for even more acceleration! Long-ish-term, maybe cffi (as a common CPython/pypy C foreign function interface) is worth a look. A PyOpenCL branch exists that uses that: https://github.com/pyopencl/pyopencl/tree/cffi Andreas
pgp4vBSAJd_R0.pgp
Description: PGP signature
------------------------------------------------------------------------------ Subversion Kills Productivity. Get off Subversion & Make the Move to Perforce. With Perforce, you get hassle-free workflows. Merge that actually works. Faster operations. Version large binaries. Built-in WAN optimization and the freedom to use Git, Perforce or both. Make the move to Perforce. http://pubads.g.doubleclick.net/gampad/clk?id=122218951&iu=/4140/ostg.clktrk
_______________________________________________ ViennaCL-devel mailing list ViennaCL-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/viennacl-devel
