RFC: Multiple backends + speedy looping

[Stéfan van der Walt]

Hi Tony

On Wed, Mar 14, 2012 at 5:28 PM, Tony Yu <tsyu80 at gmail.com> wrote:
> From the looks of the implementation, it seems none of the current modules
> would need to be changed unless a backend was added. And even then, it looks
> simple to modify an existing function to add a backend. Does this sum it up:
>
>     * Add `@add_backends` to function with new (optional) backend
>     * register backend function using `backend.register` in the `__init__`
> file for the function
>     * Subclass tests from `BackendTester` (an additional decorator for test
> functions might be good, if possible)

That's right--the design is aimed to be minimally invasive.

> Stefan: Do you have an idea of what needs to be done to get this merged?
> After a quick look: 1) It needs to be moved from the scikits.image namespace
> to skimage, 2) there are questionable changes to "filter/edges.py" and
> "filter/tests/test_edges.py" in the PR, 3) implementation should be moved
> from "backend/__init__.py" to something like "backend/core.py" (or I guess
> we've been using the convention "backend/_backend.py").

> Also, I'm not crazy about dumping backend functions into a "backend"
> subdirectory for each module. Maybe they should go in a backend-specific
> subdirectory. So, for example, "filter/backend/edges_opencl.py" would move
> to "filter/opencl/edges.py".

You've identified the three core issues.  (1) is easy to do.  (2) -- I
believe we should rework or remove those examples.  (3)  I share your
sentiment--skimage.filter.opencl seems like a better place.

Thanks for the valuable comments!  The more I think about this, the
more I think that this can be a great way of experimentally
incorporating new and maturing technologies, such as numba.  Even if
we can just start by having the fastest convolution of all the
available packages--without giving up the advantages of high-level
description--I'd be very happy.

Stéfan