On Sat, 2018-10-27 at 19:29 +1300, Ralf Gommers wrote:
>
>
> On Sat, Oct 27, 2018 at 6:37 PM Eric Wieser <
> wieser.eric+nu...@gmail.com> wrote:
> > > in order to be used prior to calling C or Fortran code that
> > > expected at least a 1-d array
> > >
> >
>
>
> > > I'm a big supporter of m
On Wed, 2018-11-14 at 14:32 -0500, Marten van Kerkwijk wrote:
> Code being better than words: see
> https://github.com/numpy/numpy/pull/12388 for an implementation. The
> change in the code proper is very small, though it is worrying that
> it causes two rather unrelated tests too fail (even if ar
On Wed, 2018-11-14 at 14:46 -0800, Stephan Hoyer wrote:
>
>
> On Wed, Nov 14, 2018 at 2:35 PM Sebastian Berg <
> sebast...@sipsolutions.net> wrote:
> > On Wed, 2018-11-14 at 14:32 -0500, Marten van Kerkwijk wrote:
> > some old issue or even PR somewhere.
> >
Hi all,
In https://github.com/numpy/numpy/pull/11897 I am looking into the
addition of a `copy=np.never_copy` argument to:
* np.array
* arr.reshape/np.reshape
* arr.astype
Which would cause an error to be raised when numpy cannot guarantee
that the returned array is a view of the input arra
On Wed, 2018-12-26 at 16:40 -0800, Ralf Gommers wrote:
>
>
> On Wed, Dec 26, 2018 at 3:29 PM Sebastian Berg <
> sebast...@sipsolutions.net> wrote:
> > Hi all,
> >
> > In https://github.com/numpy/numpy/pull/11897 I am looking into the
> > addi
"never"
> The implementation of np.never_copy is a little verbose / ugly
> Eric
>
> On Thu, Dec 27, 2018, 1:41 AM Ralf Gommers wrote:
>
> >
> > On Wed, Dec 26, 2018 at 3:29 PM Sebastian Berg <
> > sebast...@sipsolutions.net> wrote:
> > &
On Thu, 2018-12-27 at 17:45 -0800, Nathaniel Smith wrote:
> On Thu, Dec 27, 2018 at 3:27 PM Juan Nunez-Iglesias <
> jni.s...@gmail.com> wrote:
> > On Fri, Dec 28, 2018, at 3:40 AM, Sebastian Berg wrote:
> >
> > > It’s consistent with np.newaxis in spelling (modulo
On Sat, 2018-12-29 at 17:16 +0100, Matthias Geier wrote:
> Hi Sebastian.
>
> I don't have an opinion (yet) about this matter, but I have a
> question:
>
> On Thu, Dec 27, 2018 at 12:30 AM Sebastian Berg wrote:
>
> [...]
>
> > new_arr = arr.reshape(new_sha
On Sun, 2018-12-30 at 16:03 +0100, Matthias Geier wrote:
> On Sat, Dec 29, 2018 at 6:00 PM Sebastian Berg wrote:
> > On Sat, 2018-12-29 at 17:16 +0100, Matthias Geier wrote:
> > > Hi Sebastian.
> > >
> > > I don't have an opinion (yet) about
On Wed, 2019-01-02 at 11:27 +0100, Matthias Geier wrote:
> Hi Sebastian.
>
> Thanks for the clarification.
>
> > print(arr.shape) # also (5, 2)
> >
> > so the arr container (shape, dtype) is changed/muted. I think we
> > expect
> > that for content here, but not for the shape.
>
> Thanks for
On Mon, 2019-01-07 at 20:04 +0100, Matthias Geier wrote:
> On Wed, Jan 2, 2019 at 2:24 PM Sebastian Berg wrote:
> > On Wed, 2019-01-02 at 11:27 +0100, Matthias Geier wrote:
> > > Hi Sebastian.
> > >
> > > Thanks for the clarification.
> > >
On Mon, 2019-01-07 at 12:15 -0800, Keith Goodman wrote:
> Numpy uses pairwise summation along the fast axis if that axis
> contains no more than 8192 elements. How was 8192 chosen?
>
It is simply a constant used throughout the ufunc machinery (and
iteration) for cache friendliness.
However, that
On Fri, 2019-01-11 at 13:57 +1100, Juan Nunez-Iglesias wrote:
>
>
> > On 10 Jan 2019, at 6:35 pm, Todd wrote:
> >
> > Could this approach be used to deprecate `ravel` and let us just
> > use `flatten`?
>
>
> Could we not? `.ravel()` is everywhere and it matches
> `ravel_multi_index` and `unra
On Fri, 2019-01-11 at 12:32 -0800, Keith Goodman wrote:
> I remember back when a.sum(axis=0) was much slower than a.sum(axis=1)
> for something like a=np.ones((1000, 1000)). But now it runs in about
> the same time. How does numpy do it?
>
"now" is since numpy 1.7 or so :).
> Does numpy do somet
Hi all,
I was about to merge it, but was noot sure it was really discussed
before (and it would be a long time ago). The pull requests:
https://github.com/numpy/numpy/pull/10855
Proposes to add a count parameter to unpackbits:
``count`` allows subsetting the number of bits that will be unpacked
On Wed, 2019-03-06 at 12:41 -0800, Stephan Hoyer wrote:
> On Wed, Mar 6, 2019 at 10:10 AM Frederic Bastien > wrote:
> > Hi,
> >
> > I was told recently about the NEP-18. I like it, but I have a
> > comment.
> >
> > At first, it is enabled in a release by setting an environment
> > variable.
>
On Thu, 2019-03-07 at 18:24 +, Frederic Bastien wrote:
> I see speed changes vs behavior changes as different category of
> changes in my mind.
>
> I understand that now importing library can slow down NumPy for small
> arrays.
> But I have the impression you tell this can also give behavior
>
Hello Malika and welcome,
On Sat, 2019-03-23 at 02:08 +0100, Brinda wrote:
> Hello, I am called Malika.
> My outreachy initial application has been recently approved. I am new
> to this community and I'm really eager to work on this project.
> Please I wish someone explains to me how to get star
Hi Sanchi,
On Sat, 2019-03-30 at 15:58 +0530, Sanchi Vaishnavi wrote:
> I was learning to get to $ make html to work. These are the final
> steps that I used on my test branch in my numpy repo:
>
> > $ sphinx-build -b html doc/source builddir
> > >> build succeeded, 165 warnings.
> > $ make
On Sat, 2019-03-30 at 19:21 +0530, Parul Unofficial wrote:
> Hello!
>
> I'm Parul Aggarwal, a pre-final year student from India pursuing my
> bachelor's in Computer Science. I'm comfortable programming in C++
> and Python and have also worked previously on some projects based on
> flask, Django.
Hi Alex,
On Sun, 2019-05-05 at 11:03 -0400, Alex Samuel wrote:
> > On May 5, 2019, at 10:58, Alex Samuel wrote:
> >
> > Through trial and error, I've found that if I choose an unused type
> > code for each dtype, coercion seems to work as I expect it to (no
> > coercion unless I've provided a ca
OK, I looked into the code, so here is a small followup.
On Sun, 2019-05-05 at 10:58 -0400, Alex Samuel wrote:
> Hi,
>
> I'm working on building a number of related custom dtypes, and I'm
> not sure how to set the type and kind fields in PyArray_Descr. I
> tried using type='V' and choosing a si
Hi Alex,
On Mon, 2019-05-13 at 00:35 -0400, Alex Samuel wrote:
> Hi,
>
> When registering a custom cast function from datetime64 to another
> dtype, how can I get the units?
>
> I am calling PyArray_RegisterCastFunc from NPY_DATETIME. Ideally,
> I'd like to register a separate cast function for
Hi all,
there is an open PR (https://github.com/numpy/numpy/pull/12924) to
convert `np.sinc` into a ufunc. Since it should improve general
precision in `np.sinc`, I thought we could try to move that forward a
bit. We check whether this is worth it or not in the end.
However, it would also change
On Thu, 2019-05-23 at 10:17 -0400, Marten van Kerkwijk wrote:
> I agree that we should not have two functions
>
> I also am rather unsure whether a ufunc is a good idea. Earlier,
> while discussing other possible additions, like `erf`, the conclusion
> seemed to be that in numpy we should just cov
Hi all,
This is an attempt from me to wrap up the discussion a bit so that
others can chime in if they want to.
NumPy 1.17 will ship with `__array_function__` a way for array like
projects (dask, cupy) to override almost all numpy functions [0]. This
addition is uncontroversial.
NumPy 1.17 will _
Hi all,
unfortunately it was noticed in Issue 13604 [0] that when histogram is
given used with a specified range and the `density=True` keyword
argument out of bound values are simply discarded [1].
Discarding out of bound values makes sense when the density/normed
option is not used, since in th
On Sun, 2019-06-02 at 08:38 +0200, Ralf Gommers wrote:
>
>
> On Sun, Jun 2, 2019 at 3:18 AM Marten van Kerkwijk <
> m.h.vankerkw...@gmail.com> wrote:
> > > Our API is huge. A simple count:
> > > main namespace: 600
> > > fft: 30
> > > linalg: 30
> > > random: 60
> > > ndarray: 70
> > > lib: 20
>
On Sun, 2019-06-02 at 08:42 +0200, Ralf Gommers wrote:
>
>
> > >
> >
> > This sounds like a restructuring or factorization of the API, in
> > order to make it smaller, and thus easier to learn and use.
> > It may start with the docs, by paying more attention to the "core"
> > or important func
Hi all,
TL;DR:
Value based promotion seems complex both for users and ufunc-
dispatching/promotion logic. Is there any way we can move forward here,
and if we do, could we just risk some possible (maybe not-existing)
corner cases to break early to get on the way?
---
Currently when you
On Wed, 2019-06-05 at 14:14 -0700, Stephan Hoyer wrote:
> On Wed, Jun 5, 2019 at 1:43 PM Sebastian Berg <
> sebast...@sipsolutions.net> wrote:
> > Hi all,
> >
> >
> > Because `uint8(127)` can also be a `int8`, but uint8(128) it is not
> > as
> >
, 2019-06-05 at 15:41 -0500, Sebastian Berg wrote:
> Hi all,
>
> TL;DR:
>
> Value based promotion seems complex both for users and ufunc-
> dispatching/promotion logic. Is there any way we can move forward
> here,
> and if we do, could we just risk some possible (maybe not-
true for almost all functions inside numpy),
lookup could be simplified.
For those loops with all the same dtype, the issue is fairly straight
forward anyway, because I can just decide how to handle the scalar
before hand.
Best,
Sebastian
>
> Tyler
>
> On Wed, 5 Jun 2019 at 15:
On Wed, 2019-06-05 at 21:35 -0400, Marten van Kerkwijk wrote:
> Hi Sebastian,
>
> Tricky! It seems a balance between unexpected memory blow-up and
> unexpected wrapping (the latter mostly for integers).
>
> Some comments specifically on your message first, then some more
> general related ones.
, but
the behaviour is tricky. Users can pass `dtype` explicitly, but that is
a huge kludge...
Will think about if there is a solution to that, because if there is
not, you are right. It has to be a "big step" kind of release.
Although, even then it would be nice to have warnings that can b
On Fri, 2019-06-07 at 07:18 +0200, Ralf Gommers wrote:
>
>
> On Fri, Jun 7, 2019 at 1:37 AM Nathaniel Smith wrote:
> > My intuition is that what users actually want is for *native Python
> > types* to be treated as having 'underspecified' dtypes, e.g. int is
> > happy to coerce to int8/int32/int
On Thu, 2019-06-06 at 19:34 -0400, Allan Haldane wrote:
> On 6/6/19 12:46 PM, Sebastian Berg wrote:
> > On Thu, 2019-06-06 at 11:57 -0400, Allan Haldane wrote:
> > > I think dtype-based casting makes a lot of sense, the problem is
> > > backward compatibility.
> >
On Fri, 2019-06-07 at 13:19 -0500, Sebastian Berg wrote:
> On Fri, 2019-06-07 at 07:18 +0200, Ralf Gommers wrote:
> >
> > On Fri, Jun 7, 2019 at 1:37 AM Nathaniel Smith
> > wrote:
> > > My intuition is that what users actually want is for *native
> > > Pyth
On Tue, 2019-06-11 at 10:56 +0200, Ralf Gommers wrote:
>
>
> On Mon, Jun 10, 2019 at 7:47 PM Marten van Kerkwijk <
> m.h.vankerkw...@gmail.com> wrote:
> > Hi All,
> >
> > In https://github.com/numpy/numpy/pull/12801, Tyler has been trying
> > to use the new `where` argument for reductions to imp
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
o come up again later).
All the Best,
Sebastian
-
PS: Below a copy of what I wrote:
---
title: Numpy Value Based Promotion Rules
author: Sebastian Berg
---
NumPy Value Based Scalar Casting and Promotion
==
This document
Hi all,
we had discussed trying a new strategy to gather release notes on the
last community call, but not followed up on it on the list yet.
For the next release, we decided to try a strategy of using a wiki page
to gather release notes. The main purpose for this is to avoid merge
conflicts in t
; > those are likely to come up again later).
> >
> > All the Best,
> >
> > Sebastian
> >
> >
> > -
> >
> > PS: Below a copy of what I wrote:
> >
> > ---
> > title: Numpy Value Based Promotion
On Wed, 2019-06-05 at 15:41 -0500, Sebastian Berg wrote:
> Hi all,
>
> TL;DR:
>
> Value based promotion seems complex both for users and ufunc-
> dispatching/promotion logic. Is there any way we can move forward
> here,
> and if we do, could we just risk some poss
ave an opinion.
- Sebastian
> On Wed, Jun 12, 2019, 07:59 Sebastian Berg <
> sebast...@sipsolutions.net> wrote:
> > Hi all,
> >
> > we had discussed trying a new strategy to gather release notes on
> > the
> > last community call, but not followed
On Wed, 2019-06-12 at 12:03 -0500, Sebastian Berg wrote:
> On Tue, 2019-06-11 at 22:08 -0400, Marten van Kerkwijk wrote:
> > HI Sebastian,
> >
> > Thanks for the overview! In the value-based casting, what perhaps
> > surprises me most is that it is done within a
On Wed, 2019-06-12 at 17:34 -0700, Nathaniel Smith wrote:
> On Wed, Jun 12, 2019 at 12:58 PM Marten van Kerkwijk
> wrote:
> > Overall, in favour of splitting the large files, but I don't like
> > that the notes stop being under version control (e.g., a follow-up
> > PR slightly changes things, how
ed
special "minimum value" rules. And of course it also means that
resolvers need to handle such scalar(?) objects, but in many cases they
do not need more than "can cast" anyway.
Best,
Sebastian
> Best Regards,
> Hameer Abbasi
>
> > On Wednesday, Jun 12, 2
On Thu, 2019-06-13 at 19:09 -0600, Charles R Harris wrote:
> Hi All,
>
> With the 1.17 branch coming soon, this might be a good time to make
> plans about 1.18 development. A couple of possibilities are:
>
> Expiring old deprecations,
Good plan.
> Removing Python 2.7 compatibility code,
Sounds
Hi all,
There will be a NumPy Community meeting on June 12 at 11 am Pacific
Time. Everyone is invited to join in and edit the work-in-progress
meeting notes: https://hackmd.io/76o-IxCjQX2mOXO_wwkcpg?both
Best wishes
Sebastian
signature.asc
Description: This is a digitally signed message part
_
Hi Hameer,
On Tue, 2019-06-18 at 04:28 +0200, Hameer Abbasi wrote:
> On Wed, 2019-06-12 at 12:55 -0500, Sebastian Berg wrote:
> > On Wed, 2019-06-05 at 15:41 -0500, Sebastian Berg wrote:
> > > Hi all,
> > >
> A type is safely castable to another if all of these
On Wed, 2019-06-05 at 21:35 -0400, Marten van Kerkwijk wrote:
> Hi Sebastian,
>
> Tricky! It seems a balance between unexpected memory blow-up and
> unexpected wrapping (the latter mostly for integers).
>
> Some comments specifically on your message first, then some more
> general related ones.
Hi all,
since this is going to be a new addition as part of the randomgen, I
thought I would just mention it on the mailing list. The Pull Request:
https://github.com/numpy/numpy/pull/13780
Implements a new SeedSequence object based on Robert Kern's proposal
and especially the work by Prof. O'Ne
On Sun, 2019-06-23 at 19:51 +, Hameer Abbasi wrote:
> +1 for this. I have often seen (and sometimes written) code that does
> this automatically, and it is a common mistake.
Yeah, likely worth a short. I doubt many uses for the n-dimensional
axis transpose, so maybe a futurewarning approach ca
On Sun, 2019-06-23 at 23:03 +0200, Andras Deak wrote:
> On Sun, Jun 23, 2019 at 10:37 PM Sebastian Berg
> wrote:
> > Yeah, likely worth a short. I doubt many uses for the n-dimensional
> > axis transpose, so maybe a futurewarning approach can work. If not,
> > I
> &g
Probably an error is good, which is nice, because we can just tag on a
warning and not worry about it for a while ;).
>
> All the best,
>
> Marten
>
> On Sun, Jun 23, 2019 at 4:37 PM Sebastian Berg <
> sebast...@sipsolutions.net> wrote:
> > On Sun, 2019-0
Hi all,
There will be a NumPy Community meeting on _Thursday_ June 26 at 11 am
Pacific Time. Everyone is invited to join in and edit the work-in-
progress meeting notes: https://hackmd.io/76o-IxCjQX2mOXO_wwkcpg?both
Best wishes
Sebastian
PS: We decided to move to Thursday, since at least Matti
Sorry, Thursday is the 27th of course.
On Mon, 2019-06-24 at 11:02 -0700, Sebastian Berg wrote:
> Hi all,
>
> There will be a NumPy Community meeting on _Thursday_ June 26 at 11
> am
> Pacific Time. Everyone is invited to join in and edit the work-in-
> progress meeting notes:
On Tue, 2019-06-25 at 14:18 -0400, Cameron Blocker wrote:
> It seems to me that the general consensus is that we shouldn't be
> changing .T to do what we've termed matrix transpose or conjugate
> transpose. As such, the discussion of whether .T should be changed to
> throw errors or warnings on 1D
On Tue, 2019-06-25 at 17:00 -0400, Marten van Kerkwijk wrote:
> Hi Kirill, others,
>
> Indeed, it is becoming long! That said, while initially I was quite
> charmed by Eric's suggestion of deprecating and then changing `.T`, I
> think the well-argued opposition to it has changed my opinion.
> Perh
On Wed, 2019-06-26 at 17:22 -0400, Marten van Kerkwijk wrote:
> Hi Ralf,
>
> I realize you feel strongly that this whole thread is rehashing
> history, but I think it is worth pointing out that many seem to
> consider that the criterion for allowing backward incompatible
> changes, i.e., that "exi
Hi all,
There will be a NumPy Community meeting Wednesday July 3 at 11 am
Pacific Time. Everyone is invited to join in and edit the work-in-
progress meeting notes: https://hackmd.io/76o-IxCjQX2mOXO_wwkcpg
Best wishes
Sebastian
___
NumPy-Discussion mai
Hi all,
due to the SciPy conference we will _not_ have a Community meeting this
week. We will have a developer meeting at the SciPy conference on
Friday at 1pm in room 108 and take part in the Sprints. I will send a
tentative Agenda/things to discuss in a separate email.
Best,
Sebastian
signat
Hi all,
we have reserved a room for a Developer meeting at SciPy. The meeting
is planned for Friday at 1pm in room 108.
I have created a tentative Agenda with some broad discussion points at:
https://hackmd.io/rg0DI0JASKeZ_G5bTJ3YSA
Please feel free to edit or add the Agenda.
All the Best,
Seb
Hi all,
just a quick reminder that we have the meeting in about an hour. If you
wish to attend/chat from externally, please shoot me an email, I am
sure we can set up something.
Best,
Sebastian
On Mon, 2019-07-08 at 12:56 -0700, Sebastian Berg wrote:
> Hi all,
>
> we have reserved a
Hi all,
There will be a NumPy Community meeting Wednesday July 17 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
Best wishes
Sebastian
signature.asc
Description: This is a digitally signed
On Tue, 2019-07-16 at 07:06 -0600, Charles R Harris wrote:
> Hi Dashamir,
>
> On Mon, Jul 15, 2019 at 4:49 PM Dashamir Hoxha
> wrote:
> > Hi,
> >
> > With respect to this call for contributions:
> > https://github.com/numpy/numpy/pull/13988/files
> > I would like to help with improving the webs
Hi all,
There will be a NumPy Community meeting Wednesday July 24 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
Best wishes
Sebastian
signature.asc
Description: This is a digitally signed
On Tue, 2019-07-23 at 13:38 -0500, Stanley Seibert wrote:
> (Full disclosure: I work on Numba...)
>
> Just to note, the NumPy implementation will allocate (and free) more
> than 2 arrays to compute that expression. It has to allocate the
> result array for each operation as Python executes. Tha
Hey,
On Thu, 2019-07-25 at 11:35 -0600, Charles R Harris wrote:
> Hi All,
>
> The possibility of disabling default creation of object arrays has
> come up again. I'm wondering if one way to get there is to allow
> generic dtypes. The `numpy/core/numerictypes.py` module defines a
> hierarchy, and
es+einstein.edison=gmail....@python.org> on
> behalf of Sebastian Berg
> Sent: Thursday, July 25, 2019 11:23 pm
> To: numpy-discussion@python.org
> Subject: Re: [Numpy-discussion] Adding generic dtypes
>
> Hey,
>
> On Thu, 2019-07-25 at 11:35 -0600, Charles R Harris
Hi all,
There will be a NumPy Community meeting Wednesday July 31 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
Best wishes
Sebastian
signature.asc
Description: This is a digitally signed
On Tue, 2019-08-06 at 10:24 +0200, Peter Andreas Entschev wrote:
> Thanks for the concerns raised, and Stephan for promptly answering
> them.
>
> > An alternative to introducing np.duckarray() would be to just
> > modify np.asarray(). Of course this has backwards compatibility
> > impact, but if y
Hi all,
There will be a NumPy Community meeting Wednesday August 7 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
Best wishes
Sebastian
PS: (Sorry if you recently updated the file, I may ha
Hi all,
There will be a NumPy Community meeting Wednesday August 14 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
Best wishes
Sebastian
signature.asc
Description: This is a digitally signe
On Wed, 2019-08-14 at 13:45 +0100, Azeez Abdulsamod wrote:
> When will there be Numpy community in Nigeria
>
These meetings are online through video/telephone conference. The link
information is in the hackmd link.
- Sebastian
> On Tue, Aug 13, 2019, 3:31 PM Sebastian Berg &
Hi Joris,
On Mon, 2019-08-19 at 17:35 +0200, Joris Van den Bossche wrote:
> Hi all,
>
> PyGEOS (https://github.com/caspervdw/pygeos) is an experimental
> package implementing a set of numpy ufuncs to provide vectorized
> geometry functionality (wrapping the C++ GEOS library).
>
> The way it does
Hi all,
There will be a NumPy Community meeting Wednesday August 21 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 digitally
On Tue, 2019-08-20 at 22:30 +0200, Joris Van den Bossche wrote:
> Hi Sebastian,
>
> Thanks for the answer!
>
> On Mon, 19 Aug 2019 at 17:57, Sebastian Berg <
> sebast...@sipsolutions.net> wrote:
> > ...
> >
> > Hmmm, interesting use case. No, I do not
Hi all,
There will be a NumPy Community meeting Wednesday August 28 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 Evoluti
Hi all,
There will be a NumPy Community meeting Wednesday September 4 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 Evolu
On Tue, 2019-09-03 at 08:56 -0400, Warren Weckesser wrote:
> Github issue 2880 ("Get financial functions out of main namespace",
Very briefly, I am absolutely in favor of this.
Keeping the functions in numpy seems more of a liability than help
anyone. And this push is more likely to help users b
this won't
> work. We have no bug report yet because 1.17.x hasn't landed in conda
> defaults yet (perhaps this is a/the reason why?), but it will be a
> problem.
>
> > The import numpy.overridable part is meant to help garner adoption,
> > and to prefer the unump
On Mon, 2019-09-09 at 20:32 -0700, Stephan Hoyer wrote:
> On Mon, Sep 9, 2019 at 6:27 PM Ralf Gommers
> wrote:
> > I think we've chosen to try the former - dispatch on functions so
> > we can reuse the NumPy API. It could work out well, it could give
> > some long-term maintenance issues, time wil
`type(duckarray).…` on library authors.
I guess the important thing is mostly what would be convenient to
downstreams implementers.
- Sebastian
> Eric
>
> On Mon, Sep 9, 2019, 21:18 Sebastian Berg > wrote:
> > On Mon, 2019-09-09 at 20:32 -0700, Stephan Hoyer wrote:
> &g
On Tue, 2019-09-10 at 17:28 +0200, Hameer Abbasi wrote:
> On 07.09.19 22:06, Sebastian Berg wrote:
> > On Fri, 2019-09-06 at 14:45 -0700, Ralf Gommers wrote:
> >
> >
> >
> > Let me try to move the discussion from the github issue here (this
> > may
Hi all,
There will be a NumPy Community meeting Wednesday September 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
BEGIN:VCALENDAR
PRODID:-//Ximian//NONSGML Evol
Hi all,
On Thu, 2019-08-29 at 00:41 -0400, Inessa Pawson wrote:
> You know that NumPy is essential to the Python community. The NumPy
> team wants you to know that YOU, our user and developer community,
> are essential to us. That’s why we are putting together a team to
> create the inaugural Num
Hi all,
There will be a NumPy Community meeting Wednesday September 18 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 Evol
Hi all,
to try and make some progress towards a decision since the broad design
is pretty much settling from my side. I am thinking about making a
meeting, and suggest Monday at 11am Pacific Time (I am open to other
times though).
My hope is to get everyone interested on board, so that we can mak
On Wed, 2019-09-18 at 21:33 -0700, Ralf Gommers wrote:
> Hi Sebastian,
>
>
> On Wed, Sep 18, 2019 at 4:35 PM Sebastian Berg <
> sebast...@sipsolutions.net> wrote:
> > Hi all,
> >
> > to try and make some progress towards a decision since the broad
> &g
On Thu, 2019-09-19 at 21:35 +0300, Matti Picus wrote:
> On 19/9/19 2:34 am, Sebastian Berg wrote:
> > Hi all,
> >
> > to try and make some progress towards a decision since the broad
> > design
> > is pretty much settling from my side. I am thinking about making
On Mon, 2019-09-23 at 13:44 +0200, Ralf Gommers wrote:
>
>
> On Mon, Sep 23, 2019 at 1:40 PM Tom Augspurger <
> tom.w.augspur...@gmail.com> wrote:
> >
> > On Fri, Sep 20, 2019 at 3:10 PM Sebastian Berg <
> > sebast...@sipsolutions.net> wrote:
> >
t;
> > tom.w.augspur...@gmail.com> wrote:
> > > On Fri, Sep 20, 2019 at 3:10 PM Sebastian Berg <
> > > sebast...@sipsolutions.net> wrote:
> > > > On Thu, 2019-09-19 at 21:35 +0300, Matti Picus wrote:
> > > > > On 19/9/19 2:34 am, Sebastian Berg w
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 Evol
Hi all,
Looking at the ufunc dispatching rules with an `out` argument, I was a
bit surprised to realize this little gem is how things work:
```
arr = np.arange(10, dtype=np.uint16) + 2**15
print(arr)
# array([ 0, 2, 4, 6, 8, 10, 12, 14, 16, 18], dtype=uint16)
out = np.zeros(10)
np.add(arr,
On Fri, 2019-09-27 at 11:50 -0700, Sebastian Berg wrote:
> Hi all,
>
> Looking at the ufunc dispatching rules with an `out` argument, I was
> a
> bit surprised to realize this little gem is how things work:
>
> ```
> arr = np.arange(10, dtype=np.uint16) + 2**15
> print
probably work with that assumption, without actually breaking
anything.)
- Sebastian
> On Fri, Sep 27, 2019, 15:02 Sebastian Berg <
> sebast...@sipsolutions.net> wrote:
> > On Fri, 2019-09-27 at 11:50 -0700, Sebastian Berg wrote:
> > > Hi all,
> > >
> > &
On Sat, 2019-09-28 at 13:15 -0400, Warren Weckesser wrote:
> On 9/27/19, Warren Weckesser wrote:
> > NumPy devs,
> >
> > NEP 32 to remove the financial functions
> > (https://numpy.org/neps/nep-0032-remove-financial-functions.html)
> > has
> > been accepted.
>
> CI gurus: the web page containing
On Sun, 2019-09-29 at 00:20 -0400, Warren Weckesser wrote:
> On 9/28/19, Eric Wieser wrote:
> > Can you just raise an exception in the gufuncs inner loop? Or is
> > there no
> > mechanism to do that today?
>
> Maybe? I don't know what is the idiomatic way to handle errors
> detected in an inner
101 - 200 of 664 matches
Mail list logo
