summaryrefslogtreecommitdiff
path: root/numpy
Commit message (Collapse)AuthorAgeFilesLines
* MNT: also use Py_SET_REFCNT instead of Py_REFCNTThomas A Caswell2020-07-182-1/+3
| | | | This is required to support Python 3.10.
* BLD: update cython to 0.29.21mattip2020-07-102-4/+4
|
* Merge pull request #16397 from seiko2plus/implement_npyvMatti Picus2020-07-1041-0/+4459
|\ | | | | ENH: Implement the NumPy C SIMD vectorization interface
| * SEQ([1/4]): Fix NPY_FINLINE failbackSayed Adel2020-07-081-1/+1
| | | | | | Co-authored-by: Matti Picus <matti.picus@gmail.com>
| * ENH: [4/4] implement the NumPy C SIMD vectorization interfaceSayed Adel2020-07-087-0/+763
| | | | | | | | implement the same intrinsics as X86 for Power/VSX little-endian mode
| * ENH: [3/4] implement the NumPy C SIMD vectorization interfaceSayed Adel2020-07-087-0/+748
| | | | | | | | implement the same intrinsics as X86 for NEON
| * ENH: [2/4] implement the NumPy C SIMD vectorization interfaceSayed Adel2020-07-0825-0/+2578
| | | | | | | | | | | | | | | | | | | | | | | | | | implement the following intrinsics for X86 extensions: - load, store - zero, setall, set, select, reinterpret - boolean conversions - (add, sub, mul, div, adds, subs) - logical - comparison - left and right shifting - combine, zip
| * ENH: [1/4] implement the NumPy C SIMD vectorization interfaceSayed Adel2020-07-088-0/+370
| | | | | | | | | | | | | | | | | | "NPYV" or universal intrinsics as NEP-38 define it, are types and functions intended to simplify vectorization of code on different platforms. This patch initialize NPYV for SIMD extensions SSE, AVX2, AVX512, VSX and NEON on the top of C definitions that defined by the new generated header '_cpu_dispatch.h' which included by 'cpu_dispatch.h'.
* | DOC: Minor RST formatting. (#16792)Matthias Bussonnier2020-07-093-4/+4
| | | | | | DOC: fixes to capitalization and header lines
* | Merge pull request #16200 from seberg/dtypemeta-array-coercionMatti Picus2020-07-0933-1654/+2427
|\ \ | | | | | | ENH: Rewrite of array-coercion to support new dtypes
| * | TST: Add test for astype to stringlength testsSebastian Berg2020-07-081-0/+2
| | | | | | | | | | | | | | | astype is similar to array coercion, and is also compared in many of the tests below.
| * | DOC,STY: Use bitshift intsead of powers of two and fix commentsSebastian Berg2020-07-081-15/+11
| | | | | | | | | | | | | | | As asked for by Hameer, the comment was outdated, so had to change it completely instead of fixing one word.
| * | TST: datetime64 test_scalar_coercion does not fail anymoreSebastian Berg2020-07-081-3/+2
| | | | | | | | | | | | | | | The rational test still fails, but the xfail message was wrong or confusing.
| * | MAINT: Put a hack in place to allow datetime64 -> string assignment when ↵Sebastian Berg2020-07-082-9/+45
| | | | | | | | | | | | | | | | | | | | | | | | string is too short this retains (and slightly expands) the old behaviour. It is inconsistent and I think we should fix that inconsistency one way or the other (I honestly do not care *which* way).
| * | Update numpy/core/src/multiarray/array_coercion.cSebastian Berg2020-07-081-1/+1
| | | | | | | | | Co-authored-by: Anirudh Subramanian <anirudh2290@apache.org>
| * | MAINT: Remove weakref from mapping (for now) and renameSebastian Berg2020-07-084-44/+41
| | | | | | | | | | | | | | | Also add some more documentation for PyArray_DiscoverDTypeAndShape_Recursive
| * | TST: Adapt coercion-tests to the new situationSebastian Berg2020-07-081-50/+32
| | | | | | | | | | | | | | | | | | | | | Unfortunately one test had to be adapted (I missed the difference between timedelta64 and datetime64), and one tests which I thought failed only for one reason, also failed for anothe reason which is not fully gone in master.
| * | MAINt: Add assert for an unreachable exception pathSebastian Berg2020-07-081-3/+4
| | | | | | | | | | | | | | | Could also just delete this path entirely, but thought for now to keep it around.
| * | TST: Add test for too-deep non-object deprecationSebastian Berg2020-07-081-0/+16
| | | | | | | | | | | | | | | This is similar to the ragged deprecation, and proofs that gh-15611 is fixed previously.
| * | MAINT: Try to clean up headers a bitSebastian Berg2020-07-086-6/+9
| | |
| * | MAINT: Undo some header changes...Sebastian Berg2020-07-082-8/+14
| | |
| * | MAINT: Undo change of how 0-D array-likes are handled as scalarsSebastian Berg2020-07-083-8/+36
| | |
| * | MAINT: Delete PyArray_AssignFromSequenceSebastian Berg2020-07-082-179/+0
| | | | | | | | | | | | | | | | | | This function is not used anymore, so can be deleted. In all cases where we would want to use it, we first figure out the parameters and thus might as well use the AssignFromCache function
| * | MAINT: Use macros/functions instead of direct slot accessSebastian Berg2020-07-081-2/+4
| | | | | | | | | | | | Hopefully this approach is acceptable for PyPy...
| * | MAINT: Fixups (some based on new tests), almost finishedSebastian Berg2020-07-083-6/+2
| | | | | | | | | | | | | | | | | | There may be one more leak to be tracked down here, and I have the intention of checking/writing a few simple benchmarks just because...
| * | MAINT: Use flag to indicate that dtype discovery is not necessarySebastian Berg2020-07-081-43/+39
| | | | | | | | | | | | | | | If the user already set the descriptor, within the recursive call `*out_descr` is simply set correctly ahead of time.
| * | BUG: Need to set the base field apparently and swap promotionSebastian Berg2020-07-081-3/+2
| | | | | | | | | | | | | | | | | | | | | | | | Swapping promotion should not make a difference, but is a bit closer to what happened before, which should smooth over one failure in the pandas test-suit. The swapping probably only affects the promotion of datetime+float where we have a PR open to disable it in all cases.
| * | BUG: Fix use after free in PyArray_CopyObjectSebastian Berg2020-07-081-1/+4
| | | | | | | | | | | | | | | It seems strange that this did not error in any tests, should make sure I have at least one that hits this?!
| * | BUG: Fixup for PyArray_PackSebastian Berg2020-07-081-7/+9
| | |
| * | BUG: Add missing cache free...Sebastian Berg2020-07-081-0/+2
| | |
| * | BUG: Reorder dimension fix/check and promotionSebastian Berg2020-07-081-12/+14
| | | | | | | | | | | | | | | | | | | | | The code had both mixed up leading to a reference count leak when ragged arrays were involved. Further some fixups for the (semi-exposed) python side API
| * | BUG: Add missing error checkSebastian Berg2020-07-081-0/+6
| | | | | | | | | | | | | | | This was also missing before (I think there was even an unfinished PR), but my changes and new asserts flushed it out...
| * | Fixups: Some smaller fixups and comments to ensure we have testsSebastian Berg2020-07-081-43/+64
| | |
| * | BUG: Add missing DECREFSebastian Berg2020-07-081-0/+1
| | |
| * | BUG: Fix discovery for empty listsSebastian Berg2020-07-081-2/+3
| | |
| * | BUG: When filling an array from the cache, store original for objectsSebastian Berg2020-07-081-1/+3
| | | | | | | | | | | | | | | For object dtypes when the dimension limit is reached, we should prefer to store the original object, even if we have a converted array available.
| * | BUG: remove incorrect assertSebastian Berg2020-07-081-1/+0
| | | | | | | | | | | | | | | | | | While the assert is correct during array coercion, in general our parameteric instances *can* actually be attached to ndarrays and as such be used as a forced dtype in certain contexts...
| * | BUG: Smaller fixes in object-array parametric discoverySebastian Berg2020-07-081-7/+8
| | | | | | | | | | | | | | | I was hunting down for real bugs, and found these instead... The real bug was in the tests :/
| * | Allow returning NULL for dtype when there is no object to discover fromSebastian Berg2020-07-083-10/+32
| | | | | | | | | | | | | | | That is probably actually much better. I first thought that might push annoying logic down in many places, but its actually only one place...
| * | MAINT: Delete legacy dtype discoverySebastian Berg2020-07-084-930/+44
| | |
| * | MAINT: Remove use of PyArray_GetParamsFromObject from PyArray_CopyObjectSebastian Berg2020-07-084-110/+96
| | | | | | | | | | | | This required an additional hack unfortunately...
| * | Add somewhat disgusting hacks for datetime supportSebastian Berg2020-07-083-17/+54
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The can guess the dtype unit for almost anything that looks like a string (including numpy strings). So they support looking at every array element very well (in order to find the correct dtype). We thus need two hacks to support them: 1. Ensure that any string-like object is directly handled by the datetime (using is_known_scalar_type) 2. Have a string/bytes->datetime special case in the dtype from array discovery path which should only special case `object` arrays. (at least I would prefer that).
| * | Replace AdaptFlexibleDType with object and delete some datetime thing relatedSebastian Berg2020-07-0811-331/+224
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This fails two tests (but behaviour is better now). The string->datetime unit discovery for string arrays is hard-coded now, and IMO should be deprecated at some point, if necessary we can add a specific function for it maybe? Unless we really want to make this pattern a first class citizen (and not special case object). But I am against that until someone finds a better use-case...
| * | BUG: Make static declaration safe (may be an issue on msvc mostly)Sebastian Berg2020-07-081-18/+17
| | |
| * | Small fixups/comment changesSebastian Berg2020-07-081-7/+6
| | |
| * | update some comments, remove outdated old code pathSebastian Berg2020-07-082-65/+31
| | | | | | | | | | | | | | | This simplifies find_scalar_descriptor (and is actually what the NEP describes right now)
| * | Fixups/comments for compiler warningsSebastian Berg2020-07-086-7/+27
| | |
| * | Small bug fixup and rebase on masterSebastian Berg2020-07-082-4/+1
| | |
| * | Other smallre changes, some optimization related.Sebastian Berg2020-07-083-28/+27
| | |
| * | Optimize away filling all dims with -1 at the startSebastian Berg2020-07-081-13/+18
| | | | | | | | | | | | | | | Surprisingly, this actually is quite a large overhead (20-30% probably, since it is 10+% on a timing with many other overheads)
View Lorry Controller Status