Yes, we need to ensure that.. Code generator can be made, which can create code for table of registered dtype during build time itself. Also at present there lot of duplicate code that attempts to work around these slow paths, simplification of that code is also required. On Thu, May 2, 2013 at 10:12 AM, David Cournapeau <cournape@gmail.com>wrote:
@Raul I will pull new version, and try to include that also. What is wrong with macros for inline function? Yes, time for ufunc is reduced to almost half, for lookup table, I am generating key from argument type and returning the appropriated value.[1]
@Chuck Yes I did some profiling with oprofiler for "python -m timeit -n 1000000 -s 'import numpy as np;x = np.asarray(1.0)' 'x+x'". see data sheet.[2]
As every time a ufunc is invoked, the code has to check every single data type possible (bool, int, double, etc) until if finds the best match for
On Thu, May 2, 2013 at 5:25 AM, Arink Verma <arinkverma@iitrpr.ac.in> wrote: the
data that the operation is being performed on. In scalar, we can send best match, from pre-populated table. At present the implementation is not well-structured and support only addition for int+int and float+float. [1]
You are pointing out something that may well be the main difficulty: the code there is messy, and we need to ensure that optimisations don't preclude later extensions (especially with regard to new dtype addition).
David _______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
-- Arink Computer Science and Engineering Indian Institute of Technology Ropar www.arinkverma.in