summaryrefslogtreecommitdiff
path: root/numpy/core/src/npymath
Commit message (Collapse)AuthorAgeFilesLines
* ENH: Extend the functionlty of C++ type `np::Half`Sayed Adel2023-04-052-555/+238
| | | | | | | | | | - optimize float/double conversions on x86, requires for now raising up the baseline features to `f16c` at least during the build. - optimize float/double conversions on ppc64le, requires for now raising up the baseline features to `VSX3` at least during the build. - Brings `np::Half` to npymath
* ENH: Raise C++ standard to C++17Sayed Adel2023-04-041-1/+3
|
* MAINT: Move export for scipy arm64 helper into main moduleSebastian Berg2023-01-051-1/+8
| | | | | | | | | | | | | | | | | This is a follow up to gh-22679 which addressed gh-22673. The main thing is that we want the functions to be available after importing NumPy, so they need to be part of multiarray. However, `npymath` is a static library, so the symbols are not really exported there. The former PR did actually work in practice but this seems like it is technically the right place? For some reason, I had to add nextafter to be able to do: from scipy.spatial.distance import euclidean with the SciPy 1.9.3 wheels. SciPy test collection works with this for the 1.9.3 wheel, so this should be all the symbols hopefully.
* MAINT: restore npymath implementations needed for freebsdmattip2022-12-251-17/+441
|
* Merge pull request #18535 from prithvitewatia/Issue18378Matti Picus2022-12-021-20/+34
|\ | | | | BUG: Fix <complex 0>^{non-zero}
| * Update numpy/core/src/npymath/npy_math_complex.c.srcprithvitewatia2022-12-011-1/+1
| | | | | | Co-authored-by: Matti Picus <matti.picus@gmail.com>
| * Apply suggestions from code reviewprithvitewatia2022-06-171-23/+17
| | | | | | | | Co-authored-by: Matti Picus <matti.picus@gmail.com> Co-authored-by: Ivan Gonzalez <scratchmex@gmail.com>
| * rephrase 0^b commentMatti Picus2022-06-171-5/+6
| | | | | | Co-authored-by: Ivan Gonzalez <scratchmex@gmail.com>
| * add 754 to IEEE 754Matti Picus2022-06-171-1/+1
| | | | | | Co-authored-by: Ivan Gonzalez <scratchmex@gmail.com>
| * Fixed spacing and check num of warnings in testsPrithvi2022-06-171-3/+5
| |
| * Fixed 0 sign and added new testsPrithvi2022-06-171-21/+40
| |
| * Fixed style and warning capturePrithvi2022-06-171-7/+7
| |
| * Fixed Tests with pytest.warnsPrithvi2022-06-171-1/+5
| |
| * Fixed 0^non-zero as discussed in issue 18378Prithvi2022-06-171-21/+15
| |
* | MAINT: npymath cleanups for isnan, isinf, isinfinite, signbit, nextafter ↵Matti Picus2022-11-283-102/+0
| | | | | | | | | | | | | | | | | | (#22684) * make isnan, isinf, isfinite, signbit, nextafter aliases * fixes from review Co-authored-by: Sebastian Berg <sebastianb@nvidia.com>
* | BUILD: revert function() -> #define for 3 npymath functionsmattip2022-11-271-0/+23
| |
* | MAINT: replace `NPY_INLINE` with `inline`Ralf Gommers2022-11-251-10/+10
| | | | | | | | Closes gh-22100
* | Cleanup: Match arguments of isless()juztamau52022-11-071-1/+1
| | | | | | | | | | | | | | | | Error was: npy_math_internal.h.src:570:24: error: no matching function for call to 'isless(npy_float&, int)' 570 | if (isless(b, 0) != isless(mod, 0)) { | ^
* | MAINT: refactor mandatory npymath functions to #define macrosmattip2022-10-202-63/+2
| |
* | BUILD: move some never-blocked complex math functions to 'mandatory'mattip2022-09-271-444/+18
| |
* | TASK: rename macros (from review)mattip2022-08-211-9/+9
| |
* | BUILD: convert HAVE_ macros to BLOCK_, cleanupmattip2022-08-211-32/+63
| |
* | nextafter is mandatorymattip2022-08-212-412/+0
| |
* | restore atan2 implementation, clean up c99 mandatory functionsmattip2022-08-211-4/+96
| |
* | copysign is mandatory, no HAVE_COPYSIGN is definedmattip2022-08-211-11/+0
| |
* | frexp is now mandatorymattip2022-08-211-4/+1
| |
* | move hypot to optional for windows, fix pow and log2mattip2022-08-211-38/+105
| | | | | | | | Signed-off-by: mattip <matti.picus@gmail.com>
* | restore HAVE_POWL for macOS blocklistingmattip2022-08-211-2/+28
| | | | | | | | Signed-off-by: mattip <matti.picus@gmail.com>
* | restore HAVE_LOG2 for cygwin blocklistingwmattip2022-08-211-2/+52
| |
* | remove ifndef alterantives for mandatory functionsMatti Picus2022-08-211-44/+2
| |
* | make optional C99 double routines mandatorymattip2022-08-211-348/+2
|/
* MAINT: Simplify FE_INVALID redefine logic slightly and copy to cppSebastian Berg2022-06-142-48/+54
| | | | | | | This builds on the previous, but just redefines them in the C/C++ file since this is not a header and defining an undefined macro value should not be a problem locally. Also tweaks the comment a bit.
* ENH: Add support for platforms with missing fenv flagsHood Chatham2022-06-141-12/+54
| | | | | | | | | | | | | | | For instance wasm has no fenv support. musl-libc defines all the fenv functions unconditionally (fesetexcept, feclearexcept, etc) but on unsupported platforms they are no-ops: https://git.musl-libc.org/cgit/musl/tree/src/fenv/fenv.c However, the platform is expected to only define flags like FE_OVERFLOW if they are supported. I haven't found an explanation of the design decision, but it seems to be aimed at fine-grained feature detection. musl-libc-test has code that uses fenv and wants it to silently decay to a no-op on platforms missing support. I copied their implementation of this behavior: http://nsz.repo.hu/git/?p=libc-test;a=blob;f=src/common/mtest.h;h=706c1ba23ea8989b17a2f72ed1a919e187c06b6a;hb=HEAD#l30
* MAINT: Remove FPE helper code that is unnecessary on C99/C++11Sebastian Berg2022-06-131-219/+4
| | | | | | | | | | | C99 and C++11 standardize `fenv.h`, so we should not need the manual definitions for these functions for platforms that do not support it. See e.g.: https://en.cppreference.com/w/c/numeric/fenv If issues come up, the code can be restored. This applies gh-21421 again, since we had to revert using the cpp file and the change thus got lost.
* MAINT: back out conversion of npymath component to c++mattip2022-05-291-0/+842
|
* MAINT: Remove FPE helper code that is unnecessary on C99/C++11Sebastian Berg2022-05-011-239/+5
| | | | | | | | C99 and C++11 standardize `fenv.h`, so we should not need the manual definitions for these functions for platforms that do not support it. See e.g.: https://en.cppreference.com/w/c/numeric/fenv If issues come up, the code can be restored.
* MAINT: Translate ieee754.c.src to C++ using templates. (#21367)serge-sans-paille2022-04-291-237/+339
| | | | | | | | | | | | | | | | | | | * [Road to C++] Rename ieee754.c.src into ieee754.cpp.src * [Road to C++] Remove all use of internal template engine Replace them by regular C++ templates. * [Road to C++] mv ieee754.cpp.src ro ieee754.cpp Clang-format it, and update build system accordingly. * Fix 'unnecessary parentheses in declaration of ‘__NPY_UNUSED_TAGGEDc’ [-Wparentheses]' * [Road to C++] Fix misc conversion issues in ieee754.cpp - hex float literal are not supported in C++ - avoid overload issues when numpy_longdouble ultimately is equal to double - _statusfp2 exepcts unsigned arguments
* MAINT: Fix typosAlexander Shadchin2022-03-311-2/+2
|
* Extend fix for ARM32Niyas Sait2022-01-281-1/+1
|
* Fixes #20930Niyas Sait2022-01-281-1/+1
| | | | Do not use __popcnt and variants for windows/arm64 target
* MAINT, DOC: discard repeated wordsDimitri Papadopoulos2022-01-131-1/+1
|
* Restore vc141 supportIsuru Fernando2022-01-021-0/+3
|
* BUG: Revert from `long double` changes, and force `npymath` to respect ↵Sayed Adel2021-11-131-14/+26
| | | | | | | | | | | `npy_longdouble` (#20360) In some certain cases mostly workarounds, there's a necessity to define `npy_longdouble` as `double` even if that was against the compiler implementation(sizeof(long double) != sizeof(double)). Therefore, avoid `long double`, use `npy_longdouble` instead, and when it comes to standard math functions make sure of using the double version when `NPY_SIZEOF_LONGDOUBLE` == `NPY_SIZEOF_DOUBLE`.
* ENH: Adding `scalar.bit_count()` (popcount) (#19355)Ganesh Kathiresan2021-11-011-0/+86
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Adding bitcount method to scalars, e.g.: a = np.int32(1023).bit_count() * ENH: Implementation of bit_count (popcount) * ENH: Add bit_count to integer scalar type * ENH: Annotations for bit_count * ENH, WIP: Documentation for bit_count * DOC: Added `bit_count` (#19355) * BUG: Fixed windows 32 bit issue with no `__popcnt64` * DOC: Refined docstring for bit_count * TST: Tests for bit_count * ENH, MAINT: Changed return type to uint_8 | Removed extra braces and fixed typo * BUG: Fixed syntax of bit_count * DOC, BUG: Fixed bit_count example * DOC, BUG: (#19355) Removed bit_count from routines.math.rst | Improved release notes * BUG: Added type suffix to magic constants * ENH: Handle 32 bit windows popcount | Refactored popcount implementation to new function * MAINT: Refactor type_methods, separate integer definitions * DOC: Added double-ticks
* Thin compatibility layer for C/C++ math headerserge-sans-paille2021-10-251-0/+6
| | | | Should fix #20180
* [demo] how-to replacing numpy custom generation engine by raw C++serge-sans-paille2021-10-221-0/+12
| | | | | This is just a technical prototype to measure and discuss the impact and implication of moving to C++ for kernel code generation.
* BUG: np.tan(np.inf) test failureDeveloper-Ecosystem-Engineering2021-09-271-0/+19
| | | | | | | | | | | | | | | | | | | | Numpy has a test failure where `np.tan(np.inf)` is not raising "invalid". The bug is due to an underlying bug in Apple's Libm. The bug is only present on arm64 and does not affect x86_64. The changes here apply to sin, cos, and tan. If the input is a non-finite value, then return `(x - x)`, which will raise "invalid" for `x=INFINITY` as well as return `NAN` for both `INFINITY` and `NAN` as input. Testing: (Note, the testing below is on top of another branch that fixes divide-by-zero failures in reciprocal) Before change: ``` FAILED numpy/core/tests/test_umath.py::TestSpecialFloats::test_tan - AssertionError: FloatingPointError not raised by tan 1 failed, 15589 passed, 302 skipped, 1268 deselected, 31 xfailed, 3 xpassed in 70.99s (0:01:10) ``` After change: ``` 15590 passed, 302 skipped, 1268 deselected, 31 xfailed, 3 xpassed in 71.38s (0:01:11) ```
* STY: Small cleanups of includes in *.c files.Charles Harris2021-09-031-0/+1
| | | | | | | | | | | | | | | | This puts the following numpy defines at the top of the files before the includes. define NPY_NO_DEPRECATED_API NPY_API_VERSION define _MULTIARRAYMODULE define _UMATHMODULE There are also minor cleanups of <...> vs "..." include styles together with a small fix to the .clang-format file to include "pymem.h" among the Python supplied headers. Further cleanups will follow if clang-format is used on the files but that is not done here.
* BUG: Fix floating point error flags in division related opsSebastian Berg2021-07-121-62/+22
|
* delete comment about warningrubiales2021-07-121-1/+0
|
View Lorry Controller Status