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
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
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
>
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
>
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
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
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
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
y to big change. 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
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
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
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
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
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:
&
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,
> Sté
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
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
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
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
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
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
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
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
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
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
> &g
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
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
> >
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,
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
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
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 just g
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
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:
*
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
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,
>
> As me
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
.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 downlink and use every bit of
> space,
> but once on the ground
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 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:10 s
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`
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
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 expe
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
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
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:
> >
>
.
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?
>
>
> Hi al
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
lue 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 Sebastian Berg
> wrote:
> >
> > Hi all,
> >
&g
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
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
at 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
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
On Thu, 2022-09-08 at 21:15 -0400, Warren Weckesser wrote:
> On 9/8/22, Andrew Nelson wrote:
>
> >
> > For many types, this function makes an attempt to return a string
> > that would yield an object with the same value when passed to
> > eval();
>
> Sebastian, is this an explicit goal of
ct besides documentation, but
I am not certain.
- Sebastian
> > > > np.array([34.3, 10.1, -0.5], np.float32)
> array([34.3, 10.1, -0.5], dtype=float32)
> > > > np.array([5, 10, 0], np.uint8)
> array([ 5, 10, 0], dtype=uint8)
>
> Thanks,
>
> Pe
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?
Hi all,
I am thinking about the next steps for NEP 50 (The NEP wants to fix the
NumPy promotion rules, especially
On Sat, 2022-09-03 at 00:03 +, lpsm...@uw.edu wrote:
> Sebastian Berg wrote:
> > On Fri, 2022-08-19 at 23:56 +, lpsm...@uw.edu wrote:
> > > Thanks for the information! I've had to work on other project in
> > > the
> > > meantime, but was able to get ba
On Tue, 2022-08-23 at 14:00 +0200, Petr Viktorin wrote:
> On 23. 08. 22 11:46, Sebastian Berg wrote:
> > On Tue, 2022-08-23 at 03:16 +0300, Matti Picus wrote:
> > >
> > > On 22/8/22 18:59, Eric Snow wrote:
> > > > Hi all,
> > > >
> &g
On Tue, 2022-08-23 at 03:16 +0300, Matti Picus wrote:
>
> On 22/8/22 18:59, Eric Snow wrote:
> > Hi all,
> >
> > devs than just me. Do you have any preference for or against any
> > particular venue?
> >
> > Thanks!
> >
> > -eric
> > ___
> >
On Fri, 2022-08-19 at 23:56 +, lpsm...@uw.edu wrote:
> Thanks for the information! I've had to work on other project in the
> meantime, but was able to get back to this again.
>
> In an effort to wrap my head around the project's code, I realized
> that I did not have a line like:
>
>
Hi all,
Last week we had a team meeting at the SciPy conference with part of
the team calling in remotely. The main discussions were about SIMD and
updating our Roadmap.
Most discussion should simply lead to an updated roadmap, but if anyone
is curious, the meeting notes are archived here:
Hi all,
since this week is SciPy and a few of us are there and busy, there will
be no triage meeting on Wednesday.
Cheers
Sebastian
___
NumPy-Discussion mailing list -- numpy-discussion@python.org
To unsubscribe send an email to
On Thu, 2022-07-07 at 22:37 +, lpsm...@uw.edu wrote:
> Hello! I am maintaining a C++ codebase with extensive ties to Python
> bindings (via SWIG). One of the features of the code is that we
> define (in C) a subclass of a NumPy Array. Everything worked until
> we started getting this
On Wed, 2022-06-01 at 08:49 -0700, Sebastian Berg wrote:
> Hi all,
>
> I would like to share the first formal draft of
>
> NEP 50: Promotion rules for Python scalars
>
> with everyone. The full text can be found here:
>
> https://numpy.org/neps/nep
On Tue, 2022-07-05 at 23:36 +, rmccampbe...@gmail.com wrote:
> Maybe I wasn't clear, I'm talking about the 1-dimensional vector
> product, but applied to N-D arrays of vectors. Certainly dot products
> can be realized as matrix products, and often are in mathematics for
> convenience, but
s the old meaning (I think).
One reasoning for me was that users may also read too few data right
now thinking `max_rows` has the new meaning already (i.e. we fix a bug
for them).
Cheers,
Sebastian
On Tue, 2022-02-08 at 08:08 -0600, Sebastian Berg wrote:
> Hi all,
>
> just a brief
On Wed, 2022-06-29 at 12:56 +, Miles Cranmer wrote:
> So, this new method is in fact a hash table as discussed in that blog
> post. However, because it assumes integer arrays, we can go even
> further than that blog, and simply use `np.arange(ar_min, ar_max +
> 1)` is the "hash table". Thus,
Hi all,
Our bi-weekly triage-focused NumPy development meeting is Wednesday,
June 29th at 16:00 UTC (9:00am Pacific Time).
Everyone is invited to join in and edit the work-in-progress meeting
topics and notes:
https://hackmd.io/68i_JvOYQfy9ERiHgXMPvg
I encourage everyone to notify us of issues
ces the old behavior
The new documentation is available at:
https://numpy.org/devdocs/reference/generated/numpy.in1d.html
It seems this addition should be useful in many cases, but if you have
any concern about the choice of API please comment!
Cheers,
Sebastian
On Thu, 2022-06-16 at 06:08 -0700,
> np.sort.
:+1:, I agree with both points. I am also not sure about the choice of
"dictionary", since we don't use a dictionary (or even hashtable)?
(Although I may have missed discussion on the name.)
Cheers,
Sebastian
>
> On Thu, Jun 16, 2022 at 6:14
On Thu, 2022-06-16 at 10:42 +, jesse.p...@raytheon.com wrote:
> When I run it I add the CPPFLAGS=std=-C++11
> Here is the output I get when I added the above flag
> COMMAND: CPPFLAGS=-std=c++11 /awips2/python/bin/python setup.py build
> --cpu-baseline="native" --cpu-dispatch="none"
Sorry, I
Hi all,
there is a PR to add a faster path to `np.isin`, that uses a look-up-
table for all the elements that are included in the haystack
(`test_elements`):
https://github.com/numpy/numpy/pull/12065/files
Such a table means that the memory overhead can be very significant,
but the speedup
On Wed, 2022-06-15 at 15:11 +0300, Matti Picus wrote:
>
> On 14/6/22 18:14, Jesse Peet wrote:
> > I am trying to build numpy 1.22.3 in container using a rhel8 host
> > and
> > the container being rhel7.
> > My version of gcc is 4.8.5-44. Here is the error I get
> >
> > RuntimeError: Broken
Hi all,
Our bi-weekly triage-focused NumPy development meeting is Wednesday,
June 15st at 16:00 UTC (9:00am Pacific Time).
Everyone is invited to join in and edit the work-in-progress meeting
topics and notes:
https://hackmd.io/68i_JvOYQfy9ERiHgXMPvg
I encourage everyone to notify us of issues
On Wed, 2022-06-01 at 18:37 -0500, Juan Nunez-Iglesias wrote:
> > For example, in NumPy:
> >
> > np.median(np.float32([1, 2, 3, 4]))
> >
> > did return a float64 before and will now return a float32. I
> > assume
> > because somewhere we write: `(np.float64(3) + np.float32(2)) / 2`.
>
>
Hi all,
just another small API announcement, that I merged:
https://github.com/numpy/numpy/pull/16154
which adds `symbol="x"` to the polynomial classes. Ross' more detailed
explanation is copied below.
Cheers,
Sebastian
New attribute ``symbol`` added to polynomial classes
Hi all,
this has been discussed before, so mainly a brief announcement that we
merged a PR to add the `equal_nan` kwarg to `np.unique`.
If set to False, multiple `NaN`s will be reported multiple times (which
was the behavior prior to NumPy 1.21).
The keyword argument name was chosen to match
On Wed, 2022-06-01 at 20:23 +0200, Ralf Gommers wrote:
> On Wed, Jun 1, 2022 at 5:51 PM Sebastian Berg
>
> wrote:
>
> >
> > An important part of moving forward will be assessing the real
> > world
> > impact. To start that process, I have created a branch
Hi all,
I would like to share the first formal draft of
NEP 50: Promotion rules for Python scalars
with everyone. The full text can be found here:
https://numpy.org/neps/nep-0050-scalar-promotion.html
NEP 50 is an attempt to remove value-based casting/promotion. We wish
to replace
1 - 100 of 593 matches
Mail list logo
