> What you are hoping for here is known as "short circuit" or "lazy" evaluation.
In SciPy, we have the private utility function `_lazywhere`[1] for this.
Cheers,
Lucas
[1]
https://github.com/scipy/scipy/blob/f44326023dc51758495491fc9f06858fd38358a0/scipy/_lib/_util.py#L88-L156
> On 26 Apr 2024
While not about exactly your proposed syntax, the discussion in
https://github.com/data-apis/array-api/issues/609 is relevant.
Cheers,
Lucas
> On 24 Jul 2024, at 11:49, Oras P. wrote:
>
> I am aware that to do unbuffered addition operation, I can use `np.add.at`
> like this:
> ```
> np.add.at
+1 for the general idea!
It may be nice to have such a function which sits at the top level of the API,
to fit into
https://data-apis.org/array-api/draft/API_specification/data_type_functions.html
nicely. However, ‘min_value’ or ‘min‘ won’t do then - we’d probably need to
include ‘dtype’ in th
Or how about `np.dtype_info(dt)`, which could return an object with attributes
like `min` and `max`. Would that be possible?
___
NumPy-Discussion mailing list -- numpy-discussion@python.org
To unsubscribe send an email to numpy-discussion-le...@python.or
Ralf Gommers wrote:
> This sounds quite reasonable to me. The `k=0` keyword is quite badly named,
> which is my one concern. Especially when tacking it on at the end of a
> signature with already 3-4 keywords, it's not a good name. How about
> something like `diag_offset`?
FWIW, we chose `offset`
> The new discrepancy between `arr.T` and `arr.transpose()` is justified, as
> `T` is defined by the Array API, where `transpose` isn't and should retain
> the existing behavior.
The other side of the coin here is that this change would fix the
discrepancy between `arr.T` and the functions `np.ma
If NumPy were to make a move on the deprecation, then I think it would be
reasonable to change the standard from
> If the array instance is not two-dimensional, an error should be raised.
to “if the array instance is not two-dimensional, behaviour should match `.mT`,
or an error should be raise
