Hi, While trying to fix some issues on windows 64 bits related to the float format fixes, I encountered some problems (lack of some basic math functions, in particular isnan and co for the multiarray module). We already have the portable replacing code for those functions (umath_funcs_c99.inc.src), which is used for the umath module. For now, we can only reuse this implementation by direct inclusion. I think it would be better to have a separate library with those core math routines: - sharing by copying means more code, more compilation time. - it cannot be shared outside numpy core. For some code, we don't have a choice, but for math functions, I don't really see an argument for not sharing: having public, portable math functions sounds useful to me. The only requirement is that we would need to mangle the name, I think, to avoid clash with the C math library on the platforms who have the maths. Would there be any other drawback ? Would people be against this ? cheers, David
On Sun, Feb 15, 2009 at 01:48, David Cournapeau <david@ar.media.kyoto-u.ac.jp> wrote:
Would people be against this ?
Not I. -- Robert Kern "I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth." -- Umberto Eco
On Sun, Feb 15, 2009 at 5:09 PM, Robert Kern <robert.kern@gmail.com> wrote:
On Sun, Feb 15, 2009 at 01:48, David Cournapeau <david@ar.media.kyoto-u.ac.jp> wrote:
Would people be against this ?
Not I.
Ok, I have started this in the coremath branch - it solves the warning issues we got since the merge of formatting stuff. I tested it on Linux, windows (both mingw and VS - still need to test on Win64), so I think it is good to go in the trunk. The functions exported are in a separate header: http://projects.scipy.org/scipy/numpy/browser/branches/coremath/numpy/core/i... I did not put the complex functions there (nc_), but maybe they should be, I am not sure. cheers, David
Fri, 20 Feb 2009 00:16:42 +0900, David Cournapeau wrote: [clip]
Ok, I have started this in the coremath branch - it solves the warning issues we got since the merge of formatting stuff. I tested it on Linux, windows (both mingw and VS - still need to test on Win64), so I think it is good to go in the trunk. The functions exported are in a separate header:
http://projects.scipy.org/scipy/numpy/browser/branches/coremath/numpy/ core/include/numpy/npy_math.h
One question: doesn't this add one extra function call to all umath functions? Could we do '#define npy_XXX XXX' in the npy_math.h header when the appropriate platform-specified functions are available?
I did not put the complex functions there (nc_), but maybe they should be, I am not sure.
I think they should be. Then we could easily use C99 complex math functions on plaforms on which they are available (and so get the "correct" corner-case semantics for free on these platforms). Pauli
On Fri, Feb 20, 2009 at 12:28 AM, Pauli Virtanen <pav@iki.fi> wrote:
Fri, 20 Feb 2009 00:16:42 +0900, David Cournapeau wrote: [clip]
Ok, I have started this in the coremath branch - it solves the warning issues we got since the merge of formatting stuff. I tested it on Linux, windows (both mingw and VS - still need to test on Win64), so I think it is good to go in the trunk. The functions exported are in a separate header:
http://projects.scipy.org/scipy/numpy/browser/branches/coremath/numpy/ core/include/numpy/npy_math.h
One question: doesn't this add one extra function call to all umath functions? Could we do '#define npy_XXX XXX' in the npy_math.h header when the appropriate platform-specified functions are available?
I think it does add a cost. I thought about it, but I don't know whether this is significant or not. The problem of #define npy_XXX XXX is that the header needs to know whether the corresponding function is available - and we can't import HAVE_XXX symbols in npy_math.h. Another argument against the define is that in the future, we could load the actual implementation at runtime (SSE, etc...). If we use define, that's not possible. I don't know how to evaluate the cost of function call on those functions: I tried some naive benchmark, but with cache effects and all, I am not convinced I was measuring anything meaningful.
I think they should be. Then we could easily use C99 complex math functions on plaforms on which they are available (and so get the "correct" corner-case semantics for free on these platforms).
maybe we could change the names, then ? nc is not very clear IMHO (and since they were static up to now, we are free to change them I believe). cheers, David
On Fri, Feb 20, 2009 at 1:05 AM, David Cournapeau <cournape@gmail.com> wrote:
Another argument against the define is that in the future, we could load the actual implementation at runtime (SSE, etc...). If we use define, that's not possible.
Hm, that's actually a pretty stupid statement - we could certainly have an ifdef to conditionally use define or not. David
Fri, 20 Feb 2009 01:05:03 +0900, David Cournapeau wrote: [clip]
I think they should be. Then we could easily use C99 complex math functions on plaforms on which they are available (and so get the "correct" corner-case semantics for free on these platforms).
maybe we could change the names, then ? nc is not very clear IMHO (and since they were static up to now, we are free to change them I believe).
I think it would make sense to change them to follow C99 function names, with a npy_ prefix. -- Pauli Virtanen
On Fri, Feb 20, 2009 at 5:26 PM, Pauli Virtanen <pav@iki.fi> wrote:
Fri, 20 Feb 2009 01:05:03 +0900, David Cournapeau wrote: [clip]
I think they should be. Then we could easily use C99 complex math functions on plaforms on which they are available (and so get the "correct" corner-case semantics for free on these platforms).
maybe we could change the names, then ? nc is not very clear IMHO (and since they were static up to now, we are free to change them I believe).
I think it would make sense to change them to follow C99 function names, with a npy_ prefix.
The problem of complex functions is that they don't follow the C99 conventions at all. IN particular, they accept pointers instead of values. I don't know whether the rational for using pointers is still valid (it is mentioned that how to pass structure is compiler dependent - I would guess this is true mainly for fortran, I would expect the C ABI of every platform to fix those kind of issues ?) Using C99 names for functions with different prototypes may be confusing, cheers, David
On Mon, Feb 23, 2009 at 2:02 PM, David Cournapeau <cournape@gmail.com>wrote:
On Fri, Feb 20, 2009 at 5:26 PM, Pauli Virtanen <pav@iki.fi> wrote:
Fri, 20 Feb 2009 01:05:03 +0900, David Cournapeau wrote: [clip]
I think they should be. Then we could easily use C99 complex math functions on plaforms on which they are available (and so get the "correct" corner-case semantics for free on these platforms).
maybe we could change the names, then ? nc is not very clear IMHO (and since they were static up to now, we are free to change them I believe).
I think it would make sense to change them to follow C99 function names, with a npy_ prefix.
The problem of complex functions is that they don't follow the C99 conventions at all. IN particular, they accept pointers instead of values. I don't know whether the rational for using pointers is still valid (it is mentioned that how to pass structure is compiler
The usual rational is that it is more efficient to pass a pointer than to push two floats on the stack. It is also an easier way to return values, although recent versions of gcc do a good job of copying the return values where they need to go. I would stick with the pointers, although we could probably dispense with the structure and just use a pointer to the underlying type with the assumption that the real & imaginary parts are contiguous in memory. The ufuncs make that assumption in any case. Chuck
On Tue, Feb 24, 2009 at 7:01 AM, Charles R Harris <charlesr.harris@gmail.com> wrote:
On Mon, Feb 23, 2009 at 2:02 PM, David Cournapeau <cournape@gmail.com> wrote:
On Fri, Feb 20, 2009 at 5:26 PM, Pauli Virtanen <pav@iki.fi> wrote:
Fri, 20 Feb 2009 01:05:03 +0900, David Cournapeau wrote: [clip]
I think they should be. Then we could easily use C99 complex math functions on plaforms on which they are available (and so get the "correct" corner-case semantics for free on these platforms).
maybe we could change the names, then ? nc is not very clear IMHO (and since they were static up to now, we are free to change them I believe).
I think it would make sense to change them to follow C99 function names, with a npy_ prefix.
The problem of complex functions is that they don't follow the C99 conventions at all. IN particular, they accept pointers instead of values. I don't know whether the rational for using pointers is still valid (it is mentioned that how to pass structure is compiler
The usual rational is that it is more efficient to pass a pointer than to push two floats on the stack. It is also an easier way to return values, although recent versions of gcc do a good job of copying the return values where they need to go. I would stick with the pointers, although we could probably dispense with the structure and just use a pointer to the underlying type with the assumption that the real & imaginary parts are contiguous in memory. The ufuncs make that assumption in any case.
Ok, what about making the decision for complex functions later, and merging now the the real functions (the one with clear API) ? Having coremath in trunk would help me tracking down crashes on windows x64 (the trunk does not build right now because of some configuration problems which are not a concern anymore witht the coremath branch), cheers, David
On Wed, Feb 25, 2009 at 11:54 PM, David Cournapeau <cournape@gmail.com>wrote:
On Tue, Feb 24, 2009 at 7:01 AM, Charles R Harris <charlesr.harris@gmail.com> wrote:
On Mon, Feb 23, 2009 at 2:02 PM, David Cournapeau <cournape@gmail.com> wrote:
On Fri, Feb 20, 2009 at 5:26 PM, Pauli Virtanen <pav@iki.fi> wrote:
Fri, 20 Feb 2009 01:05:03 +0900, David Cournapeau wrote: [clip]
I think they should be. Then we could easily use C99 complex math functions on plaforms on which they are available (and so get the "correct" corner-case semantics for free on these platforms).
maybe we could change the names, then ? nc is not very clear IMHO
(and
since they were static up to now, we are free to change them I believe).
I think it would make sense to change them to follow C99 function names, with a npy_ prefix.
The problem of complex functions is that they don't follow the C99 conventions at all. IN particular, they accept pointers instead of values. I don't know whether the rational for using pointers is still valid (it is mentioned that how to pass structure is compiler
The usual rational is that it is more efficient to pass a pointer than to push two floats on the stack. It is also an easier way to return values, although recent versions of gcc do a good job of copying the return values where they need to go. I would stick with the pointers, although we could probably dispense with the structure and just use a pointer to the underlying type with the assumption that the real & imaginary parts are contiguous in memory. The ufuncs make that assumption in any case.
Ok, what about making the decision for complex functions later, and merging now the the real functions (the one with clear API) ? Having coremath in trunk would help me tracking down crashes on windows x64 (the trunk does not build right now because of some configuration problems which are not a concern anymore witht the coremath branch),
Sounds good, I don't think the complex functions are a pressing concern. But I suspect we should start looking forward to a code freeze in a month or so and getting the build working is a clear priority. Maybe we should start the release process? I have a short list of things I think I should finish up and now might be a good time to put together a list of things to do. I've been thinking a bit about the complex functions. It might be worth benchmarking a few to see how much it costs to pass full complex numbers back forth. If the functions were inlined the optimizer could probably do good things with the FPU registers, but how things will work when the functions are in a library is another question. And rewriting the functions will be a lot of work unless we can copy a bunch of them from someone else. Chuck
On Thu, Feb 26, 2009 at 4:32 PM, Charles R Harris <charlesr.harris@gmail.com> wrote:
Sounds good, I don't think the complex functions are a pressing concern. But I suspect we should start looking forward to a code freeze in a month or so and getting the build working is a clear priority.
The build is working more or less. Building with VS 2008 works (by works I mean build and run the testsuite with a couple of failures), but building mingw-w64 still does not (it builds, but the test suite crashes at several points - up to now, it was mostly bugs in the mingw-w64 tools, but I think some errors are ours now). Building with mingw-w64 is necessary IMO, because I don't see an easy way to build scipy wo a free fortran compiler, and gfortran is the only one I know on windows 64 (VS 2008 + gfortran breaks horribly on 64 bits ATM). Restricting numpy wo BLAS/LAPACK for windows 64 bits may be another option: in that case, the infrastructure can be considered ready. In any case, the windows 64 bits build would be very experimental. Building the 32 bits version with python 2.6 should work well, too - I am confident we can release binaries for 2.6 on windows and mac os X for 1.3, even if it is released in a short time.
Maybe we should start the release process? I have a short list of things I think I should finish up and now might be a good time to put together a list of things to do.
Yes, I was thinking about that too. There was a 1.3 thread a couple of weeks ago, we should summarize it, and set a timeline for 1.3 really soon. I can do it, unless you want do it it, David
On Thu, Feb 26, 2009 at 1:23 AM, David Cournapeau <cournape@gmail.com>wrote:
On Thu, Feb 26, 2009 at 4:32 PM, Charles R Harris <charlesr.harris@gmail.com> wrote:
Sounds good, I don't think the complex functions are a pressing concern. But I suspect we should start looking forward to a code freeze in a month or so and getting the build working is a clear priority.
The build is working more or less. Building with VS 2008 works (by works I mean build and run the testsuite with a couple of failures), but building mingw-w64 still does not (it builds, but the test suite crashes at several points - up to now, it was mostly bugs in the mingw-w64 tools, but I think some errors are ours now). Building with mingw-w64 is necessary IMO, because I don't see an easy way to build scipy wo a free fortran compiler, and gfortran is the only one I know on windows 64 (VS 2008 + gfortran breaks horribly on 64 bits ATM). Restricting numpy wo BLAS/LAPACK for windows 64 bits may be another option: in that case, the infrastructure can be considered ready. In any case, the windows 64 bits build would be very experimental.
Building the 32 bits version with python 2.6 should work well, too - I am confident we can release binaries for 2.6 on windows and mac os X for 1.3, even if it is released in a short time.
Maybe we should start the release process? I have a short list of things I think I should finish up and now might be a good time to put together a list of things to do.
Yes, I was thinking about that too. There was a 1.3 thread a couple of weeks ago, we should summarize it, and set a timeline for 1.3 really soon. I can do it, unless you want do it it,
Why don't you make a start. I can help go through the tickets this weekend to pick out the ones that need to get fixed up. Umm... come to think of it, I'll be out of town for a few days starting Sunday, but I'll do my best. Chuck
Pauli Virtanen <pav <at> iki.fi> writes: ...
One question: doesn't this add one extra function call to all umath functions? Could we do '#define npy_XXX XXX' in the npy_math.h header when the appropriate platform-specified functions are available?
There shouldn't be overhead on modern compilers for simple functions. On gcc use __inline__ should eliminate overhead (also, -O3 should automatically inline).
Tue, 24 Feb 2009 14:04:42 +0000, Neal Becker wrote:
Pauli Virtanen <pav <at> iki.fi> writes:
...
One question: doesn't this add one extra function call to all umath functions? Could we do '#define npy_XXX XXX' in the npy_math.h header when the appropriate platform-specified functions are available?
There shouldn't be overhead on modern compilers for simple functions. On gcc use __inline__ should eliminate overhead (also, -O3 should automatically inline).
Doesn't this require that the whole function body (not just the prototype) be included to the file using it? Or do current *linkers* do inlining? The core math library is compiled to a separate .o file, as the point is exactly to get rid of including c-files. -- Pauli Virtanen
On Tue, Feb 24, 2009 at 7:04 AM, Neal Becker <ndbecker2@gmail.com> wrote:
Pauli Virtanen <pav <at> iki.fi> writes:
...
One question: doesn't this add one extra function call to all umath functions? Could we do '#define npy_XXX XXX' in the npy_math.h header when the appropriate platform-specified functions are available?
There shouldn't be overhead on modern compilers for simple functions. On gcc use __inline__ should eliminate overhead (also, -O3 should automatically inline).
In order to inline, the function definition would need to be in the header and a library version would still be required for passing functions by address or in case the compiler decided *not* to inline. Chuck
On Wed, Feb 25, 2009 at 2:21 AM, Charles R Harris <charlesr.harris@gmail.com> wrote:
In order to inline, the function definition would need to be in the header and a library version would still be required for passing functions by address or in case the compiler decided *not* to inline.
I looked more into this while solving some nasty mingw FPU handling bugs on windows 64. I learnt one thing I did not know about C: you can define inline static functions in headers, and that's the approach follows for very short functions. For example, FPU status flag code in BSD is defined as follows: fenv.h: static __inline int feraiseexcept(int __excepts); ... fenv.c: int fereaiseexcept(int excepts); we could follow this, maybe - once we solve the inline problem (many compilers do not support it for C). Having optional, non inline is important IMHO, for future SSE or other dynamically loaded implementations (where inline is not an option). David
In fact, the __inline is not helpful. It's the static keyword that enables the compiler to inline the function if the function is small enough. As the static indicates that the function will not be seen from the outside, it can do this. Matthieu 2009/2/24 David Cournapeau <cournape@gmail.com>:
On Wed, Feb 25, 2009 at 2:21 AM, Charles R Harris <charlesr.harris@gmail.com> wrote:
In order to inline, the function definition would need to be in the header and a library version would still be required for passing functions by address or in case the compiler decided *not* to inline.
I looked more into this while solving some nasty mingw FPU handling bugs on windows 64. I learnt one thing I did not know about C: you can define inline static functions in headers, and that's the approach follows for very short functions. For example, FPU status flag code in BSD is defined as follows:
fenv.h:
static __inline int feraiseexcept(int __excepts); ...
fenv.c: int fereaiseexcept(int excepts);
we could follow this, maybe - once we solve the inline problem (many compilers do not support it for C). Having optional, non inline is important IMHO, for future SSE or other dynamically loaded implementations (where inline is not an option).
David _______________________________________________ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
-- Information System Engineer, Ph.D. Website: http://matthieu-brucher.developpez.com/ Blogs: http://matt.eifelle.com and http://blog.developpez.com/?blog=92 LinkedIn: http://www.linkedin.com/in/matthieubrucher
Matthieu Brucher wrote:
In fact, the __inline is not helpful. It's the static keyword that enables the compiler to inline the function if the function is small enough. As the static indicates that the function will not be seen from the outside, it can do this.
Depends what is meant by 'helpful'. My understanding is that gcc will both inline the function within the current module and supply an external copy if __inline__ is used.
Matthieu
2009/2/24 David Cournapeau <cournape@gmail.com>:
On Wed, Feb 25, 2009 at 2:21 AM, Charles R Harris <charlesr.harris@gmail.com> wrote:
In order to inline, the function definition would need to be in the header and a library version would still be required for passing functions by address or in case the compiler decided *not* to inline.
I looked more into this while solving some nasty mingw FPU handling bugs on windows 64. I learnt one thing I did not know about C: you can define inline static functions in headers, and that's the approach follows for very short functions. For example, FPU status flag code in BSD is defined as follows:
fenv.h:
static __inline int feraiseexcept(int __excepts); ...
fenv.c: int fereaiseexcept(int excepts);
we could follow this, maybe - once we solve the inline problem (many compilers do not support it for C). Having optional, non inline is important IMHO, for future SSE or other dynamically loaded implementations (where inline is not an option).
David _______________________________________________ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
The inline keyword is never an obligation to inline, it's only a proposal. And the compiler in fact doesn't care about it. When using an optimization mode, the compiler will inline the function if it is simple enough. It's its call. It will even be easier to do so if the static keyword is used, as it knows that it must not supply an external copy. Matthieu 2009/2/24 Neal Becker <ndbecker2@gmail.com>:
Matthieu Brucher wrote:
In fact, the __inline is not helpful. It's the static keyword that enables the compiler to inline the function if the function is small enough. As the static indicates that the function will not be seen from the outside, it can do this.
Depends what is meant by 'helpful'. My understanding is that gcc will both inline the function within the current module and supply an external copy if __inline__ is used.
Matthieu
2009/2/24 David Cournapeau <cournape@gmail.com>:
On Wed, Feb 25, 2009 at 2:21 AM, Charles R Harris <charlesr.harris@gmail.com> wrote:
In order to inline, the function definition would need to be in the header and a library version would still be required for passing functions by address or in case the compiler decided *not* to inline.
I looked more into this while solving some nasty mingw FPU handling bugs on windows 64. I learnt one thing I did not know about C: you can define inline static functions in headers, and that's the approach follows for very short functions. For example, FPU status flag code in BSD is defined as follows:
fenv.h:
static __inline int feraiseexcept(int __excepts); ...
fenv.c: int fereaiseexcept(int excepts);
we could follow this, maybe - once we solve the inline problem (many compilers do not support it for C). Having optional, non inline is important IMHO, for future SSE or other dynamically loaded implementations (where inline is not an option).
David _______________________________________________ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
_______________________________________________ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
-- Information System Engineer, Ph.D. Website: http://matthieu-brucher.developpez.com/ Blogs: http://matt.eifelle.com and http://blog.developpez.com/?blog=92 LinkedIn: http://www.linkedin.com/in/matthieubrucher
On Tue, Feb 24, 2009 at 11:09 AM, Matthieu Brucher < matthieu.brucher@gmail.com> wrote:
In fact, the __inline is not helpful. It's the static keyword that enables the compiler to inline the function if the function is small enough. As the static indicates that the function will not be seen from the outside, it can do this.
Good point. However, most of the ufuncs involving standard functions like sin, cos, etc. are implemented as generic loops that are passed a function pointer and for such functions the call overhead is probably not significant in the absence of intrinsic hardware implementations. The complex functions could probably use some inlining as they call other functions. That could implemented by using some local static functions in the library code that could be inlined when the library is compiled. I think that the first priority should be correctness and portability. Speed optimizations can come later. Chuck
On Wed, Feb 25, 2009 at 3:26 AM, Charles R Harris <charlesr.harris@gmail.com> wrote:
Good point. However, most of the ufuncs involving standard functions like sin, cos, etc. are implemented as generic loops that are passed a function pointer and for such functions the call overhead is probably not significant in the absence of intrinsic hardware implementations. The complex functions could probably use some inlining as they call other functions. That could implemented by using some local static functions in the library code that could be inlined when the library is compiled.
I think that the first priority should be correctness and portability. Speed optimizations can come later.
I agree. I can see plenty of advantages to force a function call - and I have not seen any clear estimation of the function call cost. If it is a burden, this can be improved later (AFAIK, inline is not a modification of the signature). David
(AFAIK, inline is not a
modification of the signature).
Indeed, even more so for C. Matthieu -- Information System Engineer, Ph.D. Website: http://matthieu-brucher.developpez.com/ Blogs: http://matt.eifelle.com and http://blog.developpez.com/?blog=92 LinkedIn: http://www.linkedin.com/in/matthieubrucher
On Fri, Feb 20, 2009 at 12:16 AM, David Cournapeau <cournape@gmail.com> wrote:
On Sun, Feb 15, 2009 at 5:09 PM, Robert Kern <robert.kern@gmail.com> wrote:
On Sun, Feb 15, 2009 at 01:48, David Cournapeau <david@ar.media.kyoto-u.ac.jp> wrote:
Would people be against this ?
Not I.
Ok, I have started this in the coremath branch - it solves the warning issues we got since the merge of formatting stuff. I tested it on Linux, windows (both mingw and VS - still need to test on Win64)
Surprisingly, it worked out of the box on win64 (with python 2.6). There are some errors, but totally unrelated to the changes. That alone is enough of an argument for inclusion IMO - those compiler crashes were driving me crazy, cheers, David
On Thu, Feb 19, 2009 at 9:32 AM, David Cournapeau <cournape@gmail.com>wrote:
On Fri, Feb 20, 2009 at 12:16 AM, David Cournapeau <cournape@gmail.com> wrote:
On Sun, Feb 15, 2009 at 5:09 PM, Robert Kern <robert.kern@gmail.com> wrote:
On Sun, Feb 15, 2009 at 01:48, David Cournapeau <david@ar.media.kyoto-u.ac.jp> wrote:
Would people be against this ?
Not I.
Ok, I have started this in the coremath branch - it solves the warning issues we got since the merge of formatting stuff. I tested it on Linux, windows (both mingw and VS - still need to test on Win64)
Surprisingly, it worked out of the box on win64 (with python 2.6). There are some errors, but totally unrelated to the changes. That alone is enough of an argument for inclusion IMO - those compiler crashes were driving me crazy,
I think this is a bit obfuscated: --- branches/coremath/numpy/core/code_generators/generate_umath.py 2009-02-19 11:45:30 UTC (rev 6417) +++ branches/coremath/numpy/core/code_generators/generate_umath.py 2009-02-19 11:46:09 UTC (rev 6418) @@ -37,7 +37,7 @@ self.out = self.type * nout assert len(self.out) == nout -_fdata_map = dict(f='%sf', d='%s', g='%sl', +_fdata_map = dict(f='npy_%sf', d='npy_%s', g='npy_%sl', F='nc_%sf', D='nc_%s', G='nc_%sl') def build_func_data(types, f): func_data = []--- branches/coremath/numpy/core/code_generators/generate_umath.py 2009-02-19 11:45:30 UTC (rev 6417) +++ branches/coremath/numpy/core/code_generators/generate_umath.py 2009-02-19 11:46:09 UTC (rev 6418) @@ -37,7 +37,7 @@ self.out = self.type * nout assert len(self.out) == nout -_fdata_map = dict(f='%sf', d='%s', g='%sl', +_fdata_map = dict(f='npy_%sf', d='npy_%s', g='npy_%sl', F='nc_%sf', D='nc_%s', G='nc_%sl') def build_func_data(types, f): func_data = [] I think it better to make the npy_* explicit in the TD constructor calls. That way folks don't have to dig through the code to discover where the magic npy came from. Chuck
On Thu, Feb 19, 2009 at 8:16 AM, David Cournapeau <cournape@gmail.com>wrote:
On Sun, Feb 15, 2009 at 5:09 PM, Robert Kern <robert.kern@gmail.com> wrote:
On Sun, Feb 15, 2009 at 01:48, David Cournapeau <david@ar.media.kyoto-u.ac.jp> wrote:
Would people be against this ?
Not I.
Ok, I have started this in the coremath branch - it solves the warning issues we got since the merge of formatting stuff. I tested it on Linux, windows (both mingw and VS - still need to test on Win64), so I think it is good to go in the trunk. The functions exported are in a separate header:
http://projects.scipy.org/scipy/numpy/browser/branches/coremath/numpy/core/i...
I did not put the complex functions there (nc_), but maybe they should be, I am not sure.
I'm thinking yes, we might want them in scalarmathmodule. Chuck
participants (7)
-
Charles R Harris -
David Cournapeau -
David Cournapeau -
Matthieu Brucher -
Neal Becker -
Pauli Virtanen -
Robert Kern