| Commit message (Collapse) | Author | Age | Files | Lines |
|\
| |
| | |
BUG: Use 2GiB chunking code for fwrite() on mingw32/64
|
| |
| |
| |
| |
| |
| |
| | |
This is a bit too broad because msys UCRT runtime may actually not
need it. Changes the type in the loop to `size_t`. This is not necessary
but the current constants are buggy without it if the branch is accidentally
used on 32bit.
|
| |
| |
| |
| | |
Addresses #2256
|
|\ \
| | |
| | | |
BUG: Fix weak scalar logic for large ints in ufuncs
|
| | | |
|
| | | |
|
| | |
| | |
| | |
| | |
| | | |
This fixes it, breaks warnings (partially), but most or all of
those paths should be errors anyway.
|
|\ \ \
| | | |
| | | | |
ENH: Restore TypeError cleanup in array function dispatching
|
| | | |
| | | |
| | | |
| | | | |
Not that it mattered, but docs say direction should be either -1 or 1
|
| | | | |
|
| | | | |
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
When the dispathcer raises a TypeError and it starts with the dispatchers
name (or actually __qualname__ not that it normally matters), then it is
nicer for users if we just raise a new error with the public symbol name.
Python does not seem to normalize exception and goes down the unicode path,
but I assume that e.g. PyPy may not do that. And there might be other
weirder reason why we go down the full path. I have manually tested it
by forcing Normalization.
Closes gh-23029
|
| | | | |
|
|\ \ \ \
| | | | |
| | | | | |
ENH: Speed up 64-bit qsort by 1.6x
|
| | |/ /
| |/| | |
|
|\ \ \ \
| |/ / /
|/| | | |
MAINT: do not use copyswapn in array sorting internals
|
| | | | |
|
|\ \ \ \ |
|
| |\ \ \ \
| | | | | |
| | | | | | |
ENH: add fast path for str(scalar_int)
|
| | | | | | |
|
| | | | | | |
|
| | | | | | |
|
| | |/ / /
| |/| | | |
|
| |\ \ \ \
| | |/ / /
| |/| | | |
MAINT: Add a proper implementation for structured zerofill
|
| | | | | |
|
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
This reorganizes the generic traversal functions for structured
dtypes a bit (before it wasn't quite generic).
Then uses that for zerofilling. We could get the two a bit closer
by also supporting `func==NULL` explicitly for clearing.
(I have not includes this here.)
The old `FillObjectArray` is still in use now, this is not ideal
and the new approach should be duplicated to add an "emptyfill"
(same semantics, normally just memset to 0, but for objects we
place an explicit `None` object).
This is a necessary follow-up to gh-23591.
|
| | | | | |
|
| | | | |
| | | | |
| | | | |
| | | | | |
xref https://github.com/numpy/numpy/pull/18053
|
| |\ \ \ \
| | | | | |
| | | | | | |
ENH: Make signed/unsigned integer comparisons exact
|
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
This makes comparisons between signed and unsigned integers exact
by special-casing promotion in comparison to never promote integers
to floats, but rather promote them to uint64 or int64 and use a
specific loop for that purpose.
This is a bit lazy, it doesn't make the scalar paths fast (they never were
though) nor does it try to vectorize the loop.
Thus, for cases that are not int64/uint64 already and require a cast in
either case, it should be a bit slower. OTOH, it was never really fast
and the int64/uint64 mix is probably faster since it avoids casting.
---
Now... the reason I was looking into this was, that I had hoped
it would help with NEP 50/weak scalar typing to allow:
uint64(1) < -1 # annoying that it fails with NEP 50
but, it doesn't actually, because if I use int64 for the -1 then very
large numbers would be a problem...
I could probably(?) add a *specific* "Python integer" ArrayMethod for comparisons
and that could pick `object` dtype and thus get the original Python object
(the loop could then in practice assume a scalar value).
---
In either case, this works, and unless we worry about keeping the behavior
we probably might as well do this.
(Potentially with follow-ups to speed it up.)
|
| | | | | | |
|
| |\ \ \ \ \
| | | | | | |
| | | | | | | |
ENH: Use AVX512 FP16 ISA for sorting float16 arrays
|
| | | | | | | |
|
| | | | | | | |
|
| |\ \ \ \ \ \
| | |_|/ / / /
| |/| | | | | |
MAINT: refactor PyArray_Repeat to avoid PyArray_INCREF
|
| | | | | | | |
|
| | | | | | | |
|
| | | | | | | |
|
| | | | | | | |
|
| |\ \ \ \ \ \
| | | | | | | |
| | | | | | | | |
ENH allow for specifying CPU features to enable via `NPY_ENABLE_CPU_FEATURES` environment variable
|
| | | | | | | | |
|
| |\ \ \ \ \ \ \
| | | | | | | | |
| | | | | | | | | |
DOC: Resolve length/index ambiguity in numpy.outer docstring
|
| | | | | | | | | |
|
| | | | | | | | | |
|
| | | | | | | | | |
|
| | | | | | | | | |
|
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | | |
Co-authored-by: Pierre Blanchard <Pierre.Blanchard@arm.com>
|
| | |_|/ / / / /
| |/| | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | | |
When I translated range checks for [sin](https://github.com/ARM-software/optimized-routines/blob/91d5bbc3091fa568e6856c7c41f9d7492d5957df/math/v_sin.c#L68):
```c
cmp = v_cond_u64 ((ir >> 52) - TinyBound >= Thresh);
```
and [cos](https://github.com/ARM-software/optimized-routines/blob/91d5bbc3091fa568e6856c7c41f9d7492d5957df/math/v_cos.c#L56):
```c
cmp = v_cond_u64 (v_as_u64_f64 (r) >= v_as_u64_f64 (RangeVal));
```
They ended up the wrong way around, this corrects it.
|
| |\ \ \ \ \ \ \
| | | | | | | | |
| | | | | | | | | |
ENH: Allow, and default to, downstream building with old API
|
| | | | | | | | |
| | | | | | | | |
| | | | | | | | | |
Co-authored-by: Matti Picus <matti.picus@gmail.com>
|