Hi Andy,
Sorry for the late reply.
On Tue, Oct 25, 2011 at 12:17 AM, Andreas Mueller
- Support for multiple computation back-ends
Would anyone like to comment on this issue?
Could you give an example on how you picture this? I think I get the general idea but I'm not sure how you would implement it. You want the user to provide some other computational backend that is somehow plugged into scikits-image, as far as i understand.
Also: Do you think the easy switching between the implementations is a good enough reason for the additional complexity?
I've learnt that we cannot satisfy all the people all of the time. Some people want interesting algorithms, other people want very fast execution times. Since we can't write code for all those use cases at the same time, I think our best option is to help them achieve their goal with minimum effort. So, all that this framework allows you to do is basically "outsource" skimage functions. For example, you can say: "Instead of calling sobel from skimage, use this sobel implementation I found in opencv" Usually, this will require you to write code that can only be run on an opencv system, but with the plugin system you can easily share that code with colleagues who do not have opencv installed: use_backend('my_opencv_routines') output = sobel(input) If the opencv backend is not found, the backend gracefully falls back to the NumPy / Cython implementation. Yes, the complexity opens some doors for weird things to happen. For example, if implementations (say, e.g., opencv vs. CUDA vs NumPy) return subtly different results, your script won't give the same result on all machines. To compensate, we've added utility functions to the test suite, so that you can do: @add_backends def mytest(): for b in backends: output = sobel(input, backend=b) [...check_output...]
Don't get me wrong, I'm not as opposed as it might sound, I'm just trying to figure the idea out ;)
All critical feedback is most welcome (and necessary)! Let's keep the discussion going. Cheers Stéfan