…Half/Double VSX3 instructions by the assembler

  This fix addresses two issues:
   * Corrects the use of unsupported instructions by the assembler
     in half-precision to double-precision conversion.
   * Resolves a code error related to variable naming during conversion.

is my email back because it is stored somewhere else or is it just a conflict bad manipulation ? you can forget me please

….isclose

These shouldn't fail and should work without the GIL, but as cython
points out (now), this doesn't work in practice, because without
the `noexcept`, cython will grab the GIL to check for errors every
time.

This is said to be fixed upstream, see
anaconda/anaconda-client#654

Closes numpy#24062

MAINT: Add missing `noexcept` to shuffle helpers

DOC: "What is NumPy?" section of the documentation

Incorporates numpy/meson#6

Closes numpygh-25026

[skip azp] [skip circle]

BLD: make macOS version check for Accelerate NEWLAPACK more robust

Update .mailmap

Co-authored-by: Sebastian Berg <[email protected]>

ENH: DType API slot for descriptor finalization before array creation

…gfault

BUG: ensure passing `np.dtype` to itself doesn't crash

…mall bug

Also, fixes a small issue, that the type[int] and type[bool] are special
and any other paths were actually just broken.

MAINT: Adjust typing for readded `np.long`

…long

The new random number generation defaults to int64 throughout.

Also test it within cython

This way, any integer input should work fine, in particular any 64
bit platform.  Chosing this rather than intp, since there seems
little reason to not support 64bit ints on 32bit platforms.

Some tests will be failing and docs will need update probably.

Otherwise, fixing the rest of the test seems actually more annoying.

This is just minimal, really should use int64, but this is the legacy
API anyway.

… compile

(emscriptn CI was failing due to this)

(Might be good to have more tests, seemed mainly tested indirectly
via `choice` tests.)

Otherwise things get confusing, the default integer must be long after
all if long and int are the same size.

Also does this for bernoulli, its a mixed bag, many legacy ones use
the `disc()` which just force-casts from int64 to long anyway...

This was relied upon by sklearn and it seems reasonable to still
default to returning a Python integer.

The test should check for the result type, but the way I had adapted
it was thus the wrong way around (and didn't work)

This is somewhat strange, because we cast to double in the scalar
case.  This is OK in practice because we are really only interested
in 32bit longs, which are guaranteed to fit into double...

Co-authored-by: Nathan Goldbaum <[email protected]>

Simply sort the long codes before int, because it might mean we
prefer them (and that may fix the tests).  Also explicitly add
mapping to ssize_t for int (this pre-empts chaning the definition
of `intp` admittedly)

Co-authored-by: Nathan Goldbaum <[email protected]>

This shouldn't normally be run anyway due to the requires-memory,
but I saw one CI failure on the armhf run.

I am getting a lot of compile warnings recently.  Not sure exactly
why, but one source here is that the 1 we store is cast to -1 for
a signed integer bitfield.  Making it explicitly unsigned quenches
the warning and seems easiest.

Use hex code, for no good reason other than Figma being buggy.

Closes numpygh-24933

MAINT: Unpin urllib3 for anaconda-client install

Add example for item method with object arrays

Signed-off-by: Liang Yan <[email protected]>

TST: Ensure test is not run on 32bit platforms

MAINT: Make bitfield integers unsigned

API: Make 64bit default integer on 64bit windows

DOC: Include `np.long` in `arrays.scalars.rst`

DOC: Small fixes for NEP 52

Closes numpygh-16261.

numpygh-16261 reported that documentation headings currently have inconsistent capitalization schemes and should be standardized.

DOC: revisions to "absolute beginners" tutorial

This adds a header to define compatibility with 1.x when compiling
against 2.0.  However, it is also designed so that it can be vendored
by downstream to allow affected projects to compile with 1.x also.

For now, it only points to the complex macros and includes the
``NPY_DEFAULT_INT`` macro.  More things could be added though,
for example, I had an initial version that "backported"
``PyUFunc_GiveFloatingPointErrors``.

Also add logging on failure, so future build issues are easier to
diagnose.

Also includes some smaller fixes to make the OpenBLAS and MKL detection
more efficient, resulting in less output in meson-log.txt

BLD: improve detection of Netlib libblas/libcblas/liblapack

Eventually, the ``import_array()`` helper would also raise such an
error anyway, but this is nicer because it gives us cleaner control
of the error message (allowing us to update recommendations with
new releases for example).

The error message given by ``import_array()`` is controlled by us
but most likely compiled in from a many years old NumPy version...

This commit does not enforce ABI version yet, but this may follow
soon!