> >> Or do it get you completly wrong? Is your intention to make a plugin >> architecture in the sense of: copy some directory with libs and >> config >> in your site-packages and then your multiplications are much >> faster? I >> would consider such a framework a bit overengineered, since speedy >> calculations are a nice feature for every numpy user. > > You have to detect the presence of the library. If there are no such > framework, you have to compile the module again (and for scipy under > Windows, it is not simple). So developing a good plugin framework will > help people code fast libraries plugins if it is possible, there will > be only one module and not one for Intel/AMD/Atlas/CUDA/... thus less > bugs, ... Well Cuda might not be available everywhere, so a plugin architecture might provide usefull in this case (though i doubt that it would be easier than to just have some packagers responsible for offering python with this enabled to download). But Waveframe for example works readily on all I386 architecture out of the box and without any configuration. Given that there would be support for it in python, why would someone choose to disable it since it has no downsides? Why would you provide it as a plugin if you would ship it always?
Same thought, different argumentation: If i have a cuda card, i probably do not want to use it for every possible calculation. For example array((2))**2 would be faster in software (or even faster with framewave support) then cuda (because cudas bottleneck is the datatransfer to the graphicscard, which only makes it usefull for huge arrays). The plugin would therefore be micromanaged or must offer some on/off toggle functionality; it would therefore not replace existing calls. Conclusion: I would vote for libraries which only speed things up to be included in the release and I for one would prefer a numpy aware cude extension module for python instead of a plugin for numpy. Greetings, Holger _______________________________________________ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
