Generate ufuncs for frexp and ldexp #4852
Conversation
|
The Python 3.x builds are failing. |
|
Yes. That's what I get for rushing and then not testing python 3. On Wednesday, July 9, 2014, Ralf Gommers [email protected] wrote:
|
|
Fixed. |
| @@ -343,6 +343,7 @@ double npy_log2(double x) | |||
| * asinh, acosh, atanh | |||
| * | |||
| * hypot, atan2, pow, fmod, modf | |||
| * ldexp, frexp | |||
| * | |||
| * We assume the above are always available in their double versions. | |||
There was a problem hiding this comment.
Is this a good assumption for us? It didn't used to be, but admittedly, that was a long time ago.
There was a problem hiding this comment.
Well, I suppose I don't really know. I know linux and windows have them both and I'd assume apple does too. Anything beyond that I can't say. Both are part of C89 FWIW. I suppose if we'd like I could add a implementation to npymath.
There was a problem hiding this comment.
Just to follow up here, python uses both of these unconditionally. We're fine.
|
Looks generally good to me, but have some questions. |
|
Oh, and if you want to add some documentation about the workings of the code generator, that would be welcome also. |
|
Let's give it a shot, so merging, thanks. Because you have been working on the code generator recently, it would be helpful if you could document it. I find that every time I deal with it I need to work through the code again to see just what is does. |
Generate ufuncs for frexp and ldexp
|
Thanks! |
|
this PR seems to cause build failures with MSVC, unresolved external symbol _ldexp and _frexp |
|
Not unexpected ;) They are in msvc 2008, I checked before merging, but we may need to do something more to use them, flags perhaps, or link some library. Are you using gcc or msvc? |
|
Looking at this again, the only other changes I made regarding these functions in #3010 was to delete a few lines in numpy/core/src/private/npy_config.h (see be42cae) These changes did build with MSVC 2008 when I was working on #3010. Unfortunately I no longer have access to a windows machine to test things. |
|
removing those lines seems to fix the build for me, but I'm don't know what now happens with frexpl/ldexpl but the testsuite succeeds |
|
Hmm, it seems that those lines should be OK since on Windows long double is double. OTOH, I think mingw does implement true long doubles. There may be another problem with the long double configuration somewhere. |
|
I meet build failure in VS2010+Win8.1. Because in math.h, ldexpl is macro(math.h Line 282): #define ldexpl(x,y) ((long double)ldexp((double)(x), (y)))*But the commit undef it! |
The functions are macros in msvc which we undefine and redeclare in npy_math. Since we now generate the ldexpl and frexpl ufuncs in numpygh-4852 this was broken by the extra logic for them in npy_config.h
Note previously used location for releases on SourceForge is no longer supported (latest tarball v1.11.2 available there is dated 2016-10-04) so as other distros (see, Fedora http://pkgs.fedoraproject.org/cgit/rpms/numpy.git/tree/numpy.spec?id=7013948f8ba073c69a91a545f0a0898cb62652fa#n22) we get release tarball directly from GitHub. Also note 0001-no-fenv-on-uclibc.patch was rebased on v1.13.1 and 0002-Don-t-blindly-enable-frexpl-and-ldexpl-for-uClibc.patch was removed completely as corresponding code got nuked with numpy/numpy#4852. I'm not really sure if something similar to Arnout's patch is still required so it would be good if somebody more knowledgeable checks that. Signed-off-by: Alexey Brodkin <[email protected]> Cc: Rahul Bedarkar <[email protected]> Cc: Gwenhael Goavec-Merou <[email protected]> Cc: Arnout Vandecappelle <[email protected]> Cc: Peter Korsgaard <[email protected]>
Note previously used location for releases on SourceForge is no longer supported (latest tarball v1.11.2 available there is dated 2016-10-04) so as other distros (see, Fedora http://pkgs.fedoraproject.org/cgit/rpms/numpy.git/tree/numpy.spec?id=7013948f8ba073c69a91a545f0a0898cb62652fa#n22) we get release tarball directly from GitHub. Also note 0001-no-fenv-on-uclibc.patch was rebased on v1.13.1. 0002-Don-t-blindly-enable-frexpl-and-ldexpl-for-uClibc.patch is no longer needed. Since numpy/numpy#4852, there is a wrapper for frexpl and ldexpl like for the other math functions. Signed-off-by: Alexey Brodkin <[email protected]> Cc: Rahul Bedarkar <[email protected]> Cc: Gwenhael Goavec-Merou <[email protected]> Cc: Arnout Vandecappelle <[email protected]> Cc: Peter Korsgaard <[email protected]> Reviewed-by: Arnout Vandecappelle (Essensium/Mind) <[email protected]> [Arnout: improve explanation of 0002-Don-t-blindly-enable-frexpl-and-ldexpl-for-uClibc.patch] Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <[email protected]>
No description provided.