ng)..
Note that I believe all of this type of logic should be moved into a
UFuncImpl [0] object, so that it can be DType (and especially user
DType) specific without bloating up the current UFunc object too much.
Although that puts a lot of power out there, so may be good to limit it
a lot i
Hi all,
There will be a NumPy Community meeting Wednesday September 25 at 11 am
Pacific Time. Everyone is invited to join in and edit the work-in-
progress meeting topics and notes:
https://hackmd.io/76o-IxCjQX2mOXO_wwkcpg?both
Best wishes
Sebastian
BEGIN:VCALENDAR
PRODID:-//Ximian//NONSGML
oject, and at minimum the last thee minor versions."
For the full text, please refer to the link above.
Cheers,
Sebastian
signature.asc
Description: This is a digitally signed message part
___
NumPy-Discussion mailing list
NumPy-Discussion@pyth
Hi all,
There will be a NumPy Community meeting Wednesday October 9 at 11 am
Pacific Time. Everyone is invited to join in and edit the work-in-
progress meeting topics and notes:
https://hackmd.io/76o-IxCjQX2mOXO_wwkcpg?both
Best wishes
Sebastian
BEGIN:VCALENDAR
PRODID:-//Ximian//NONSGML
and running at:
https://berkeley.zoom.us/j/762261535
However, we will send a reminder/logistics email when we start with the
sprint.
Cheers,
Sebastian
signature.asc
Description: This is a digitally signed message part
___
NumPy-Discussion mailing
On Wed, 2019-10-09 at 21:26 -0700, Zijie Poh wrote:
> Hi Sebastian,
>
> It is Tuesday October 15 or Monday October 14?
>
Sorry, its Tuesday the 15th [0]. Monday is a holiday in California at
least.
Cheers,
Sebastian
[0] Probably happens to me because I am still used to weeks s
a replacement. Which should just be a replacement for
`PyArray_GetArrayParamsFromObject` [1].
I have to look at the scalar API, but there may be some candidates
there as well.
Best,
Sebastian
[0] The only thing it seems to do is change how strings are parsed in
`np.asarray` calls. Otherwi
Hi all,
I have to see if that zoom link works, and we probably have to switch
over the day and need some place to write down things, so lets put any
updates here:
https://hackmd.io/kyMr_SHJTAaWsHQGRhJ7hQ
Best,
Sebastian
On Tue, 2019-10-15 at 14:15 +, Hameer Abbasi wrote:
> Is the meet
Sorry for the confusion, we will be using this link:
https://berkeley.zoom.us/j/5416755993
On Tue, 2019-10-15 at 09:00 -0700, Sebastian Berg wrote:
> Hi all,
>
> I have to see if that zoom link works, and we probably have to switch
> over the day and need some place to write dow
for 1.18) 16 issues were closed.
And there are still a couple of PRs hanging which can get wrapped up
soon.
Cheers,
Sebastian
On Wed, 2019-10-09 at 17:55 -0700, Sebastian Berg wrote:
> Hi all,
>
> we are planning to remote spring to try to reduce the number of open
> PRs and is
Hi all,
I am very sorry, I forgot to send out a reminder yesterday with the
sprint going on all day. We will be meeting now, the meeting topics and
notes are:
https://hackmd.io/76o-IxCjQX2mOXO_wwkcpg?both
Best wishes
Sebastian
signature.asc
Description: This is a digitally signed message part
discussion
(such as PR and issue triage) every second week.
Best wishes
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
in sort, but in ordering functions in
> general.
>
Since the standard python functions all have the `reverse` parameter,
it seems like a good idea to me.
I agree that when we add it, it probably would be good to aim for
adding it for all sorting related functions at the same time.
Best,
Se
list since it is an API change. If anyone is concerned please I
will be happy to revert, otherwise this is expected to be included in
1.18.
Cheers,
Sebastian
signature.asc
Description: This is a digitally signed message part
___
NumPy-Discussion mailing
ons/axis as the output
will have.
Maybe we should have had `new_axis=` and `expand_axis=` and you can
only use one ;).
- Sebastian
> Please let me know if you have any questions / suggestions.
>
> Regards,
> ZJ
> ___
> NumPy-Discussio
Hi all,
There will be a NumPy Community meeting Wednesday December 11 at 11 am
Pacific Time. Everyone is invited to join in and edit the work-in-
progress meeting topics and notes:
https://hackmd.io/76o-IxCjQX2mOXO_wwkcpg?both
Best wishes
Sebastian
signature.asc
Description: This is a
;
I agree, if nobody knows any usecase, I am for trying to remove it. It
seems like a Deprecation will not be super simple here. And since there
are no known use-cases, and any new use-case is better covered by
`__array_ufunc__` (and probably also `__array_wrap__`)
On Mon, 2019-12-16 at 13:41 -0600, Sebastian Berg wrote:
> On Mon, 2019-12-16 at 21:01 +0200, Matti Picus wrote:
> > A code path and test have been in the code since NumPy 0.4 for a
> > two-argument variant of ``__array__(dtype=None, context=None)``. It
> > was
> > act
On Thu, 2020-01-02 at 16:51 -0700, Charles R Harris wrote:
> Hi All,
>
> Just want to propose cleaning up the Python 2.7 compatibility code
> for NumPy 1.19. Any objections?
>
Not from me, sounds like a good plan, lets get it over with :).
- Seba
ould discuss this more generally with other
options. IMO deprecating this practically unused thing now does not
mean we cannot do something similar in the future.
- Sebastian
[0] It has its own namespace, so is opt-in for the end user. You can
only support a single backend at a time, although I
Hi all,
After the holiday break, there will be a NumPy Community meeting
Wednesday January 8 at 11 am Pacific Time. Everyone is invited to join
in and edit the work-in-progress meeting topics and notes:
https://hackmd.io/76o-IxCjQX2mOXO_wwkcpg?both
Best wishes
Sebastian
signature.asc
not in {np, dask.numpy_api}:
raise TypeError("This function only supports numpy and Dask.")
```
I do not think this is as cleanly possibly with `__array_function__`.
Best,
Sebastian
On Mon, 2020-01-06 at 20:29 -0800, Stephan Hoyer wrote:
> I am pleased to present a new NumP
masked arrays). The `axis`
argument usually denotes the axis being operated on/along.
- Sebastian
> ___
> NumPy-Discussion mailing list
> NumPy-Discussion@python.org
> https://mail.python.org/mailman/listinfo/numpy-
Hi all,
There will be a NumPy Community meeting Wednesday January 22 at 11 am
Pacific Time. Everyone is invited to join in and edit the work-in-
progress meeting topics and notes:
https://hackmd.io/76o-IxCjQX2mOXO_wwkcpg?both
Best wishes
Sebastian
signature.asc
Description: This is a
[0].
Tools are maybe getting a bit better (e.g. github allows to click on
"view blame before this, although I doubt we ever get somewhere were
they will figure out that something was "just" a style cleanup.
- Sebastian
[0] An example are pytest vs. nose testing
are any cases where it is useful [0]
My idea is to add the deprecation warning now, and if nobody notices it
remove them as soon as 1.19 is released.
- Sebastian
[0] It seems useful for user datatypes/loop, but using it for those
does not seem possible (or at least straight forward), since they
On Fri, 2020-01-24 at 17:56 -0700, Charles R Harris wrote:
>
>
> On Fri, Jan 24, 2020 at 11:29 AM Sebastian Berg <
> sebast...@sipsolutions.net> wrote:
> > Hi all,
> >
> >
> > My idea is to add the deprecation warning now, and if nobody
> &g
Hi all,
Our bi-weekly triage-focused NumPy development meeting is tomorrow
(Wednesday, January 29) at 11 am Pacific Time. Everyone is invited
to join in and edit the work-in-progress meeting topics and notes:
https://hackmd.io/68i_JvOYQfy9ERiHgXMPvg
Best regards,
Sebastian
signature.asc
Hi all,
There will be a NumPy Community meeting Wednesday February 5 at 11 am
Pacific Time. Everyone is invited to join in and edit the work-in-
progress meeting topics and notes:
https://hackmd.io/76o-IxCjQX2mOXO_wwkcpg?both
Best wishes
Sebastian
signature.asc
Description: This is a
le()`, the
array module object/context would preferably be passed around,
hopefully even between libraries. That provides a reasonable way to
opt-in to the new behaviour without a warning (mainly for library
users, end-users can silence the warning if they wish so).
- Sebastian
> The obvious choice
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
hesitation, I can also add this to the
NEP 41 draft. Although I currently feel it is the right thing to do
even if we never had any new dtypes.
- Sebastian
signature.asc
Description: This is a digitally signed message part
___
NumPy-Discussion mailing
sibly
without the `dtype` as a positional argument).
The call your search finds is nice because it must delete `np.dtype`
call.
As is, it is doing the incorrect thing so the deprecation would flush
out a bug.
- Sebastian
> On Fri, Feb 14, 2020 at 2:28 PM Sebastian Berg <
> sebast...@si
should be a contiguous array? I guess it
might include subnormal numbers or NaN?
Can you open an issue with some of those details if you have them?
- Sebastian
> this numpy version
> numpy-1.19.0.dev0%2B20200214184618_1f9ab28-cp38-cp38-
> manylinux2010_x86_64.whl
> is in t
Hi all,
There will be a NumPy Community meeting Wednesday February 19 at 11 am
Pacific Time. Everyone is invited to join in and edit the work-in-
progress meeting topics and notes:
https://hackmd.io/76o-IxCjQX2mOXO_wwkcpg?both
Best wishes
Sebastian
signature.asc
Description: This is a
on this :)
Looks like a good structure to me, I think go ahead and start!
- Sebastian
> --
> Melissa Weber Mendonça
>
> ___
> NumPy-Discussion mailing list
> NumPy-Discussion@python.org
> https://mail.python.org/mailman/listinfo/
reduce(scalar, axis=()) -> array
Of course libraries that do `np.asarray` would/could basically chose to
not preserve scalars: Their signature is defined as taking strictly
array input.
Cheers,
Sebastian
[0] At best this can be a vision to decide which way they may evolve.
[1] E.g. PyT
nswer is just that for datatypes that do not round-trip
easily, `.item()` is probably preferable, and for datatypes that do
round-trip scalars are fine.
- Sebastian
>
> On Fri, Feb 21, 2020 at 5:37 PM Sebastian Berg
> wrote:
> > Hi all,
> >
> > When we create new
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
n x + _helper(len(x))
def generic(x):
module = np.get_array_module(x)
x = module.asarray(x)
return x + _helper(len(x))
def _helper(n, module=np):
return module.random.unform(size=n)
If you try to make the above work with context managers, you _still_
need to pass in the module to _helper [
Hi all,
There will be a NumPy Community meeting Wednesday March 4 at 11 am
Pacific Time. Everyone is invited and encouraged to join in and edit
the work-in-progress meeting topics and notes:
https://hackmd.io/76o-IxCjQX2mOXO_wwkcpg?both
Best wishes
Sebastian
signature.asc
Description: This
at if we want to go there, we would need to push ahead
with the `np.duckarray()` idea instead.
To be clear: I currently very much prefer the get_array_module() idea.
It just seems much cleaner for library authors, and they are the
primary issue at the moment in my opinion.
- Sebastian
> -A
On Sun, 2020-02-23 at 22:44 -0800, Stephan Hoyer wrote:
> On Sun, Feb 23, 2020 at 3:59 PM Ralf Gommers
> wrote:
> >
> > On Sun, Feb 23, 2020 at 3:31 PM Stephan Hoyer
> > wrote:
> > > On Thu, Feb 6, 2020 at 12:20 PM Sebastian Berg <
> > > sebast...@s
array_interface__`, `__array_ufunc__`,
`__array_function__`, `__array_finalize__`, ...
So we are using `__array_*__` for numpy related dunders.
Of course we use most Python defined dunders, but I am not sure that
you are looking for that?
Best,
Sebastian
> Thanks
>
> fun info: i am a
/68i_JvOYQfy9ERiHgXMPvg
I encourage everyone to notify 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
ons in the
future roadmap for NumPy.
The current full text is reproduced below, although the above link is
probably a better way to read it.
Cheers
Sebastian
[1] NEP 40 gives some background information about the current systems
and issues with it:
https://github.com/numpy/
Hi all,
There will be a NumPy Community meeting Wednesday March 18 at 11 am
Pacific Time. Everyone is invited and encouraged to join in and edit
the work-in-progress meeting topics and notes:
https://hackmd.io/76o-IxCjQX2mOXO_wwkcpg?both
Best wishes
Sebastian
PS: The US had its daylight
(extension) MetaClass, all details of this class are supposed
to remain experimental in flux at this time.
Cheers
Sebastian
On Wed, 2020-03-11 at 17:02 -0700, Sebastian Berg wrote:
> Hi all,
>
> I am pleased to propose NEP 41: First step towards a new Datatype
> System https://numpy.
-weekly on Wednesday, I did not anticipate
moving the day itself for now.
This is primarily for the Community and not the Triage meeting.
All the best,
Sebastian
signature.asc
Description: This is a digitally signed message part
___
NumPy-Discussion
ess tangible/approachable.
So, my main point here is that we have to make this large refactor as
approachable as possible, and if that means that at some point someone
has to spend a huge, but hopefully straight forward effort, to rip
DTypes out of NumPy, I think that might be a worthy trade
np.asarray(res)` simply because `res` is N-D but could then be
silently converted to a scalar. E.g. see
https://github.com/numpy/numpy/issues/13105 for an issue about this
(although it does not actually list any specific problems).
- Sebastian
> There is certainly a need for more numpy-like
something similar) to tag on the things it needs
to efficiently use the DTypes (outside the computational engine/UFuncs,
which cover a lot, but unfortunately I do not think everything).
- Sebastian
> Indeed the data storage layer should be able to provide a way to
> store the
> data type repr
s on
what projects can help you or what solutions to look into.
- Sebastian
> I used psutils to determine how much RAM python thinks it has access
> to and
> it return with 1.8 TB approx.
>
> Is there some way I can fix numpy to create these large arrays?
> Thanks for your time and co
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 April 1 at 1(!)pm
Pacific Time. Everyone is invited and encouraged to join in and edit
the work-in-progress meeting topics and notes:
https://hackmd.io/76o-IxCjQX2mOXO_wwkcpg?both
Best wishes
Sebastian
PS: Remember that we will try
is_tuple
I think, since this is a function for library authors more than end-
users. And we do not have much prior art around where to put something
like that.
Cheers,
Sebastian
> > Warren
> >
>
> Answering my own question:
>
> "shape_base.py" is not where
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
at the current type numbers.
Best,
Sebastian
On Wed, 2020-03-11 at 17:02 -0700, Sebastian Berg wrote:
> Hi all,
>
> I am pleased to propose NEP 41: First step towards a new Datatype
> System https://numpy.org/neps/nep-0041-improved-dtype-support.html
>
> This NEP motivates
On Wed, 2020-04-08 at 12:37 -0700, Chris Barker wrote:
> sorry to have fallen off the numpy grid for a bit, but:
>
> On Mon, Mar 23, 2020 at 1:37 PM Sebastian Berg <
> sebast...@sipsolutions.net>
> wrote:
>
> > On Mon, 2020-03-23 at 11:45 -0700, Chris Bar
ed/versioned API front, I would hope that we can defer that
as a semi-orthogonal issue, basically saying that for now you have to
provide a NumPy API that faithfully reproduces whatever NumPy version
is installed on the system.
Cheers,
Sebastian
> Cheers,
> Andy
>
> On 3/3/20 6:34 PM,
On Thu, 2020-04-09 at 13:52 +0200, Ralf Gommers wrote:
> On Wed, Mar 4, 2020 at 1:22 AM Sebastian Berg <
> sebast...@sipsolutions.net>
> wrote:
>
> > On Sun, 2020-02-23 at 22:44 -0800, Stephan Hoyer wrote:
> > > On Sun, Feb 23, 2020 at 3:59 PM Ralf Gomme
On Thu, 2020-04-09 at 13:52 +0200, Ralf Gommers wrote:
> On Thu, Apr 9, 2020 at 12:02 AM Sebastian Berg <
> sebast...@sipsolutions.net>
> wrote:
>
> >
>
> I think it would be nice to have a separate NEP 37 implementation
> outside
> of NumPy to play with
On Thu, 2020-04-09 at 22:11 -0500, Sebastian Berg wrote:
> On Thu, 2020-04-09 at 13:52 +0200, Ralf Gommers wrote:
> > On Thu, Apr 9, 2020 at 12:02 AM Sebastian Berg <
> > sebast...@sipsolutions.net>
> > wrote:
> >
>
> >
> > I think it would
d a
way to transition.
These options do not have to be handled by us, it only helps here with
having context managers to opt-in to new behaviour, and maybe to get an
idea for how transitions can look like.
Alternatively, we could all to create project specific context managers
to do the same an
On Fri, 2020-04-10 at 18:19 +0200, Ralf Gommers wrote:
> On Fri, Apr 10, 2020 at 3:03 PM Sebastian Berg <
> sebast...@sipsolutions.net>
> wrote:
>
> > On Fri, 2020-04-10 at 12:27 +0200, Ralf Gommers wrote:
> > > > 3. I a
Hi all,
There will be a NumPy Community meeting Wednesday April 15th 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:
https://hackmd.io/76o-IxCjQX2mOXO_wwkcpg?both
Best wishes
Sebastian
think
it may not be be uncommon use, so I am not sure we should spend our
deprecation chips/pain on it (if someone wants to try, we can see).
But at least in my opinion it should not be advertised or used in
docs/tutorials, and thus also not typed.
- Sebastian
> Cheers,
> Ralf
> ___
lar class/type.
The point 2. may be independent of the whole scalar story, I am
conflating it here, because to me it applies more naturally in that
context.
Cheers,
Sebastian
[0] See the community meeting agenda document for the link:
https://hackmd.io/76o-IxCjQX2mOXO_wwkcpg
[1] These are thoughts
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
___
NumPy-Discussion mailing list
NumPy-Discussion
list.
I hope we will be able to discuss and reach a consensus between those
interested and involved quickly (possibly already on the next community
call). In either case, before any changes they will be run by the
mailing list to ensure community consensus.
Cheers,
Sebastian
_`.
Under that assumption, it would be an opt-out right now since NumPy
allows copies by default here.
Defining things along copy does seem sensible, though I do not know how
it would play with some of the current array-likes choosing to refuse
`__array__`.
- Sebastian
> Eric
>
> O
On Fri, 2020-04-24 at 10:12 -0700, Stephan Hoyer wrote:
> On Fri, Apr 24, 2020 at 6:31 AM Sebastian Berg <
> sebast...@sipsolutions.net>
> wrote:
>
> > One thing to note is that `__array__` is actually asked to return a
> > copy AFAIK.
>
> The documentation
any usage other than direct typing that may be the better name?
Out of curiousity, I guess `ArrayLike` would be an ABC that a
downstream project can register with?
- Sebastian
>
> Stéfan
> ___
> NumPy-Discussion maili
larity as to whom we would be helping?
If end-users will actually use `np.asarray(..., force=True)` over
special methods, then great! But I am currently not sure the type-
safety argument is all that big of a point. And the performance or
memory-blowup argument remains true even for visualization l
cely.
I am happy to help the end-user in this case, but if that is the target
audience we may want to _discourage_ Napari from using `force=True` and
encourage sparse not to put any RuntimeWarnings on it!
- Sebastian
> Cheers,
> Ralf
>
>
>
> > If end-users will actually use
On Tue, 2020-04-28 at 09:58 -0500, Sebastian Berg wrote:
> On Tue, 2020-04-28 at 11:51 +0200, Ralf Gommers wrote:
>
> > > So arguably, there is no type-safety concern due to `.detach()`.
> >
> > I'm not sure what the question is here; no one mentioned type-
Hi all,
There will be a NumPy Community meeting Wednesday April 29th 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:
https://hackmd.io/76o-IxCjQX2mOXO_wwkcpg?both
Best wishes
Sebastian
On Wed, 2020-04-29 at 05:26 -0500, Juan Nunez-Iglesias wrote:
> Hi everyone, and thank you Ralf for carrying the flag in my absence.
> =D
>
> Sebastian, the *primary* motivation behind avoiding detach() in
> PyTorch is listed in original post of the PyTorch issue:
>
> >
`object` array
will be returned for `np.asarray(["string", 0])` in the future.
But if we know already that we prefer an error, it would be better to
give a DeprecationWarning right away. (It just does not seem nice to
change the same thing twice even if the workaround is identical.)
Cheer
his change, we lose the
> ability to
> concatenate numbers to strings without making intermediate copies.
>
I agree we can do that for concatenate and am happy to add just add it.
Adding the dtype argument (maybe for now only force-casting is fine?)
to `np.concatenate` seems like a reasonable ext
a useful
meaning as an argument to be honest.)
I think I would prefer allowing all of `>`, `B`, and `big`. But change
the documentation to not mention the single letter `B`. And some future
people/us can think about deprecating them in a few years...
In any case, I am absolu
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
___
NumPy-Discussion mailing list
NumPy-Discussion
Hi all,
There will be a NumPy Community meeting Wednesday May 13th 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:
https://hackmd.io/76o-IxCjQX2mOXO_wwkcpg?both
Best wishes
Sebastian
optimize iteration order (although from the
python side I expect we do not want to do that by default).
The reason is also that I am not sure I like `arr.flat` and `for subarr
in arr` too much, because the list-of-list like iteration seems only
semi-natural for an N-D array.
- Sebastian
>
>
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
___
NumPy-Discussion mailing list
NumPy-Discussion
ABI break if anyone subclasses ndarray from C
(extending the struct) and does not very carefully anticipate the
possibility. I am not even sure we support that, but its hard to be
sure...
Cheers,
Sebastian
[1] The size difference should not matter IMO, and with cythons
memoryviews buffers
e overhead is not very
relevant). I am not sure that if the use case is actually big enough
to worry about it, i.e. if you work with complex numbers, you may be
fine with just converting to complex once early on...
- Sebastian
> On Mon, May 25, 2020 at 9:49 AM Eric Wieser <
> wieser.eric
On Mon, 2020-05-25 at 11:10 -0400, Robert Kern wrote:
> On Mon, May 25, 2020 at 10:36 AM Sebastian Berg <
> sebast...@sipsolutions.net>
> wrote:
>
> > On Mon, 2020-05-25 at 10:09 -0400, Brian Racey wrote:
> > > Would a "complex default" mode ever ma
Hi all,
There will be a NumPy Community meeting Wednesday May 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:
https://hackmd.io/76o-IxCjQX2mOXO_wwkcpg?both
Best wishes
Sebastian
On Wed, 2020-05-27 at 18:36 +0200, Ralf Gommers wrote:
> On Fri, May 22, 2020 at 10:14 PM Sebastian Berg <
> sebast...@sipsolutions.net>
> wrote:
>
> I had no idea if we support that, so I crowdsourced some inputs.
>
> Feedback from Travis: "I would be qui
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
NumPy side. I do not have the bandwidth to actually dive into
this for real though.
Cheers,
Sebastian
[1] That is the complexity concerning the NumPy API. I do not know how
complex a blocked iterator itself is.
signature.asc
Description: This is a digitally signed message part
Hi all,
There will be a NumPy Community meeting Wednesday May 27th at 1pm
Pacific Time (20:00 UTC [0]). 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
,
Sebastian
[1] Full table of deprecated aliases:
== =
Deprecated Equivalent to Possibly intended numpy type
== =
``numpy.bool`` ``bool
On Thu, 2020-06-11 at 09:59 -0500, Sebastian Berg wrote:
> Hi all,
>
> In the pull request: https://github.com/numpy/numpy/pull/14882
> Eric proposes to deprecate the type aliases which NumPy imports
> into its main namespace (e.g. np.int, np.bool, see table below [1]).
>
>
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
ble, but may be very slow.
- Sebastian
[0] It is hard to list how exactly it is broadened up, because the
current behaviour has very subtle behaviours, such as actually
iterating a `memoryview()`, which does always the same thing, but only
works for 1-D memoryviews, and fails for both 0-D and
Hi all,
There will be a NumPy Community meeting Wednesday May 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
forward" is very intuitive, but only after pointing out that it
is related to whether the fft or ifft has the normalization factor.
Cheers,
Sebastian
>
> Best,
> Leo
>
>
>
> --
> Sent from: http://numpy-discussion.10968.n7.nabble.com/
> _
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
201 - 300 of 666 matches
Mail list logo
