[Numpy-discussion] Change definition of complex sign (and use it in copysign)

2023-12-22 Thread mhvk
Hi All,

A long-standing, small wart in numpy has been that the definition of sign for 
complex numbers is really useless (`np.sign(z)` gives the sign of the real 
component, unless that is zero, in which case it gives the sign of the 
imaginary component, in both cases as a complex number with zero imaginary 
part). Useless enough, in fact, that in the Array API it is suggested [1] that 
sign should return `z / |z|` (a definition consistent with those of reals, 
giving the direction in the complex plane).

The question then becomes what to do. My suggestion - see 
https://github.com/numpy/numpy/pull/25441 - is to adapt the Array API 
definition for numpy 2.0, with the logic that if we don't change it in 2.0, 
when will we?

Implementing it, I found no real test failures except one for `np.geomspace`, 
where it turned out that to correct the failure, the new definition 
substantially simplified the implementation.

Furthermore, with the redefinition, it has become possible to extend 
``np.copysign(x1, x2)`` to complex numbers, since it can now generally return 
``|x1| * sign(x2)`` with the sign as defined above (with no special treatment 
for zero).

Anyway, to me the main question would be whether this would break any workflows 
(though it is hard to see how it could, given that the previous definition was 
really rather useless...).

Thanks,
https://github.com/data-apis/array-api/pull/556, 
Marten

[1] 
https://data-apis.org/array-api/latest/API_specification/generated/array_api.sign.html
 (and https://github.com/data-apis/array-api/pull/556, which has links to 
previous discussion)
___
NumPy-Discussion mailing list -- numpy-discussion@python.org
To unsubscribe send an email to numpy-discussion-le...@python.org
https://mail.python.org/mailman3/lists/numpy-discussion.python.org/
Member address: arch...@mail-archive.com


[Numpy-discussion] Re: ENH: ignore_nan parameter in np.average

2023-12-23 Thread mhvk
I think the logical choice would be to allow a weighted average in the 
nan-functions, not to change `np.average`. In particular, I think it is bad API 
to add options for such exclusions; we have another open issue about infinitiy 
in the data, which leads to nan even with weight 0 (because `0*inf = nan`; see 
https://github.com/numpy/numpy/issues/25362); should that gets its own option?

It also seems a case that is *very* easily solved by the user with a wrapper, 
or, as noted in the issue, with creating a mask and using `np.ma.average`. Or, 
indeed, just calculating `np.nansum(data * weight, axis=...) / 
np.nansum(weight, axis=...)`

Anyway, my 2ยข would be to think whether we actually need this addition, and, if 
we decide we do, to see how this would fit with the `nan*` functions. This 
might mean introducing `np.nanaverage` since the Array API is fairly clear that 
`mean()` should be unweighted. Indeed, if written such that the `NaN` skipping 
is done after data and weight are multiplied, that would solve 
https://github.com/numpy/numpy/issues/25362 too.

-- Marten

p.s. My other reason for hesitation is that generally when you get a NaN, 
something is actually wrong...

> I would love some input on this issue, 
> https://github.com/numpy/numpy/issues/21375.
>
> I have created a draft PR which I believe resolves it, 
> https://github.com/numpy/numpy/pull/25474. Decided to go with adding 
> ignore_nan to np.average rather than adding weights to np.nanmean as it 
> seemed logical and was the path of least resistance.
> Please let me know what you think!
> -awestm
___
NumPy-Discussion mailing list -- numpy-discussion@python.org
To unsubscribe send an email to numpy-discussion-le...@python.org
https://mail.python.org/mailman3/lists/numpy-discussion.python.org/
Member address: arch...@mail-archive.com


[Numpy-discussion] Re: Bumping CPU baseline to x86-64-v2

2025-05-17 Thread mhvk
Hi Sayed,

I'm a bit confused: does your suggested change mean that prre-2009 processors 
won't work at all, or that no use will be made of the (little) acceleration 
that they provided?  The latter seems fine, but not working at all seems rather 
bad. Though I'd think that for any old processors one can just fall back to the 
standard `libm` implementations.

All the best,

Marten
___
NumPy-Discussion mailing list -- numpy-discussion@python.org
To unsubscribe send an email to numpy-discussion-le...@python.org
https://mail.python.org/mailman3/lists/numpy-discussion.python.org/
Member address: arch...@mail-archive.com