[Numpy-discussion] Recent umath changes
Charles R Harris
Wed Dec 17 12:40:37 CST 2008
On Tue, Dec 16, 2008 at 10:56 PM, David Cournapeau <
> Charles R Harris wrote:
> > On Tue, Dec 16, 2008 at 8:59 PM, David Cournapeau
> > <email@example.com <mailto:firstname.lastname@example.org>>
> > wrote:
> It does not work at the moment on windows at least :) But more
> essentially, I don't see why you declared those functions: can you
> explain me what was your intention, because I don't understand the
The declarations were for the SPARC. Originally I had them up in an ifdef up
top, but I got curious what different machines would do. They shouldn't
cause a problem unless something is pretty strange. The undefs I put where
they are for similar reasons, but there was a strong temptation to move them
into the if statement where they used to be. Let's say curiousity got the
best of me there. They shouldn't affect anything but macros and I didn't
want the function declarations do be interpreted as macros.
> > You are, of course, free to break these builds again. However, I
> > designated space at the top of the file for compiler/distro specific
> > defines, I think you should use them, there is a reason other folks do.
> The problem is two folds:
> - by declaring functions everywhere in the code, you are effectively
> spreading toolchain specific oddities in the whole source file. This is
> not good, IMHO: those should be detected at configuration stage, and
> dealt in the source code using those informations. That's how every
> autoconf project does it. If a function is actually a macro, this should
> be detected at configuration.
> - declarations are toolchain specific; it is actually worse, it even
> depends on the compiler flags. It is at least the case with MS
> compilers. So there is no way to guarantee that your declaration matches
> the math runtime one (the compiler crash reported is exactly caused by
Worth knowing ;) It works on the windows buildbot but that is running
python 2.4. Speaking of which, the BSD buildbot needs nose (I don't know
what happened to it), the windows box is showing the same old permissions
problem, and one of the SPARC buildbots just times out unless you build
during the right time of day. We are just hobbling along at the moment.
> > The macro undef could be moved but I preferred to generate an error if
> > there was a conflict with the the standard c function prototypes.
> > We can't use inline code for these functions as they are passed to the
> > generic loops as function pointers.
> Yes, I believe this is another problem when declaring function: if we
> use say cosl, and cosl is an inline function in the runtime, by
> re-declaring it, you are telling the compiler that it is not inline
> anymore, so the compiler does not know anymore you can't take the
> address of cosl, unless it detects the mismatch between the runtime
> declaration and ours, and considers it as an error (I am not sure
> whether this is always an error with MS compilers; it may only be a
> warning on some versions - it is certainly not dealt in a gracious
> manner every time, since the linker crashes in some cases).
Sorry for the late reply, the network was down.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Numpy-discussion