On Tue, 2025-06-24 at 21:06 +, Carlos Martin wrote:
> It is common to want to pad an array along a *specific* axis.
> Examples:
>
> -
> https://stackoverflow.com/questions/72106542/how-to-pad-the-i-j-axes-of-a-3d-np-array-without-padding-its-k-axis
> -
> https://stackoverflow.com/questions/560
On Sun, 2025-06-08 at 00:40 +, Carlos Martin wrote:
> Add a reverse argument to accumulating functions that, when true,
> causes the accumulation to be performed in reverse. Examples:
Can you describe use cases? Without that, I am not sure I find the
flip solution terrible enough for a very
On Sat, 2025-04-12 at 10:10 +, Mateusz Sokol wrote:
> Hi all!
>
> The Array API standard states that `T` property should only be
> applied to 2-dimensional arrays, in all other cases it should raise
> an error:
> https://data-apis.org/array-api/latest/API_specification/generated/array_api.arra
", end="")
> get_ipython().run_line_magic("timeit",
> "calculate_bbox_normal(vertices)")
> print("Transpose: ", end="")
> get_ipython().run_line_magic("timeit",
> "calculate_bbox_transpose(vertices)"
Hi all,
Since it is an API decision, I have an open PR:
https://github.com/numpy/numpy/pull/28576
To allow `out=...` in ufuncs (yes, three dots, the Ellipsis).
NumPy normally has the bad habit of always returning scalars rather
than 0-D arrays. Passing `out=...` would be one way to ensure arra
Hi all,
it's that time of the year again where daylight savings time starts
(the US had it already and Europe will have it now).
I suggest we "realign" our meeting to this time zone (since it is
scheduled as UTC), I think for our typical crowd that is the nicer time
slot.
(I would slightly prefe
On Fri, 2025-03-21 at 23:22 +0100, Tiziano Zito via NumPy-Discussion
wrote:
> Hi George,
>
> what you see is due to the memory layout of numpy arrays. If you
> switch your array to F-order you'll see that the two functions have
> the same timings, i.e. both are fast (on my machine 25 times faster
Hi all,
I am not as such against adding more bit-wise functions. But, I think
if we do, we probably need to discuss namespaces.
(because adding this is a slippery slope to also adding countr/countl,
etc. Unless we can just decide now to add all and those are actually
few.)
True, `bitwise_` namin
On Mon, 2025-02-24 at 11:30 -0600, Lee Johnston via NumPy-Discussion
wrote:
> We have a C-extension module that works with Datetime DType objects
> through
> the C-API. The existing code works fine for NumPy 1x, but not 2x. The
> NumPy
> 2.0 migration documentation
> <
> https://numpy.org/doc/stabl
On Wed, 2025-01-15 at 13:50 +0200, Matti Picus via NumPy-Discussion
wrote:
>
> On 14/01/2025 19:05, Nathan via NumPy-Discussion wrote:
> > GitHub now has support for "issue types".
>
>
> I couldn't figure out how to customize the types, all I see are
> 'bug',
> 'feature', 'task'
>
It can be
>
> Are there any plans to define "ufunc" as a protocol, rather than a
> type
> that must be inherited to be recognized? Its behaviors are well
> defined at
> this point.
>
> Jim
>
>
> On Thu, Jan 2, 2025, 5:41 AM Sebastian Berg
>
> wrote:
>
>
Stack is not a generalized ufunc.
It may behave similar to one in many ways, but implementation wise has
nothing to do with ufuncs.
Also ufuncs do not support an arbitrary number of operands.
`vectorize` can indeed mimic generalized ufuncs, but (unfortunately)
doesn't create them as such currentl
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 originally, because
Hi all,
I would like to/lean to going ahead with adding these. And in some
discussions I think that was basically the decision, so that is the
default currently.
But, I am not sure that nobody had serious disagreement about it (or
maybe the conjugation part, although I think it drops out of the
The Python C-API almost exclusively uses `-1` for errors and I consider
it a wart that some NumPy API uses `NPY_FAIL`/`NPY_SUCCEED`, i would
not do this for new API.
The one exception are all "argument parsing functions". For those
Python again dictates the use of 0 (NPY_FAIL) and 1 (NPY_SUCCEED)
On Sat, 2024-10-12 at 12:13 -0400, Marten van Kerkwijk wrote:
> Hi Dan, others,
>
> Regardless, since there have been 7 years of
> PendingDeprecationWarning,
> I think changing that to a regular DeprecationWarning should not
> surprise anybody, at least not if they had built a package based on
On Tue, 2024-10-08 at 09:34 +0100, Kevin Sheppard via NumPy-Discussion
wrote:
> Can anyone shed some light on the expected behavior of code using
> array(..., copy=True) with pandas objects? We ran into this in
> statsmodels
> and I think there are probably plenty of places where we explicitly
> ca
only weigh in when it is relevant to our community
> experience
> Matti
>
> On Mon, Oct 7, 2024 at 1:04 PM Sebastian Berg
> wrote:
> >
> > Hi all,
> >
> > TL;DR: NumPy should endorse some or all of the new SPECs if we like
> > them. If you don't
Hi all,
TL;DR: NumPy should endorse some or all of the new SPECs if we like
them. If you don't or do like them, please discuss, otherwise I
suspect we will propose and endorsing them soon and do it if a few core
maintainers agree.
---
The Scientific Python project has the SPEC process to write
On Mon, 2024-08-26 at 11:26 -0400, Marten van Kerkwijk wrote:
> I think a NEP is a good idea. It would also seem to make sense to
> consider how the dtype itself can hold/calculate this type of
> information, since that will be the only way a generic ``info()``
> function can get information for a
Hi all,
please join me in welcoming Joren (https://github.com/jorenham) to the
NumPy maintainers team.
Joren has done a lot of work recently contributing, reviewing, and
maintaining typing related improvements to NumPy.
We are looking forward to see new momentum to improve NumPy typing.
Thanks f
On Fri, 2024-07-12 at 09:56 -0400, Warren Weckesser wrote:
> On Fri, Jul 12, 2024 at 7:47 AM Sebastian Berg
> wrote:
> >
>
> > (You won't be able to know these relations from reading the
> > signature,
> > but I doubt it's worth worrying about
On Thu, 2024-07-11 at 19:31 -0400, Warren Weckesser wrote:
> I have implemented quite a few generalized ufuncs over in ufunclab
> (https://github.com/WarrenWeckesser/ufunclab), and in the process I
> have accumulated a gufunc "wish list". Two items on that list are:
>
> (1) the ability to impose c
The most probably change seems to me that NumPy now includes
`complex.h`. But not sure that is the right direction or why it would
lead to cryptic errors.
- Sebastian
On Wed, 2024-07-03 at 10:30 +0200, PIERRE AUGIER wrote:
> Hi,
>
> We have a strange issue with building pyFFTW with Numpy 2.0
On Mon, 2024-06-10 at 10:49 +0300, Matti Picus wrote:
> What operating system?
>
>
> If I recall correctly, NumPy tries to be compatible with CPython for
> these edge cases.
>
Right, and there seems nothing odd here to me. Try using `divmod()` on
a few numbers (not infinities) to realize that
On Mon, 2024-05-06 at 22:39 +, Henry Schreiner wrote:
> This will be messier for projects building wheels and wanting to
> support non-EoL Python versions. To build a wheel with anything other
> than pybind11, you now need the oldest supported NumPy for Python <
> 3.9, the latest NumPy 1 for Py
On Tue, 2024-05-07 at 11:41 +0200, Gael Varoquaux wrote:
> On Tue, May 07, 2024 at 11:31:02AM +0200, Ralf Gommers wrote:
> > make `pip install scikit-image==0.22` work if that version of
> > scikit-image depends on an unconstrained numpy version.
>
> Would an option be for the scikit-image maintai
On Tue, 2024-05-07 at 15:46 +1000, Juan Nunez-Iglesias wrote:
> On Tue, 7 May 2024, at 7:04 AM, Ralf Gommers wrote:
> > This problem could have been avoided by proper use of upper bounds.
> > Scikit-image 0.22 not including a `numpy<2.0` upper bound is a bug
> > in scikit-image (definitely for ABI
On Mon, 2024-05-06 at 09:17 +1000, Matti Picus wrote:
> On 05/05/2024 11:32, Mark Harfouche wrote:
>
> >
> > Thank you for considering this last minute request. I know it adds
> > work at this stage.
> >
> > Mark
>
>
> I think NumPy should not be the leader in dropping versions, rather
> sh
On Mon, 2024-03-25 at 13:49 +, percynichols...@gmail.com wrote:
> Many thanks!
>
> Just one more inquiry along those lines, if I may. The code asserts
> that clip should outpace np.maximum(mp.minumum(arr, max), min).
> Despite this:
> *time a = np.arange(100)it.clip(4, 20) # 8.48 µs
> %time
On Mon, 2024-01-22 at 17:08 -0700, Nathan wrote:
> Hi all,
>
> I propose we accept NEP 55 and merge PR #25347 implementing the NEP
> in time
> for the NumPy 2.0 RC:
I really like this work and I think it is a big improvement! At this
point we probably have to expect some things to be still bugg
On Sat, 2023-12-23 at 09:56 -0500, Marten van Kerkwijk wrote:
> Hi Sebastian,
>
> > That looks nice, I don't have a clear feeling on the order of
> > items, if
> > we think of it in terms of `(start, stop)` there was also the idea
> > voiced to simply add another name in which case you would allow
On Sat, 2023-12-23 at 09:56 -0500, Marten van Kerkwijk wrote:
> Hi Sebastian,
>
> > That looks nice, I don't have a clear feeling on the order of
> > items, if
> > we think of it in terms of `(start, stop)` there was also the idea
> > voiced to simply add another name in which case you would allow
On Fri, 2023-12-22 at 18:01 -0500, Marten van Kerkwijk wrote:
> Hi Martin,
>
> I agree it is a long-standing issue, and I was reminded of it by your
> comment. I have a draft PR at
> https://github.com/numpy/numpy/pull/25476
> that does not change the old behaviour, but allows you to pass in a
>
Few things in the Python API care about order, but there are also quite
a few places that will return C-order (and are faster for C-order
inputs) whether you change those defaults or not.
The main issue is that e.g. some cython wrappers will probably assume
that the newly created array is C-order.
e. There is no 1.27 planned as of
now, if it happens it would be a (big) backport release, though.
(Due to files having been moved around backports seem to be getting
harder, though.)
- Sebastian
>
> Best, Michael
>
> > On 2. Nov 2023, at 16:25, Sebastian Berg <
> > seb
Hi all,
just a heads up, the PR to change the default integer is merged on
main. This may cause issues, especially with Cython code because
`np.int_t` cannot be reasonably defined anymore.
Other code may also want to vet usage of "long" in any variation. Much
code (like SciPy) simply supports a
Hi all,
there is a PR to merge very limited support for weights in quantiles,
which given no further input I will probably merge based on sklearn
devs saying that they will use it. This means, adding a `weights`
kwarg [1]. See:
https://github.com/numpy/numpy/pull/24254
Limited here means th
On Fri, 2023-09-29 at 11:39 +0200, Klaus Zimmermann wrote:
> Hi,
>
> one thing that's been on my mind about this discussion:
>
> Isn't sorting strings simply a much harder job? Particularly Unicode
> strings?
Yes, but in theory if they are length 1 it is just sorting integers (8
or 64bit) for
On Tue, 2023-08-29 at 08:01 +, Nicolas Holzschuch wrote:
> Hello,
>
> This is my first post to this group; I'd like to start by expressing
> my appreciation for the amazing work in developing and maintaining
> Numpy.
>
> I have a question. Numpy has quite a lot of static local variables
> (
On Fri, 2023-08-11 at 13:43 -0400, Benjamin Root wrote:
> I'm really confused. Summing from zero should be what cumsum() does
> now.
>
What they mean is *including* the "implicit" 0 in the result. There
are some old NumPy issues on this, suggesting something like a new
kwarg like `include_initia
On Thu, 2023-07-13 at 21:53 -0500, Aaron Meurer wrote:
> Does astype make sense as a ufunc?
Yes and no. Implementation wise casting is practically a ufunc.
But there are real semantic differences: Casting _must_ provide the
exact output dtype (something that ufuncs do support, you have to pass
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
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:
&
hat could happen and how the new
trade-offs would be.
- Sebastian
>
> Overall, I feel this is a rather invasive change to NumPy that
> affects results that have been stable for many years, so it warrants
> careful consideration--perhaps even postponing until 2.0?
>
> Best regards,
Hi all,
there was recently a PR to NumPy to improve the performance of sin/cos
on most platforms (on my laptop it seems to be about 5x on simple
inputs).
This changes the error bounds on platforms that were not previously
accelerated (most users):
https://github.com/numpy/numpy/pull/23399
Th
On Mon, 2023-05-29 at 10:55 +1000, Juan Nunez-Iglesias wrote:
> Hi folks,
>
> Apologies if this is documented somewhere, but I haven't been able to
> find it. I've read through NEP-42 [1] and skimmed NEP-41 [2], but I'm
> not sure:
>
> (a) at what point of implementation we are, and
> (b) if it's
Hi all,
On behalf of the steering council, I am very happy to announce that
Nathan has joined us as a Maintainer!
Nathan has been consistently contributing and reviewing NumPy PRs for a
while and is for example actively working on a better string DType
which often means diving into the NumPy core
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
Hi all,
Just in case anyone has an opinion. We just merged:
https://github.com/numpy/numpy/pull/23713/files
That PR makes comparisons like `uint64(2**62) == int64(2**62+1)` exact.
It may seem confusing, why it isn't before. The reason is that NumPy
promotes `uint64` and `int64` to `float6
On Mon, 2023-05-01 at 17:50 +, jmsa...@gmail.com wrote:
> > I think this example shows that you don't need any special
> > infrastructure
> > from numpy. I don't think there is going to be much appetite to
> > expand our
> > API in this direction.
>
> But I do! I'm looking for something that i
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]))
&
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
Hi all,
Unlike conversions of 0-d arrays via:
float(np.array([1]))
conversions of 1-D or higher dimensional arrays with a single element
are a bit strange:
float(np.array([1]))
And deprecating it has come up often enough with many in favor, but
also many worried about the possible ann
On Wed, 2023-03-22 at 12:00 -0400, Robert Kern wrote:
> On Wed, Mar 22, 2023 at 9:34 AM Neal Becker
> wrote:
>
> > I have a function F
> > def F(a, b):
> > c = a * b
> >
> > Initially, a is a scalar, b[240,3000]. No problem.
> > Later I want to use F, where a[240] is a vector. I want to al
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
On Fri, 2023-03-17 at 07:44 +, Ralf Gommers wrote:
> On Thu, Mar 16, 2023 at 7:57 PM Sergio Callegari <
> sergio.calleg...@gmail.com>
> wrote:
>
> > I am trying to use the `clip` method to transform floats to
> > integers with
> > clipping. I was expecting to be able to do both the clipping an
Hi all,
Without concerns voiced, I will probbaly merge the PR:
https://github.com/numpy/numpy/pull/23240
soon. It proposes to dispatch also on the `where=` argument to ufuncs
for __array_ufunc__. This allows a use-case of an "uncertainty"
boolean array (which is not really boolean).
I gues
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:/
On Thu, 2023-03-02 at 15:20 +, Ralf Gommers wrote:
> Hi all,
>
> In https://github.com/numpy/numpy/pull/23314 I am deprecating four
> functions: `product`, `cumproduct`, `alltrue`, `sometrue`. These are
> all
> aliases (for `prod`, `cumprod`, `all` and `any`), were already not
> part of
> the
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
On Tue, 2023-02-14 at 13:07 -0800, Stefan van der Walt wrote:
> On Tue, Feb 14, 2023, at 12:27, Ralf Gommers wrote:
> > Okay, as long as we keep in mind that it should contain all these
> > not-for-main-namespace functions/classes, it seems fine with me. We
> > can live with two namespaces (`types`
On Sat, 2023-02-11 at 11:24 +, Ralf Gommers wrote:
> On Fri, Feb 10, 2023 at 5:35 PM Nathan
> wrote:
>
> > >
> >
> > Small bikeshed: the name np.types indicates to me that it has
> > something to
> > do with static typing. If this namespace only includes dtype
> > classes, then
> > np.dty
Hi all,
I was wondering if we should introduce a new `np.types` namespace. The
main reason is that we have the DType classes, that most users don't
need to worry about. These mirror the scalar classes, but getting them
is weird currently.
I never wanted to put these in the top-level (because I
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 &
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 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
t changes will be done to make this
worthwhile.
* Status: Planning
* Champion: Matti Picus (?), Sebastian Berg (?)
* Severity: Severe (for maintainers without a plan), typical for users
* Affects: Library maintainers, some users
* Notes:Many users may have issues if pip installing a very
On Wed, 2023-01-04 at 04:06 +, Peter Schneider-Kamp wrote:
> Hi guys,
>
> I am trying to understand how the x86 dispatch for ndarray sort
> works. The following call in Line 137 of
> numpy/core/src/npysort/quicksort.cpp returns 0 for my test cases:
>
> if (x86_dispatch::quicksort(start, num))
On Wed, 2022-12-21 at 14:58 +0100, Thibaut Lunet wrote:
> Hi everyone,
>
> I want to vectorize multiple matrix-vector products and avoid a for
> loop, a little bit like np.linalg.solve does, for instance :
>
>
> dimension > 2.
>
> Since np.linalg.solve does this vectorization naturally, I
Hi all,
TL;DR: If nobody has concerns, I think we may give always returning
boolean values for `any()` and `all()` a shot soon (for object input).
Today in the triage meeting, and generally once in a while it comes up
that:
object_arr.any()
object_arr.all()
should always return boolean
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.
>
On Wed, 2022-12-07 at 14:21 -0700, Aaron Meurer wrote:
> Hi all.
>
> As discussed in today's community meeting, I plan to start working on
> adding some useful functions to NumPy which are part of the array API
> standard https://data-apis.org/array-api/latest/index.html.
>
> Although these are a
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
On Fri, 2022-12-02 at 03:42 +0200, Sayed Adel wrote:
> I feel delighted and more motivated to work. I am now working on
> accepting the new reality and organize the tasks entrusted to me.
> Thanks
> to the NumPy team who supported me from the beginning until now.
It is very exciting to have you
Hi all,
there is a discussion about how `round(array)` should behave in:
https://github.com/numpy/numpy/issues/6248
There is some discussion about object arrays which should probably be
fixed for `around()` in that ago.
Otherwise, the is the question what to do about the fact that:
* round
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
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.
- Sebastian
PS
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,
&
On Thu, 2022-11-17 at 17:48 -0800, Stephan Hoyer wrote:
> On Thu, Nov 17, 2022 at 5:29 PM Scott Ransom
> wrote:
> >
> >
>
> Hi Scott,
>
> Thanks for sharing your feedback!
>
> Would you or some of your colleagues be open to helping maintain a
> library
> that adds the 80-bit extended preci
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
ways available to discuss such possibilities, there are
some corners w.r.t. to such bit-sized thoughts which are still shrouded
in fog.
- Sebastian
>
> Greg
>
> [1] Specifically, this is for very low bandwidth satellite data where
> we
> try to pack as much information in the
On Fri, 2022-11-11 at 17:03 +0300, Evgeni Burovski wrote:
> > (2) a more important one, the `.c.src` format. In SciPy we got rid
> > of it, and we're not going to make Meson understand an ad-hoc
> > templating method that only NumPy uses. So we have two choices:
> > also get rid of it, or write a n
uss in NumPy issues or directly).
- Sebastian
>
> BR Oscar
>
> Den tors 10 nov. 2022 kl 15:13 skrev Sebastian Berg <
> sebast...@sipsolutions.net>:
>
> > On Thu, 2022-11-10 at 14:55 +0100, Oscar Gustafsson wrote:
> > > Den tors 10 nov. 2022 kl 13
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 just get dumped in to the main namespace, so why not
make one like `errors` in pandas or `exceptions` in
On Fri, 2022-11-11 at 12:27 +0100, Ralf Gommers wrote:
> Hi all,
>
> With distutils now removed from the stdlib in the Python 3.12 release
> cycle, the clock is ticking a bit for dealing with our build system
> situation. With SciPy's move to Meson now basically complete - there
> are
> always loo
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
On Thu, 2022-11-10 at 11:08 +0100, Oscar Gustafsson wrote:
> >
> > I'm not an expert, but I never encountered rounding floating point
> > numbers
> > in bases different from 2 and 10.
> >
>
> I agree that this is probably not very common. More a possibility if
> one
> would supply a base argumen
ese Python
integers. I will bring this up again also, but it is not directly
related.
On Tue, 2022-10-11 at 14:00 +0200, Sebastian Berg wrote:
> Hi all,
>
> just to mention it, there is a PR ready on this:
>
> https://github.com/numpy/numpy/pull/22385
>
> it necesseci
On Thu, 2022-11-03 at 11:37 +0100, Oscar Gustafsson wrote:
> Hi all,
>
> I hope this is the correct way to propose a new feature.
> https://github.com/numpy/numpy/issues/22522
>
Thanks for the proposal. I don't have much of an opinion on this and
right now I am mainly wondering whether there is
es in repr, I would also be happy to not
do it.
It would make a bit of a presumption that NumPy is the obvious provider
of `int32` (and if others do, they are likely compatible).
- Sebastian
>
> Aaron Meurer
>
> On Fri, Oct 28, 2022 at 2:55 AM Sebastian Berg
> wrote:
> &
wait on NEP approval.
Cheers,
Sebastian
On Thu, 2022-09-08 at 11:38 +0200, Sebastian Berg wrote:
>
> TL;DR: NumPy scalars representation is e.g. `34.3` instead of
> `float32(34.3)`. So the representation is missing the type
> information. What are your thoughts on changing that?
&g
Hi all,
I would like to expose more of the ufunc internals in the following PR:
https://github.com/numpy/numpy/pull/22422/
There are three new proposed functions. I hope the first one can be
generally useful while the last two are very specific (and thus
underscored), but will hopefully bec
hould be a new type of casting rule that
> is non-value based only.
>
> Unless your entire suggestion is to change the definition of 'safe'
> to
> not be value-based. I wasn't completely clear about that.
>
> Aaron Meurer
>
> On Thu, Oct 20, 2022 at 7:30 AM
On Thu, 2022-10-20 at 23:26 +, ntess...@pm.me wrote:
> Hello,
>
Hi,
I don't have a strong opinion yet it does seem potentially useful, but
I think there would be some details to hash out in the proposal.
Some thoughts:
* `np.add.at` should be able to do what you want (but of course is very
Hi all,
I am happy that we have the correct integer handling for NEP 50 merged,
so the relevant parts of the proposal can now be tested. [1]
However, this has highlighted that NumPy has problems with applying the
"cast safety" logic to scalars. We had discussed this a bit yesterday,
and this is
17:24 +0200, Ralf Gommers wrote:
> On Thu, Sep 29, 2022 at 10:10 AM Sebastian Berg
>
> wrote:
>
> > On Wed, 2022-09-28 at 16:44 -0700, Stefan van der Walt wrote:
> > > Hi Sebastian,
> > >
> > > On Wed, Sep 28, 2022, at 12:11, Sebastian Berg wrote:
>
On Wed, 2022-09-28 at 16:44 -0700, Stefan van der Walt wrote:
> Hi Sebastian,
>
> On Wed, Sep 28, 2022, at 12:11, Sebastian Berg wrote:
> > np.array([1, 2], dtype="uint8") + (-1)
> >
> > which currently returns an "int16" array must raise an er
Hi all,
In NEP 50 (https://numpy.org/neps/nep-0050-scalar-promotion.html) my
current proposal is that the following:
np.array([1, 2], dtype="uint8") + (-1)
which currently returns an "int16" array must raise an error. This is
because we want to return a uint8 array but the -1 cannot be
repr
On Thu, 2022-09-08 at 23:19 -0700, Stefan van der Walt wrote:
> I am in favor of such a change. It will make what is returned more
> transparent to users (and reduce confusion for newcomers).
>
> With NEP50, we're already adopting a philosophy of explicit scalar
> usage anyway: no longer pretendi
1 - 100 of 664 matches
Mail list logo
