You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Can we brainstorm a namespace for array creation/inspection utils? Maybe as part of np.lib.<submodule>, maybe directly np.<submodule>?
Functions I might dump there are:
byte_bounds (apparently some use it, and it's an OK function, but not really a general audience one, unlike may_share_memory which I think makes sense at least for teaching).
np.core._multiarray_umath._discover_array_parameters: Finds the shape and dtype the same way as np.asarray(), but doesn't create the full array (although it does create some temporaries). Seems to be useful occasionally, and may also be useful to add additional functionality that we do not want in np.asarray().
prepare_arrays(*arrays, *, kwarg=None) may be useful. For NEP 50, maybe asarray_or_pyscalar makes just as much sense (one can trivially write that admittedly). @mdhaber liked the idea of having a function that converts multiple arrays to their result type (which could be an option there). I like the idea of clumping asarray calls; opitonally including result_type seems convenient (even if it may not always be ideal as it assumes simple promotion is correct, it is effectively what is often used anyway).
normalize_axis_index
Probably we can think of more functions to add there or move?
Maybe utils is already a decent name and it just needs to lose some of the weirder functions?
The text was updated successfully, but these errors were encountered:
I created a PR that introduces np.lib.array_utils public namespace: #24540
Right now it hosts byte_bounds, normalize_axis_tuple (originally imported from core in np.lib.stride_tricks) and normalize_axis_index (originally imported from core in np.lib.shape_base)
Uh oh!
There was an error while loading. Please reload this page.
Can we brainstorm a namespace for array creation/inspection utils? Maybe as part of
np.lib.<submodule>
, maybe directlynp.<submodule>
?Functions I might dump there are:
byte_bounds
(apparently some use it, and it's an OK function, but not really a general audience one, unlikemay_share_memory
which I think makes sense at least for teaching).np.core._multiarray_umath._discover_array_parameters
: Finds the shape and dtype the same way asnp.asarray()
, but doesn't create the full array (although it does create some temporaries). Seems to be useful occasionally, and may also be useful to add additional functionality that we do not want innp.asarray()
.prepare_arrays(*arrays, *, kwarg=None)
may be useful. For NEP 50, maybeasarray_or_pyscalar
makes just as much sense (one can trivially write that admittedly). @mdhaber liked the idea of having a function that converts multiple arrays to their result type (which could be an option there). I like the idea of clumping asarray calls; opitonally includingresult_type
seems convenient (even if it may not always be ideal as it assumes simple promotion is correct, it is effectively what is often used anyway).normalize_axis_index
Maybe
utils
is already a decent name and it just needs to lose some of the weirder functions?The text was updated successfully, but these errors were encountered: