uss this. The PR allows some
testing of the feature already.
Cheers,
Sebastian
>1. Add a key kwarg to the sort() (function and method). To support
> key
>based sorting on arrays.
>2. Use a new function on the lines off sortby(c_arr,
> key=(c_arr.real,
>
On Wed, 2020-07-01 at 12:48 -0700, Stephan Hoyer wrote:
> On Wed, Jul 1, 2020 at 12:23 PM Sebastian Berg <
> sebast...@sipsolutions.net>
> wrote:
>
> > This is a WIP, but allows nicely to try out how the new API
> > could/should look like, and see the potential im
ead to _really_ understand it:
https://numpy.org/neps/nep-0021-advanced-indexing.html
In general, I wonder if going into much depth about how 0-D arrays are
not actually really handled very special is good. Yes, its confusing
on its own, but it seems also a bit like overloading the user with
unneces
Hi all,
There will be a NumPy Community meeting Wednesday July 8th at 1pm
Pacific Time (20:00 UTC). Everyone is invited and encouraged to
join in and edit the work-in-progress meeting topics and notes at:
https://hackmd.io/76o-IxCjQX2mOXO_wwkcpg?both
Best wishes
Sebastian
signature.asc
in, if just to say hi!
Cheers,
Sebastian
signature.asc
Description: This is a digitally signed message part
___
NumPy-Discussion mailing list
NumPy-Discussion@python.org
https://mail.python.org/mailman/listinfo/numpy-discussion
On Sun, 2020-07-12 at 16:00 +0300, Ram Rachum wrote:
> Hi everyone,
>
> Here's a problem I've been dealing with. I wonder whether NumPy has a
> tool
> that will help me, or whether this could be a useful feature request.
>
> In the upcoming EuroPython 20200, I'll do a talk about live-coding a
> m
ons in NumPy. (see
https://github.com/numpy/numpy/pull/16476)
- Sebastian
On Mon, 2020-06-29 at 01:59 +, Peter Bell wrote:
> > > Honestly, I don't find "forward" very informative. There isn't
> > > any real convention on whether FFT of IFFT have any
>
On Mon, 2020-07-13 at 15:45 +0300, Ram Rachum wrote:
> Thank you Sebastian and Andras for your detailed replies.
>
> Sebastian, your suggestion of adding `item.item()` solved my problem!
> Now
> the for loop is still slower than vectorize, but by a smaller factor,
> and
> t
of issues or PRs that you feel should
be prioritized or simply discussed briefly. Just comment on it so we
can label it, or add your PR/issue to this weeks topics for discussion.
Best regards
Sebastian
signature.asc
Description: This is a digitally signed message part
Hi all,
There will be a NumPy Community meeting Wednesday July 22nd at 1pm
Pacific Time (20:00 UTC). Everyone is invited and encouraged to
join in and edit the work-in-progress meeting topics and notes at:
https://hackmd.io/76o-IxCjQX2mOXO_wwkcpg?both
Best wishes
Sebastian
signature.asc
in
> https://numpy.org/doc/stable/reference/arrays.indexing.html.
>
The reason is because we used to not do this when there are *two*
advanced indices:
arr = np.ones((5, 6))
arr[[], [10, 10]]
giving an empty result. If you check on master (and maybe on
it may
be a bit quicker, but likely still 2 releases?
We are not always good about phasing out deprecations immediately when
it is plausible. The one you mention strikes me as a bigger one though,
so I think we should wait about 2 years. It is plausible that we are
there already, even for a while.
C
need it
because you are testing another package against numpy behaviour!).
So I am happy to merge it if its proposed (maybe its easier for you to
add this to NumPy then work around it in your tests), but I am honestly
concerned that proposing this as a general principle is far more churn
then worth the
On Thu, 2020-07-23 at 10:18 -0500, Sebastian Berg wrote:
> On Wed, 2020-07-22 at 17:35 -0600, Aaron Meurer wrote:
> > > About your warnings, do you have a nice way to do that? The
> > > mechanism
> > > for warnings does not really give a good way to catch that a
>
org/neps/nep-0042-new-dtypes.html
I think you could do much of such syntax now, but I would suggest to do
it outside of NumPy proper (at least the experimentation) at this time
for that reason. Hopefully, it won't be too long until we can think of
creating such API for good inside NumPy.
Cheers,
Se
Hi all,
There will be a NumPy Community meeting Wednesday Agust 5th at 1pm
Pacific Time (20:00 UTC). Everyone is invited and encouraged to
join in and edit the work-in-progress meeting topics and notes at:
https://hackmd.io/76o-IxCjQX2mOXO_wwkcpg?both
Best wishes
Sebastian
signature.asc
assume
that `permuted` as a name and API has largely settle down, and reached
consensus (at last if there is not more activity here or on the PR).
So, as a heads up, I am planning to review and push that forward in the
next days, but more discussion is of course welcome. We still have time
to de
hide it behind an environment variable.
Cheers,
Sebastian
signature.asc
Description: This is a digitally signed message part
___
NumPy-Discussion mailing list
NumPy-Discussion@python.org
https://mail.python.org/mailman/listinfo/numpy-discussion
P draft, at least not without pointing it out.
I will say that I think it is not very high risk, because I think
annoying or not, the argument could be deprecated again with a
transition short phase. Admittedly, that argument only works if we have
a replacement solution.
Cheers,
Sebastian
>
of issues or PRs that you feel should
be prioritized or simply discussed briefly. Just comment on it so we
can label it, or add your PR/issue to this weeks topics for discussion.
Best regards
Sebastian
signature.asc
Description: This is a digitally signed message part
ntion yet. Maybe because nobody had much
concerns about it yet, or maybe it was just lower on the priority list.
To be clear: I am fully prepared to pull this out of master before
release or probably rather disable it in release versions. An
alternative could be an environment variable (an env variabl
()` in slices, because Python did not. But now Python
caught up.
- Sebastian
[1] I have never seen anyone index with a bool, and I have no
conception of what `arr[masked:not_masked]` would mean.
There is not a small step from `arr[True]` to `arr[True:]`.
On Thu, 2020-08-13 at 15:14 -0600, Aaron
Hi all,
There will be a NumPy Community meeting Wednesday Agust 19th at 1pm
Pacific Time (20:00 UTC). Everyone is invited and encouraged to
join in and edit the work-in-progress meeting topics and notes at:
https://hackmd.io/76o-IxCjQX2mOXO_wwkcpg?both
Best wishes
Sebastian
signature.asc
ray without first calling `nonzero` isn't really whats going
on. And I don't know how it could be whats going on, since adding
dimensions to a boolean index would have much more implications?
- Sebastian
> (and scalar ints) are broadcast together, *except* for boolean
> scalars. T
s the better
choice. My initial choice was that this would be an error as well, and
I still slightly prefer it, but don't feel it matters much.
- Sebastian
>
> Aaron Meurer
>
> On Thu, Jul 23, 2020 at 12:18 PM Aaron Meurer
> wrote:
> > > After writing this, I real
, is that I tried to do be minimal in the changes
when I rewrote advanced indexing (and generalized boolean scalars
correctly) long ago. That was likely the right start/choice at the
time, since there were much bigger fish to catch, but I do not think
anything is holding us back now.
Cheers,
Sebastian
>
On Thu, 2020-08-20 at 16:50 -0500, Sebastian Berg wrote:
> On Thu, 2020-08-20 at 12:21 -0600, Aaron Meurer wrote:
> > You're right. I was confusing the broadcasting logic for boolean
> > arrays.
> >
> > However, I did find this example
> >
> > > &g
ho may have
found a use for this type of nugget to use `np.nonzero()` or find
another solution.
- Sebastian
>
> Aaron Meurer
>
> On Thu, Aug 20, 2020 at 3:56 PM Sebastian Berg
> wrote:
> > On Thu, 2020-08-20 at 16:50 -0500, Sebastian Berg wrote:
> > > On Thu, 2020-
On Thu, 2020-08-20 at 17:08 -0600, Aaron Meurer wrote:
> On Thu, Aug 20, 2020 at 4:38 PM Sebastian Berg
> wrote:
> > On Thu, 2020-08-20 at 16:00 -0600, Aaron Meurer wrote:
> > > Just to be clear, what exactly do you think should be deprecated?
> > > Boolean scal
On Mon, 2020-08-24 at 15:31 -0600, Aaron Meurer wrote:
> On Wed, Aug 19, 2020 at 8:18 PM Sebastian Berg
> wrote:
> > On Wed, 2020-08-19 at 19:37 -0600, Aaron Meurer wrote:
> > > These cases don't give any deprecation warnings in NumPy master:
> > >
> >
of issues or PRs that you feel should
be prioritized or simply discussed briefly. Just comment on it so we
can label it, or add your PR/issue to this weeks topics for discussion.
Best regards
Sebastian
signature.asc
Description: This is a digitally signed message part
Hi all,
There will be a NumPy Community meeting Wednesday September 2nd at 1pm
Pacific Time (20:00 UTC). Everyone is invited and encouraged to
join in and edit the work-in-progress meeting topics and notes at:
https://hackmd.io/76o-IxCjQX2mOXO_wwkcpg?both
Best wishes
Sebastian
signature.asc
us of issues or PRs that you feel should
be prioritized or simply discussed briefly. Just comment on it so we
can label it, or add your PR/issue to this weeks topics for discussion.
Best regards
Sebastian
signature.asc
Description: This is a digitally signed message part
Hi all,
There will be a NumPy Community meeting Wednesday September 16th at 1pm
Pacific Time (20:00 UTC). Everyone is invited and encouraged to
join in and edit the work-in-progress meeting topics and notes at:
https://hackmd.io/76o-IxCjQX2mOXO_wwkcpg?both
Best wishes
Sebastian
A PR is welcome! If you have the time, it may help to summarize the
potential issues/solutions on the list so that it is easier to make a
decision. It might also help to have a few more users involved who use
datetimes more actively. I do not use them v
us of issues or PRs that you feel should
be prioritized or simply discussed briefly. Just comment on it so we
can label it, or add your PR/issue to this weeks topics for discussion.
Best regards
Sebastian
signature.asc
Description: This is a digitally signed message part
but it was long decided that it will remain a SyntaxError.
For the question at hand, it seems to me that mixing labeled and
unlabeled indexing would be an error for array-like objects.
In that case, the worst we get seems a quirk where `arr[None, x=4]` is
not an error, when it should be an error.
T
; and I am not aware of
> any
> corner cases.
There may not be, I think this had to do with how we approached certain
difficulties in the PR (around viewing as int64 or using floats,
probably). We just should make sure to have tests for both start and
end being NaT.
Maybe NaT is not a big i
Hi all,
There will be a NumPy Community meeting Wednesday September 16th at 1pm
Pacific Time (20:00 UTC). Everyone is invited and encouraged to
join in and edit the work-in-progress meeting topics and notes at:
https://hackmd.io/76o-IxCjQX2mOXO_wwkcpg?both
Best wishes
Sebastian
issues or PRs that you feel should
be prioritized, discussed, or reviewed.
Best regards
Sebastian
signature.asc
Description: This is a digitally signed message part
___
NumPy-Discussion mailing list
NumPy-Discussion@python.org
https
decisions and
explanations.
Cheers,
Sebastian
PS: In some places NEP 42 references NEP 43, for which I hope to merge
the draft soon, the current status is here:
https://github.com/numpy/numpy/pull/16723
However, this should be mainly interested for those wishin
that cannot be done
as an extension/protocol later (like the `arr.astype(Unitless)` cast,
which should be a straight forward extension).
Although, it would be interesting to figure out how a future Unit DType
would best look in this regard!
Cheers,
Sebastian
> functions that allow the subclass
ce
of a minimal API. I have pasted the doc-string (html, hope that works
fine) below to allow a quicker idea of what is being proposed. To me
it looks good! (I wonder if we need `subok`, but I guess we probably
do.)
Cheers,
Sebastian
numpy.sliding_window_viewnumpy.sliding_window_view(x, wind
of issues or PRs that you feel should
be prioritized, discussed, or reviewed.
Best regards
Sebastian
signature.asc
Description: This is a digitally signed message part
___
NumPy-Discussion mailing list
NumPy-Discussion@python.org
https://mail.python.org
ted with numpy removed...
# I manuall deleted sudo rm -rf /usr/include/numpy, but I do not think it
should have been there?!
#include_directories(${SOURCE_FILES}
/home/sebastian/venvs/pydbg-clean/include/python3.8d)
include_directories(${SOURCE_FILES} /usr/include/python3.8)
add_executable(asdf
Hi all,
On Thu, 2020-10-08 at 07:51 -0500, Sebastian Berg wrote:
> Hi all,
>
> after another thorough revision of NEP 42 (much thanks to Ben!), I
> propose accepting the NEP, with the note that details are expected
> change.
>
> I am always happy to clarify and review
Hi all,
There will be a NumPy Community meeting Wednesday October 27th at 1pm
Pacific Time (20:00 UTC). Everyone is invited and encouraged to
join in and edit the work-in-progress meeting topics and notes at:
https://hackmd.io/76o-IxCjQX2mOXO_wwkcpg?both
Best wishes
Sebastian
signature.asc
ike this
> implemented? Is it simple enough that we can just work out the
> details
> here and on a pull request, or should I write a NEP?
A short NEP may make sense, at least if this is supposed to be a
generic protocol for general array-likes, which I guess it would have
to be r
On Thu, 2020-10-29 at 23:58 -0600, Aaron Meurer wrote:
> On Thu, Oct 29, 2020 at 6:09 PM Sebastian Berg
> wrote:
> > On Tue, 2020-10-27 at 17:15 -0600, Aaron Meurer wrote:
> > > For ndindex (https://quansight.github.io/ndindex/), the biggest
> > > issue
> &
because NumPy still has it, so that NumPy
not being conservative actually helps everyone?
- Sebastian
> Thanks all,
>
> Juan.
>
> On Mon, 2 Nov 2020, at 2:01 AM, Ralf Gommers wrote:
> >
> > On Mon, Nov 2, 2020 at 7:47 AM Stephan Hoyer
> > wrote:
> >
of issues or PRs that you feel should
be prioritized, discussed, or reviewed.
Best regards
Sebastian
signature.asc
Description: This is a digitally signed message part
___
NumPy-Discussion mailing list
NumPy-Discussion@python.org
https
to be clear that
this type of project patches/modifies NumPy and is not associated with
it directly.
It seams `pnumpy` is currently taken on PyPI with a small amount of
downloads: https://pypistats.org/packages/pnumpy
(Although I wonder how many are actual users.), though.
Cheers,
Seba
decision, please just bring it up so we can
reconsider.
Cheers,
Sebastian
PS: We may keep testing on 3.6 for the moment, at least for PyPy for
technical reasons.
On Tue, 2020-11-03 at 11:58 -0800, Brigitta Sipocz wrote:
> Hi,
>
> For what it's worth, python 3.6 is also dropped f
time for feedback in case you have a better idea
e.g. for the function or parameter names.
Cheers,
Sebastian
On Mon, 2020-10-12 at 08:39 +, Zimmermann Klaus wrote:
> Hello,
>
> I would like to draw the attention of this list to PR #17394 [1] that
> adds the implementation
On Thu, 2020-11-05 at 12:51 -0800, Stephan Hoyer wrote:
> On Thu, Nov 5, 2020 at 11:16 AM Ralf Gommers
> wrote:
>
> >
> > On Thu, Nov 5, 2020 at 4:56 PM Sebastian Berg <
> > sebast...@sipsolutions.net>
> > wrote:
> >
> > > Hi all,
>
On Thu, 2020-11-05 at 17:35 -0600, Sebastian Berg wrote:
> On Thu, 2020-11-05 at 12:51 -0800, Stephan Hoyer wrote:
> > On Thu, Nov 5, 2020 at 11:16 AM Ralf Gommers <
> > ralf.gomm...@gmail.com>
> > wrote:
> >
> > > On Thu, Nov 5, 2020 at 4:56 PM Sebasti
Hi all,
There will be a NumPy Community meeting Wednesday November 11th at 1pm
Pacific Time (20:00 UTC). Everyone is invited and encouraged to
join in and edit the work-in-progress meeting topics and notes at:
https://hackmd.io/76o-IxCjQX2mOXO_wwkcpg?both
Best wishes
Sebastian
signature.asc
ture, lets
discuss these as well!
Cheers,
Sebastian
[1] The functions which receive the keyword argument are:
* np.array, np.asarray, np.ascontiguousarray, etc.
* np.arange
* np.ones, np.zeros, np.empty, np.full
* np.fromfunction
* np.identity
* np.fromfile
* ... a
of issues or PRs that you feel should
be prioritized, discussed, or reviewed.
Best regards
Sebastian
signature.asc
Description: This is a digitally signed message part
___
NumPy-Discussion mailing list
NumPy-Discussion@python.org
https
r
> > of
> > * releases. Direct access to the members themselves is
> > deprecated.
> > * To ensure that your code does not use deprecated access,
> > * #define NPY_NO_DEPRECATED_API NPY_1_7_API_VERSION
> > * (or NPY_1_8_API_VERSION or higher as require
machines (clusters, workstations) should maybe be audited for
performance. Yes! (Although even then, reduces tend to get used, no
matter how much you have!)
As for actually doing something to reduce the carbon footprint, I think
the vast majority of our users would have more impact if they thrott
e.
So, I could possibly argue that the most important thing may well be
accessibility of algorithms. And I think that is what a large chunk of
Scientific Python packages are all about.
Whether or not that has an impact on the environment...
Cheers,
Sebastian
[1] This was the first resour
Hi all,
There will be a NumPy Community meeting Wednesday November 25th at 12pm
Pacific Time (19:00 UTC). Everyone is invited and encouraged to
join in and edit the work-in-progress meeting topics and notes at:
https://hackmd.io/76o-IxCjQX2mOXO_wwkcpg?both
Best wishes
Sebastian
signature.asc
of issues or PRs that you feel should
be prioritized, discussed, or reviewed.
Best regards
Sebastian
signature.asc
Description: This is a digitally signed message part
___
NumPy-Discussion mailing list
NumPy-Discussion@python.org
https
anyones code.
3. NumPy should not check the *validity* of the arguments. For example:
`np.add.reduce(xarray, axis="long")` should probably work in xarray.
(`xarray.DataArray` does not actually implement the above.)
But a string cannot be used as an axis in NumPy.
Cheers,
Seb
und was `pip install numpy==1.19.3`, which uses a
different OpenBLAS that avoids the worst of the windows bug.
- Sebastian
>
> On Thu, Dec 3, 2020 at 12:57 AM Alan G. Isaac
> wrote:
>
> > numpy 1.19.3 installs fine.
> > numpy 1.19.4 appears to install but does not wo
On Wed, 2020-12-02 at 21:07 -0800, Stefan van der Walt wrote:
> Hi Sebastian,
>
> Looking at these three rules, they all seem to stem from one simple
> question: do we desire for a single code snippet to be runnable on
> multiple array implementations?
>
> On Wed,
On Sat, 2020-12-05 at 20:12 -0700, Charles R Harris wrote:
> On Sat, Dec 5, 2020 at 4:31 PM Juan Nunez-Iglesias
> wrote:
>
> > Hi all,
> >
> > At the prodding [1] of Sebastian, I’m starting a discussion on the
> > decision to deprecate np.{bool,float,int
On Sat, 2020-12-05 at 22:05 -0800, Stephan Hoyer wrote:
> On Wed, Dec 2, 2020 at 3:39 PM Sebastian Berg <
> sebast...@sipsolutions.net>
> wrote:
>
> > 1. If an argument is invalid in NumPy it is considered and error.
> >For example:
> >
> >
important points have even been included in NumPy itself.
That leaves still a lot of freedom to modify the final public API, but
that is not the most important part with respect to moving forward.
I have opened a PR to that affect:
https://github.com/numpy/numpy/pull/17953
Cheers,
Sebastian
Hi all,
There will be a NumPy Community meeting Wednesday December 9th at 12pm
Pacific Time (20:00 UTC). Everyone is invited and encouraged to
join in and edit the work-in-progress meeting topics and notes at:
https://hackmd.io/76o-IxCjQX2mOXO_wwkcpg?both
Best wishes
Sebastian
signature.asc
make headway...
Any thoughts or clarity remaining that I can try to confuse? :)
Cheers,
Sebastian
[0] We could use the reordering trick also for concrete DTypes,
although, that would require introducing some kind of priority... I do
not like that much as public API, but it might be somethin
g` right away, but I don't mind
taking it slow.
Cheers,
Sebastian
[1] I admit, probably almost nobody would notice. And usually using a
Python `bool` is better...
>
> Aaron Meurer
>
> On Sat, Dec 5, 2020 at 4:31 PM Juan Nunez-Iglesias
> wrote:
> > Hi all,
> &g
On Wed, 2020-12-09 at 13:37 -0800, Stephan Hoyer wrote:
> On Wed, Dec 9, 2020 at 1:07 PM Aaron Meurer
> wrote:
>
> > On Wed, Dec 9, 2020 at 9:41 AM Sebastian Berg
> > wrote:
> > >
> > > On Mon, 2020-12-07 at 14:18 -0700, Aaron Meurer wrote:
> > &g
On Thu, 2020-12-10 at 20:38 +0100, Ralf Gommers wrote:
> On Thu, Dec 10, 2020 at 7:25 PM Sebastian Berg <
> sebast...@sipsolutions.net>
> wrote:
>
> > On Wed, 2020-12-09 at 13:37 -0800, Stephan Hoyer wrote:
> > > On Wed, Dec 9, 2020 at 1:07 PM Aaron Meurer
> &
On Fri, 2020-12-11 at 12:09 +0100, Ralf Gommers wrote:
> On Wed, Dec 9, 2020 at 5:22 PM Sebastian Berg <
> sebast...@sipsolutions.net>
> wrote:
>
> > Hi all,
> >
> > Sorry that this will again be a bit complicated again :(. In brief:
> >
> &g
On Fri, 2020-12-11 at 11:35 +0100, Ralf Gommers wrote:
> On Thu, Dec 10, 2020 at 9:00 PM Sebastian Berg <
> sebast...@sipsolutions.net>
> wrote:
>
> Just deprecation `np.int` may make sense. That will already raise
> awareness, and leaving `np.float` as-is may preve
opposed to 32bit or 64bit depending on the
whims of the user; or `intp` because it is "indexing related".
It would be interesting to see if we can change the default at some
point. It might also be tricky: There may be quite a bit of code
expecting `long` (e.g. Cython extensions or `scipy
On Sun, 2020-12-13 at 19:00 +1100, Juan Nunez-Iglesias wrote:
>
>
> > On 13 Dec 2020, at 6:25 am, Sebastian Berg <
> > sebast...@sipsolutions.net> wrote:
> >
> > But "default" in NumPy really doesn't mean a whole lot? I can
> > think of
of issues or PRs that you feel should
be prioritized, discussed, or reviewed.
Best regards
Sebastian
signature.asc
Description: This is a digitally signed message part
___
NumPy-Discussion mailing list
NumPy-Discussion@python.org
https
On Tue, 2020-12-15 at 13:45 -0600, Sebastian Berg wrote:
> Hi all,
>
> Our bi-weekly triage-focused NumPy development meeting is today
> (Wednesday, November 18th) at 11 am Pacific Time (19:00 UTC).
Maybe I won't forget to update this next time. Of course tomorrow
December 16th
hoc to me when I first learned about it and of course
it is not always clear if something is low or moderate risk. But I do
like that it gives *some* formalization. Note that IIRC the ISO
standard does not even attempt to say what categories a specific
product development should use.
(I think this
On Wed, 2020-12-30 at 11:43 -0600, Sebastian Berg wrote:
> On Wed, 2020-12-30 at 16:27 +0100, Ralf Gommers wrote:
> >
> > That's very hard to describe, since it relies so much on previous
> > experience and qualitative judgements. That's the main reason why I
&
On Sat, 2021-01-02 at 18:06 +0100, Ralf Gommers wrote:
> On Sat, Jan 2, 2021 at 3:55 AM Sebastian Berg <
> sebast...@sipsolutions.net>
> wrote:
>
> > On Wed, 2020-12-30 at 11:43 -0600, Sebastian Berg wrote:
> >
> > On Wed, 2020-12-3
Hi all,
There will be a NumPy Community meeting Wednesday January 6th at 12pm
Pacific Time (20:00 UTC). Everyone is invited and encouraged to
join in and edit the work-in-progress meeting topics and notes at:
https://hackmd.io/76o-IxCjQX2mOXO_wwkcpg?both
Best wishes
Sebastian
signature.asc
o eventually make it public (or even allow
overriding it) [2]. That is lower priority though, since we could get
away with keeping it private API for a while.
Cheers,
Sebastian
[1] That may need some thought: If others provide the struct (and not
just consume it like a ufunc/dtype author), they
int at cython or
numba/transonic.
Cheers,
Sebastian
>
> 09.01.2021, 22:30, "Joseph Fox-Rabinovitz"
> :
> What other ways have you tried?
>
> On Sat, Jan 9, 2021 at 2:15 PM wrote:
> > Hello. There is a random 1D array m_0 with size 3000, for example:
> &
does that for you. Unless you want to optimize
that conversion away?
Cheers,
Sebastian
> data, but that seems daunting and error prone. Is there a way I can
> achieve
> this and have scalar arguments passed to np.PyArray_MultiIter_DATA be
> converted to same-element arr
different dtype, it would allow you to cast in a buffered
way (much better if you expect large arrays, likely not for smaller
ones):
https://numpy.org/doc/stable/reference/c-api/iterator.html#simple-iteration-example
Hope this helps.
Cheers,
Sebastian
--
Sent from: http://numpy-discussi
issues or PRs that you feel should
be prioritized, discussed, or reviewed.
Best regards
Sebastian
signature.asc
Description: This is a digitally signed message part
___
NumPy-Discussion mailing list
NumPy-Discussion@python.org
https://mail.python.org
f the dispatching in
NumPy.
Note that NumPy arrays cannot be distributed or gpu backed, and you
cannot add using a subclass. So if that is the aim, do not subclass
ndarray unless you were prepared to create multiple (sub)classes
(ndarray, dask array, cupy array).
Cheers,
Sebastian
>
> Advice
Hi all,
There will be a NumPy Community meeting Wednesday January 20th at 12pm
Pacific Time (20:00 UTC). Everyone is invited and encouraged to
join in and edit the work-in-progress meeting topics and notes at:
https://hackmd.io/76o-IxCjQX2mOXO_wwkcpg?both
Best wishes
Sebastian
signature.asc
uot;limit to Python operators" is
something we should aim for here. This does make a small difference,
because user DTypes could "live" in the future if we have an idea of
how that future may look like.
Cheers,
Sebastian
signature.asc
Description: This is a digitally signed me
On Tue, 2021-01-26 at 06:11 +0100, Ralf Gommers wrote:
> On Tue, Jan 26, 2021 at 2:01 AM Sebastian Berg <
> sebast...@sipsolutions.net>
> wrote:
>
> > Hi all,
> >
> > does anyone have a thought about how user DTypes (i.e. DTypes not
> > currently part
PRs that you feel should
be prioritized, discussed, or reviewed.
Best regards
Sebastian
signature.asc
Description: This is a digitally signed message part
___
NumPy-Discussion mailing list
NumPy-Discussion@python.org
https://mail.python.org/mailman
On Wed, 2021-01-27 at 10:33 +0100, Ralf Gommers wrote:
> On Tue, Jan 26, 2021 at 10:21 PM Sebastian Berg <
> sebast...@sipsolutions.net>
> wrote:
>
Thanks for all the other comments, they are helpful. I am considering
writing a (hopefully short) NEP, to define the directio
On Wed, 2021-01-27 at 18:16 +0100, Ralf Gommers wrote:
> On Wed, Jan 27, 2021 at 5:44 PM Sebastian Berg <
> sebast...@sipsolutions.net>
> wrote:
>
> > On Wed, 2021-01-27 at 10:33 +0100, Ralf Gommers wrote:
> > > On Tue, Jan 26, 2021 at 10:21 PM Sebastian Berg &
Hi all,
There will be a NumPy Community meeting Wednesday February 3rd at 12pm
Pacific Time (20:00 UTC). Everyone is invited and encouraged to
join in and edit the work-in-progress meeting topics and notes at:
https://hackmd.io/76o-IxCjQX2mOXO_wwkcpg?both
Best wishes
Sebastian
signature.asc
the individual function as `.. versionchanged::`)
I am thinking just a table with:
* version changed
* short description
* affected functions
* how the stream changed (if that is ever relevant)
Cheers,
Sebastian
> Kevin
>
>
> From: Robert Kern
> Sent: Monday, Feb
PRs that you feel should
be prioritized, discussed, or reviewed.
Best regards
Sebastian
signature.asc
Description: This is a digitally signed message part
___
NumPy-Discussion mailing list
NumPy-Discussion@python.org
https://mail.python.org/mailman
301 - 400 of 666 matches
Mail list logo
