On Thu, 2022-11-10 at 14:55 +0100, Oscar Gustafsson wrote:
> Den tors 10 nov. 2022 kl 13:10 skrev Sebastian Berg <
> sebast...@sipsolutions.net>:
>
> > On Thu, 2022-11-10 at 11:08 +0100, Oscar Gustafsson wrote:
> > > >
> > > > I'm not an
g users (about breakages/workarounds and how things work)
I doubt you/we need it for 1. at this point or details for why meson,
but if anyone disagrees then maybe we do ;). But 2. may very much be
worthwhile.
- Sebastian
PS: I do like the idea of having short NEPs. My feeling is that the
&q
ically zero. I do not want custom
exceptions for too many things, but there are probably good reasons to
have more than we do have right now, and even the ones we have seem
enough for a namespace.
Cheers,
Sebastian
The long story is that following one of those many threads, I decide
but doesn't yet quite work.
I will note just dealing with the Python/NumPy C-API can be a fairly
steep learning curve, so you need someone comfortable to dive in and
budget a good amount of time for that part.
And yes, this is pretty new, so there may be stumbling stones (which I
am happy to disc
n
> discussed
Whoops, got distracted: I made it publicly visible. I assume that was
the intention and invisible is just the default.
- Sebastian
> before: any thoughts to change it to e.g. tempita templating?
> Translating .c.src templates to .c.in is straightforward if tedious,
>
ould `tobytes()` be made to compactify? Yes, but then it suddenly
needs extra logic for bit-sized and doesn't just expose memory. That
is maybe fine, but also seems a bit awkward?
I would love to have a better answer, but dancing around the byte-
strided ABI seems tricky...
Anyway, I am al
Hi again,
On Tue, 2022-10-25 at 11:41 +0200, Sebastian Berg wrote:
> Hi all,
>
> I would like to expose more of the ufunc internals in the following
> PR:
>
> https://github.com/numpy/numpy/pull/22422/
Just to note that this PR is now merged and scheduled for release
(w
it pretty clear cut (it is
still a large compatibility change that should be formally accepted as
a brief NEP, similar to yanking financial).
Without any "mitigation" it is a tough decision to make. Maybe there is
no decision, because longdouble is a house of cards bound to collapse
unless
I plan on adding a brief note on about helping with doc updates to NEP
when accepting it. Ross was planning to add a table of changed
examples, although I don't think that is necessary for accepting.
Cheers,
Sebastian
On Fri, 2022-10-28 at 10:54 +0200, Sebastian Berg wrote:
> Hi all,
&
Thanks for bringing this up again. The Python method exists and it
seems like relatively basic functionality.
Overall, I am slightly in favor of adding the ufunc. So if nobody
voices an opinion that it doesn't seem a good fit for NumPy, I would be
happy to move forward with it.
- Seba
On Tue, 2022-11-29 at 14:51 -0700, Aaron Meurer wrote:
> On Fri, Nov 25, 2022 at 9:36 AM Sebastian Berg
> wrote:
> >
> > Hi all,
> >
> > I would like to formally propose accepting NEP 51. Without any
> > concern
> > voiced, we will consider it accept
s? It seems useful to enable
`round()` and is a bit of a shame to get caught up on the detail, but I
am not sure what the right choice is :).
- Sebastian
___
NumPy-Discussion mailing list -- numpy-discussion@python.org
To unsubscribe send an em
ting to have you on the team! Exciting times ahead :).
- Sebastian
>
> Thanks, Sayed.
>
> On 12/2/22 01:03, Brigitta Sipőcz wrote:
> > Wonderful news, congratulations Sayed!
> >
> > Brigitta
> >
> > On Thu, 1 Dec 2022 at 13:18, Ralf Gommers
> >
On Fri, 2022-11-11 at 14:46 +0100, Sebastian Berg wrote:
> Hi all,
>
> I want to add a new exception or two. It is a longer story, that you
> can find at the bottom :).
>
> Lets create a namespace for custom errors! I don't want to propose
> new
> exceptions that j
atrix_norm` seems a bit tedious right now and
`vector_norm` probably adds functionality since multiple axes
are probably valid.
- Sebastian
PS: For the `ndarray.H` proposal, "its complicated" is maybe too fuzzy:
The complexity is about not being able to return a view for complex
numbers. Tha
On Mon, 2022-12-12 at 18:20 -0500, Warren Weckesser wrote:
> On 12/12/22, Aaron Meurer wrote:
> > On Mon, Dec 12, 2022 at 8:46 AM Sebastian Berg
> > wrote:
> > >
> > > On Wed, 2022-12-07 at 14:21 -0700, Aaron Meurer wrote:
> > > > Hi all.
>
soon (with plenty of time to test before the release)
if nobody voices concern.
Cheers,
Sebastian
___
NumPy-Discussion mailing list -- numpy-discussion@python.org
To unsubscribe send an email to numpy-discussion-le...@python.org
https://ma
nk anyone ever pushed for it very strongly.
There is maybe a bit more of a push for `vecdot` (both vectors) right
now, but you want the mixed case...
- Sebastian
>
> Best,
>
> Thibaut
>
> ___
> NumPy-Discussion mailing li
high end Intel CPUs (IIRC), presumably, you simply do
not have the hardware.
E.g. on M1, `show_runtime()` won't even list AVX512 when compiled, on
x86 they would probably show up as "not found" because they exist, but
your hardware doesn't support AVX512.
- Sebastian
>
who helped draft and revise this!
Cheers,
Sebastian
Road to NumPy 2.0> Note: This is a living document. We are prepared to modify
it through
> continued dialogue with the community. Its acceptance indicates
> consensus on the process and timelines.
AbstractNumPy 2.0 release is an op
On Wed, 2023-02-08 at 12:48 +0100, Francesc Alted wrote:
> Hi,
>
>
> Is there a way (or an ongoing effort) to express the variety of data
> types
> in NumPy that beats the above (which seems somewhat inconsistent to
> me)?
How about using the Python buffer interface format string (maybe with
On Wed, 2023-02-08 at 14:31 +0100, Francesc Alted wrote:
> On Wed, Feb 8, 2023 at 1:42 PM Sebastian Berg <
> sebast...@sipsolutions.net>
> wrote:
>
> > On Wed, 2023-02-08 at 12:48 +0100, Francesc Alted wrote:
> > > Hi,
> > >
> > >
> >
On Wed, 2023-02-08 at 17:08 +0100, Francesc Alted wrote:
> On Wed, Feb 8, 2023 at 3:19 PM Sebastian Berg <
> sebast...@sipsolutions.net>
> wrote:
>
> > On Wed, 2023-02-08 at 14:31 +0100, Francesc Alted wrote:
> > > On Wed, Feb 8, 2023 at 1:42 PM Sebastian Berg &
y public is not great...
(I will note that the DType classes do get printed sometimes in error
messages.)
Cheers,
Sebastian
___
NumPy-Discussion mailing list -- numpy-discussion@python.org
To unsubscribe send an email to numpy-discussion-le...@p
types because Python has `types` as a catch-all for builtin
types (mainly function, generator, ...) that are not normally used
directly and it seemed relatively clear and concise.
(In Python I don't think it has anything to do with typing directly.)
- Sebastian
>
> C
for where we would would put new submodules, i.e. in
`np.lib`. or `np.` directly.)
For these particular ones, I still slightly prefer `np.types` and
`np.exceptions`, but happy either way. One disadvantage of the main
namespace is that it is so large, it is hard to find submodules :).
- Sebastian
On Fri, 2023-02-10 at 10:34 -0700, Nathan wrote:
> On Fri, Feb 10, 2023 at 3:31 AM Sebastian Berg <
> sebast...@sipsolutions.net>
> wrote:
>
> > Hi all,
> >
> > I was wondering if we should introduce a new `np.types` namespace.
> > The
> > mai
ing to
`VisibleDeprecationWarning` before full removal.
- Sebastian
>
> Cheers,
> Ralf
> ___
> NumPy-Discussion mailing list -- numpy-discussion@python.org
> To unsubscribe send an email to numpy-discussion-le...@python.org
> https://m
On Tue, 2023-03-07 at 12:17 +, Ralf Gommers wrote:
> On Mon, Mar 6, 2023 at 8:12 AM Sebastian Berg <
> sebast...@sipsolutions.net>
> wrote:
>
> > On Thu, 2023-03-02 at 15:20 +, Ralf Gommers wrote:
> > > Hi all,
> > >
> > > In https:/
re=` might run into
issues (for some types).
That is slightly tedious, but I doubt it causes much issues in practice
(where isn't used much, and for most types it doesn't matter much
either way, except for rejecting weirder inputs).
Cheers,
Sebastian
_
u that using `out=`:
x = np.array([1, 5, 259], dtype=np.uint16)
res = np.empty_like(x, np.uint8)
np.clip(x, 3, 200, out=res, casting="unsafe")
will perform the calculation in whatever the inputs are and _then_
cast. But, in NumPy, unless you have largish arrays, performin
On Mon, 2023-03-13 at 11:22 +0100, Sebastian Berg wrote:
> Hi all,
>
> Without concerns voiced, I will probbaly merge the PR:
>
> https://github.com/numpy/numpy/pull/23240
I put this PR in, if it turns out there are issues or general dislike,
please let us know and we
.
However, I agree. Unless the use-case exceedingly clear about
requiring "outer" behavior. "outer" behavior is uncommon for functions
in the NumPy world and broadcasting is what users will generally expect
(and that includes future self).
- Sebastian
>
> __
ourse.
Cheers,
Sebastian
___
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...
On Thu, 2023-04-20 at 13:59 -0400, Warren Weckesser wrote:
> On 4/20/23, Sebastian Berg wrote:
> > Hi all,
> >
> >
>
> In [64]: np.float64(np.array([0.0]))
> :1: DeprecationWarning: Conversion of
> an array with ndim > 0 to a scalar is deprecated, an
On Thu, 2023-04-20 at 20:17 +0200, Sebastian Berg wrote:
> On Thu, 2023-04-20 at 13:59 -0400, Warren Weckesser wrote:
> > On 4/20/23, Sebastian Berg wrote:
> > > Hi all,
> > >
> > >
>
>
>
> >
> > In [64]: np.float64(np.array([0.0]))
&
mPy is probably not in a position to help you. You can
implement the functions that you described yourself (i.e. with overflow
return indication). And they will be fully compatible with NumPy (see
for example https://github.com/WarrenWeckesser/ufunclab or maybe via
jitters like numba).
- Sebastian
here is no
opportunity to see the intermediate float.
(There should be a larger opportunity for optimizing the comparison.)
Cheers,
Sebastian
___
NumPy-Discussion mailing list -- numpy-discussion@python.org
To unsubscribe send an email to numpy-dis
On Tue, 2023-05-16 at 11:46 -0400, Warren Weckesser wrote:
> On 4/21/23, Sebastian Berg wrote:
> > On Thu, 2023-04-20 at 20:17 +0200, Sebastian Berg wrote:
> > > On Thu, 2023-04-20 at 13:59 -0400, Warren Weckesser wrote:
> > > > On 4/20/23, Sebastian
core as needed.
Looking forward to working more with you!
Cheers,
Sebastian
___
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
a minimal
`IntEnum` DType factory is likely quite reasonably scoped.
(As a prototype implementation, but I expect adapting to a final
version should be smooth.)
- Sebastian
[1] Maybe as a DType factory in C to create arbitrary `IntEnum` likes,
maybe as parametric DType. I suspect the first
and hope for a better one?
I doubt we can decide on a very clear cut yes/no, but I am very
interested what everyone thinks whether this precision trade-off is too
surprising to users?
Cheers,
Sebastian
___
NumPy-Discussion mailing list -- numpy-di
On Tue, 2023-05-30 at 23:31 -0700, Stefan van der Walt wrote:
> Hi Sebastian,
>
> Could you clarify whether there are now varying code paths, depending
> on the CPU features available?
There is less variation then before because the new code path will be
taken on practically al
On Fri, 2022-10-28 at 10:54 +0200, Sebastian Berg wrote:
> Hi all,
>
> As mentioned earlier, I would like to propose changing the
> representation of scalars in NumPy. Discussion and ideas on changes
> are much appreciated!
>
> The main change is to show scalars as:
&
On Tue, 2023-06-20 at 12:07 -0400, Robert Kern wrote:
> On Tue, Jun 20, 2023 at 11:38 AM Daniel Salles Civitarese <
> sall...@br.ibm.com> wrote:
>
> > ### Proposed new feature or change:
> >
> > I work with geospatial data that requires tensors with many
> > dimensions.
> > One challenge I used t
s Ralf said, you may also have to keep the method indirection (e.g.
because otherwise you break people using `np.around()` on pandas...).
- Sebastian
>
> Aaron Meurer
>
> On Tue, Jul 11, 2023 at 7:38 AM James Webber
> wrote:
> >
> > Hello there! First time posti
ng like a new
kwarg like `include_initial=True`.
This was also discussed here more recently:
https://github.com/data-apis/array-api/issues/597
I think everyone always agreed with such an addition being good. It
terribly be super hard, although the code needs some restructuring to
do it, so not sure it is e
but ignored `copy=` in their
`__array__` methods:
https://github.com/pandas-dev/pandas/issues/57739
It probably makes sense bumping there. NumPy could assume it isn't
correctly implemented, but that would be weird also...
(Objects that did nothing would get correct behavior but with a
Deprec
the future
(but actually doesn't apply directly).
Cheers,
Sebastian
[1] The SPECs are not necessarily fixed. If you think they are missing
a note/solution, we can modify them.
[2] With it's flat namespace, I am not sure e.g. lazy-loading is of
much use to NumPy (just like we have longer
r SPEC 7, I think we certainly should endorse it, exactly because it
is a recommendation for downstream. Even though we have no API where
it applies.
I don't have not formed a strong opinion about the other two yet. For
those, I would agree that it may be a bit odd to "endorse" but no
for that it would be nice if we can see how easy that is, because
while tedious, it may not be all that hard.
- Sebastian
>
> All the best,
>
> Marten
> ___
> NumPy-Discussion mailing list -- numpy-discussion@python.org
> To unsu
s which is also confusing.
I.e. sure, it's bad, but what is the actionable item?
- Sebastian
On Thu, 2024-10-31 at 11:53 +, sverre.hassing--- via NumPy-
Discussion wrote:
> While using the C API to work with Numpy arrays, I came across some
> inconsistencies regarding the return of a
ures
> of a ufunc involve more than having particular methods—they need to
> check
> their arguments and call particular methods: `__array_ufunc__`.
> That's not
> something one can check with `hasattr`.
>
> Sebastian, are you saying that the only definition of "ufunc
That seems like a bug but not sure why it would happen. It needs to
call `__array__`, but indeed of course not with `copy=True`.
Would you open an issue on github?
- Sebastian
On Thu, 2024-12-26 at 03:46 +, Israel, Daniel M via NumPy-
Discussion wrote:
> Sure. I didn’t origina
existing vecdot).
I am more seriously considering whether we should only add them to the
`numpy.linalg` namespace, while `matmul` and `vecdot` are in both
`numpy` and `numpy.linalg`.
(A bit tedious/surprising, but if not used much OK with the "See Also"
section)
- Sebastian
On Tue,
such currently.
- Sebastian
On Tue, 2024-12-31 at 10:20 -0600, Jim Pivarski via NumPy-Discussion
wrote:
> I think you're right: the function `stack`, as you've defined it, is
> a
> gufunc.
>
> Here's an implementation using np.vectorize
> <
> http
27;bug',
> 'feature', 'task'
>
It can be done, but it is part of the org settings, so presumably
limited to very few of us:
https://github.com/organizations/numpy/settings/issue-types
So one of could just add all the ones we currently have some time.
- Sebas
of the inner-loop
since a few year now -- but only casts actually do so).
In the end, `maximum(arr[:, 0], arr[:, 1])` will always the fastest way
for this specific thing, because it explicitly picks the clearly best
approach.
It would be good to close that gap at least a bit, though.
- Sebastian
would slightly prefer to move it, but am OK either way.)
- Sebastian
___
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.pyt
o-one has concerns, I think we'll merge this soon, but I am always
happy to hear opinions!
Cheers,
Sebastian
PS: This PR is about ufuncs, I suppose a few odd functions might
"inherit" it. We may want to allow it for other functions that have an
`out=`, but it
commendation at most and if it was more it would
probably be a mistake there.
- Sebastian
>
> For non-2-dimensional arrays, the replacement for `arr.T` can be
> either: Array API compatible, namely `np.permute_dims(arr,
> range(arr.ndim)[::-1])`, or shorter, NumPy specific:
>
could link to it in the "See also" section for
example.)
- Sebastian
[1] https://github.com/WarrenWeckesser/ufunclab
On Thu, 2025-03-06 at 18:08 +, Carlos Martin wrote:
> Feature request: Add a `bit_width` function to NumPy's [bit-wise
> operations](
> https://n
which is the mechanism/slot for datetime metdata (as you can se the
field is called `c_metadata`).
You have to use that and compile with NumPy 2.x. If you don't want to
compile with NumPy 2.x, you'll have to copy paste the `npy_2_compat.h`
file and include it alway
On Sun, 2025-03-23 at 10:17 +0800, Fang Zhang wrote:
> Sebastian,
>
> I think the core issue you pointed out is indeed correct, but your
> detailed
> explanation is backwards, since `maximum(arr[:, 0], arr[:, 1])`
> implements
Ah, right, I explained things thinking of axis=
a very uncommon need.
(For ufuncs, if you improved stride support `out=` might allow making
the flip no-cost also.)
- Sebastian
>
> - ufunc.accumulate:
> https://numpy.org/doc/stable/reference/generated/numpy.ufunc.accumulate.html
> - cumsum:
> https://numpy.org/doc/stabl
that is a mildly in favor from me when it comes to accepting
such a change, but I am not sure if it will be quite enough to overcome
friction of adding new API.
- Sebastian
>
> This should require only minor modification to the implementation of
> `numpy.pad`. If others like this idea, I
601 - 666 of 666 matches
Mail list logo
