[Numpy-discussion] Fwd: SciPy2017 Sprints FinAid for sprint leaders/core devs

In case anyone is interested in helping run a NumPy sprint at SciPy this year: -- Forwarded message -- From: Jonathan Rocher Date: Mon, Mar 27, 2017 at 7:06 AM Subject: SciPy2017 Sprints FinAid for sprint leaders/core devs To: Nathaniel Smith , charlesr.har...@gmail.com

Re: [Numpy-discussion] __array_ufunc__ counting down to launch, T-24 hrs.

On Thu, Mar 30, 2017 at 7:40 PM, Charles R Harris wrote: > Hi All, > > Just a note that the __array_ufunc__ PR is ready to merge. If you are > interested, you can review here. I want to get this in too, but 24 hours seems like a very short deadline for getting feedback on such a large and complex

Re: [Numpy-discussion] Fwd: [numfocus] Grants up to $3k available to NumFOCUS projects (sponsored & affiliated)

On Mar 31, 2017 1:15 AM, "Ralf Gommers" wrote: On Mon, Mar 27, 2017 at 11:42 PM, Ralf Gommers wrote: > > > On Mon, Mar 27, 2017 at 11:33 PM, Julian Taylor < > jtaylor.deb...@googlemail.com> wrote: > >> I have two ideas under one big important topic: make numpy python3 >> compatible. >> >> The

Re: [Numpy-discussion] speed of random number generator compared to Julia

On Apr 3, 2017 8:59 AM, "Pierre Haessig" wrote: Le 03/04/2017 à 15:44, Jaime Fernández del Río a écrit : This says that Julia uses this library

Re: [Numpy-discussion] Long term plans for dropping Python 2.7

On Fri, Apr 14, 2017 at 5:19 PM, Charles R Harris wrote: > Hi All, > > It may be early to discuss dropping support for Python 2.7, but there is a > disturbance in the force that suggests that it might be worth looking > forward to the year 2020 when Python itself will drop support for 2.7. There >

Re: [Numpy-discussion] Long term plans for dropping Python 2.7

On Fri, Apr 14, 2017 at 10:47 PM, Ralf Gommers wrote: > > > On Sat, Apr 15, 2017 at 5:19 PM, Nathaniel Smith wrote: [...] >> From numpy's perspective, I feel like the most important reason to >> continue supporting 2.7 is our ability to convince people to keep >>

Re: [Numpy-discussion] proposal: smaller representation of string arrays

On Apr 21, 2017 2:34 PM, "Stephan Hoyer" wrote: I still don't understand why a latin encoding makes sense as a preferred one-byte-per-char dtype. The world, including Python 3, has standardized on UTF-8, which is also one-byte-per-char for (ASCII) scientific data. You may already know this, but

Re: [Numpy-discussion] proposal: smaller representation of string arrays

On Mon, Apr 24, 2017 at 7:23 PM, Robert Kern wrote: > On Mon, Apr 24, 2017 at 7:07 PM, Nathaniel Smith wrote: > >> That said, AFAICT what people actually want in most use cases is support >> for arrays that can hold variable-length strings, and the only place where >>

Re: [Numpy-discussion] proposal: smaller representation of string arrays

On Apr 25, 2017 11:53 AM, "Robert Kern" wrote: On Tue, Apr 25, 2017 at 11:18 AM, Charles R Harris < charlesr.har...@gmail.com> wrote: > > On Tue, Apr 25, 2017 at 11:34 AM, Anne Archibald < peridot.face...@gmail.com> wrote: >> Clearly there is a need for fixed-storage-size zero-padded UTF-8; two

Re: [Numpy-discussion] proposal: smaller representation of string arrays

On Apr 25, 2017 9:35 AM, "Chris Barker" wrote: - filenames File names are one of the key reasons folks struggled with the python3 data model (particularly on *nix) and why 'surrogateescape' was added. It's pretty common to store filenames in with our data, and thus in numpy arrays -- we need t

Re: [Numpy-discussion] proposal: smaller representation of string arrays

On Apr 25, 2017 10:13 AM, "Anne Archibald" wrote: On Tue, Apr 25, 2017 at 6:05 PM Chris Barker wrote: > Anyway, I think I made the mistake of mingling possible solutions in with > the use-cases, so I'm not sure if there is any consensus on the use cases > -- which I think we really do need to

Re: [Numpy-discussion] proposal: smaller representation of string arrays

On Tue, Apr 25, 2017 at 4:11 PM, Chris Barker - NOAA Federal wrote: >> On Apr 25, 2017, at 12:38 PM, Nathaniel Smith wrote: > >> Eh... First, on Windows and MacOS, filenames are natively Unicode. > > Yeah, though once they are stored I. A text file -- who the heck > k

Re: [Numpy-discussion] proposal: smaller representation of string arrays

On Apr 26, 2017 9:30 AM, "Chris Barker - NOAA Federal" < chris.bar...@noaa.gov> wrote: UTF-8 does not match the character-oriented Python text model. Plenty of people argue that that isn't the "correct" model for Unicode text -- maybe so, but it is the model python 3 has chosen. I wrote a much lo

Re: [Numpy-discussion] proposal: smaller representation of string arrays

On Apr 26, 2017 12:09 PM, "Robert Kern" wrote: On Wed, Apr 26, 2017 at 10:43 AM, Julian Taylor < jtaylor.deb...@googlemail.com> wrote: [...] > I have read every mail and it has been a large waste of time, Everything > has been said already many times in the last few years. > Even if you memory ma

Re: [Numpy-discussion] [NumPy-discussion] Wish List of Possible ufunc Enhancements

On Fri, Apr 28, 2017 at 9:53 AM, Matthew Harrigan wrote: > Here is a link to a wish list of possible ufunc enhancements. I would like > to know what the community thinks. It looks like a pretty good list of ideas worth thinking about as and when someone has time :-). I'm not sure what feedback y

Re: [Numpy-discussion] NumPy v1.13.0rc1 released.

On Wed, May 10, 2017 at 7:06 PM, Nathan Goldbaum wrote: > Hi Chuck, > > Is there a docs build for this release somewhere? I'd like to find an > authoritative reference about __array_ufunc__, which I'd hesistated on > looking into until now for fear about the API changing. A sort-of-rendered versi

[Numpy-discussion] UC Berkeley hiring developers to work on NumPy

Hi all, As some of you know, I've been working for... quite some time now to try to secure funding for NumPy. So I'm excited that I can now officially announce that BIDS [1] is planning to hire several folks specifically to work on NumPy. These will full time positions at UC Berkeley, postdoc or s

Re: [Numpy-discussion] UC Berkeley hiring developers to work on NumPy

On Sun, May 14, 2017 at 2:56 PM, Charles R Harris wrote: > > > On Sat, May 13, 2017 at 11:45 PM, Nathaniel Smith wrote: >> >> Hi all, >> >> As some of you know, I've been working for... quite some time now to >> try to secure funding for NumPy.

Re: [Numpy-discussion] UC Berkeley hiring developers to work on NumPy

On Sun, May 14, 2017 at 2:11 PM, Chris Barker - NOAA Federal wrote: > Awesome! This is really great news. > > Does this mean is several person-years of funding secured? Yes – hoping to give more details there soon. (There's nothing dire and secretive, it's just the logistics of getting an announc

Re: [Numpy-discussion] Proposal: np.search() to complement np.searchsorted()

On May 9, 2017 9:47 AM, "Martin Spacek" wrote: Hello, I've opened up a pull request to add a function called np.search(), or something like it, to complement np.searchsorted(): https://github.com/numpy/numpy/pull/9055 There's also this issue I opened before starting the PR: https://github.com

Re: [Numpy-discussion] UC Berkeley hiring developers to work on NumPy

keep your fingers crossed I guess. Here's some text from the proposal (the references to "this year" may give some sense of how long this has taken...): https://docs.google.com/document/d/1xHjQqc8V8zJk7WSCyw9NPCpMYZ2Urh0cmFm2vDd14ZE/edit -n On Sun, May 14, 2017 at 3:40 PM, Nathani

Re: [Numpy-discussion] UC Berkeley hiring developers to work on NumPy

On Mon, May 15, 2017 at 1:43 AM, Matthew Brett wrote: > Hi, > > On Sun, May 14, 2017 at 10:56 PM, Charles R Harris > wrote: >> >> >> On Sat, May 13, 2017 at 11:45 PM, Nathaniel Smith wrote: >>> >>> Hi all, >>> >>> As some of yo

Re: [Numpy-discussion] UC Berkeley hiring developers to work on NumPy

On Mon, May 22, 2017 at 10:04 AM, Sebastian Berg wrote: > On Mon, 2017-05-22 at 17:35 +0100, Matthew Brett wrote: >> Hi, >> >> On Mon, May 22, 2017 at 4:52 PM, Marten van Kerkwijk >> wrote: >> > Hi Matthew, >> > >> > > it seems to me that we could get 80% of the way to a reassuring >> > > bluepri

Re: [Numpy-discussion] Future of ufuncs

On Mon, May 29, 2017 at 1:51 PM, Charles R Harris wrote: > > > On Mon, May 29, 2017 at 12:32 PM, Marten van Kerkwijk > wrote: >> >> Hi Chuck, >> >> Like Sebastian, I wonder a little about what level you are talking >> about. Presumably, it is the actual implementation of the ufunc? I.e., >> this

Re: [Numpy-discussion] [SciPy-Dev] PyRSB: Python interface to librsb sparse matrices library

On Jun 24, 2017 7:29 AM, "Sylvain Corlay" wrote: Also, one quick question: is the LGPL license a deliberate choice or is it not important to you? Most projects in the Python scientific stack are BSD licensed. So the LGPL choice makes it unlikely that a higher-level project adopts it as a depende

Re: [Numpy-discussion] Boolean binary '-' operator

On Sun, Jun 25, 2017 at 9:45 AM, Stefan van der Walt wrote: > Hi Chuck > > On Sun, Jun 25, 2017, at 09:32, Charles R Harris wrote: > >> The boolean binary '-' operator was deprecated back in NumPy 1.9 and changed >> to an error in 1.13. This caused a number of failures in downstream >> projects. T

Re: [Numpy-discussion] Boolean binary '-' operator

On Jun 26, 2017 6:56 PM, "Charles R Harris" wrote: > On 27 Jun 2017, 9:25 AM +1000, Nathaniel Smith , wrote: > I guess my preference would be: > 1) deprecate + > 2) move binary - back to deprecated-but-not-an-error > 3) fix np.diff to use logical_xor when the inputs

Re: [Numpy-discussion] Boolean binary '-' operator

On Tue, Jun 27, 2017 at 3:09 PM, Robert Kern wrote: > On Tue, Jun 27, 2017 at 3:01 PM, Benjamin Root wrote: >> >> Forgive my ignorance, but what is "Z/2"? > > https://groupprops.subwiki.org/wiki/Cyclic_group:Z2 > https://en.wikipedia.org/wiki/Cyclic_group This might be a slightly better link? ht

Re: [Numpy-discussion] proposed changes to array printing in 1.14

On Fri, Jun 30, 2017 at 7:23 PM, Juan Nunez-Iglesias wrote: > I agree that shipping a sane/sanitising doctest runner would go 95% of the > way to alleviating my concerns. > > Regarding 2.0, this is the whole point of semantic versioning: downstream > packages can pin their dependency as 1.x and kn

Re: [Numpy-discussion] Vector stacks

On Sat, Jul 1, 2017 at 3:31 PM, Charles R Harris wrote: > Hi All, > > The '@' operator works well with stacks of matrices, but not with stacks of > vectors. Given the recent addition of '__array_ufunc__', and the intent to > make `__matmul__` use a ufunc, I've been wondering is it would make sen

Re: [Numpy-discussion] Making a 1.13.2 release

It's also possible to work around the 3.6.1 problem with a small preprocessor hack. On my phone but there's a link in the bug report discussion. On Jul 6, 2017 6:10 AM, "Charles R Harris" wrote: > Hi All, > > I've delayed the NumPy 1.13.2 release hoping for Python 3.6.2 to show up > fixing #2994

Re: [Numpy-discussion] NumPy steering councils members

On Jul 21, 2017 9:36 AM, "Sebastian Berg" wrote: On Fri, 2017-07-21 at 16:58 +0200, Julian Taylor wrote: > On 21.07.2017 08:52, Ralf Gommers wrote: > > Hi all, > > > > It has been well over a year since we put together the governance > > structure and steering council > > (https://docs.scipy.org/

Re: [Numpy-discussion] Dropping support for Accelerate

I've been wishing we'd stop shipping Accelerate for years, because of how it breaks multiprocessing – that doesn't seem to be on your list yet. On Sat, Jul 22, 2017 at 3:50 AM, Ilhan Polat wrote: > A few months ago, I had the innocent intention to wrap LDLt decomposition > routines of LAPACK into

Re: [Numpy-discussion] Dropping support for Accelerate

se of fork() without exec is discouraged in general in processes >>> that use layers above POSIX." >>> >>> On Sun, Jul 23, 2017 at 10:16 AM, Ilhan Polat >>> wrote: >>>> >>>> That's probably because I know nothing about the

Re: [Numpy-discussion] Dropping support for Accelerate

On Tue, Jul 25, 2017 at 6:48 AM, Matthew Brett wrote: > On Tue, Jul 25, 2017 at 2:19 PM, Nathaniel Smith wrote: >> I updated the bit about OpenBLAS wheel with some more information on >> the status of that work. It's not super important, but FYI. > > Maybe remove the

Re: [Numpy-discussion] Dropping support for Accelerate

On Tue, Jul 25, 2017 at 7:05 AM, Matthew Brett wrote: > On Tue, Jul 25, 2017 at 3:00 PM, Nathaniel Smith wrote: >> On Tue, Jul 25, 2017 at 6:48 AM, Matthew Brett >> wrote: >>> On Tue, Jul 25, 2017 at 2:19 PM, Nathaniel Smith wrote: >>>> I updated the bit

Re: [Numpy-discussion] ENH: ratio function to mimic diff

I'd also like to see a more detailed motivation for this. And, if it is useful, then that would make 3 operations that have special case pairwise moving window variants (subtract, floor_divide, true_divide). 3 is a lot of special cases. Should there instead be a generic mechanism for doing this fo

Re: [Numpy-discussion] Why are empty arrays False?

On Fri, Aug 18, 2017 at 2:45 PM, Michael Lamparski wrote: > Greetings, all. I am troubled. > > The TL;DR is that `bool(array([])) is False` is misleading, dangerous, and > unnecessary. Let's begin with some examples: > bool(np.array(1)) > True bool(np.array(0)) > False bool(np.arra

Re: [Numpy-discussion] Why are empty arrays False?

On Fri, Aug 18, 2017 at 7:34 PM, Eric Firing wrote: > I don't agree. I think the consistency between bool([]) and bool(array([])) > is worth preserving. Nothing you have shown is inconsistent with "Falseness > is emptiness", which is quite fundamental in Python. The inconsistency is > in distin

Re: [Numpy-discussion] Proposal - change to OpenBLAS for Windows wheels

Makes sense to me. On Sep 25, 2017 05:54, "Matthew Brett" wrote: > Hi, > > I suggest we switch from ATLAS to OpenBLAS for our Windows wheels: > > * OpenBLAS is much faster, at least when Tony Kelman tested it last year > [1]; > * We now have an automated Appveyor build for OpenBLAS [2, 3]; > * T

[Numpy-discussion] numpy grant update

Hi all, I wanted to give everyone an update on what's going on with the NumPy grant [1]. As you may have noticed, things have been moving a bit slower than originally hoped -- unfortunately my health is improving but has continued to be rocky [2]. Fortunately, I have awesome co-workers, and BIDS

Re: [Numpy-discussion] numpy grant update

On Wed, Oct 18, 2017 at 10:24 PM, Nathaniel Smith wrote: > I'll also be giving a lunch talk at BIDS tomorrow to let folks locally > know about what's going on, which I think will be recorded – I'll send > around a link after in case others are interested.

Re: [Numpy-discussion] numpy grant update

On Thu, Oct 26, 2017 at 1:14 PM, Marten van Kerkwijk wrote: > Hi Nathaniel, > > Thanks for the link. The plans sounds great! You'll not be surprised > to hear I'm particularly interested in the units aspect (and, no, I > don't mind at all if we can stop subclassing ndarray...). Is the idea > that

Re: [Numpy-discussion] numpy grant update

On Thu, Oct 26, 2017 at 2:11 PM, Nathan Goldbaum wrote: > My understanding of this is that the dtype will only hold the unit metadata. > So that means units would propogate through calculations automatically, but > the dtype wouldn't be able to manipulate the array data (in an in-place unit > conv

Re: [Numpy-discussion] is __array_ufunc__ ready for prime-time?

On Nov 6, 2017 4:19 PM, "Chris Barker" wrote: On Sat, Nov 4, 2017 at 6:47 AM, Marten van Kerkwijk < m.h.vankerkw...@gmail.com> wrote: > > You just summarized excellently why I'm on a quest to change `asarray` > to `asanyarray` within numpy +1 -- we should all be using asanyarray() most of the

Re: [Numpy-discussion] Proposal of timeline for dropping Python 2.7 support

On Nov 7, 2017 2:15 PM, "Chris Barker" wrote: On Mon, Nov 6, 2017 at 6:14 PM, Charles R Harris wrote: > Also -- if py2.7 continues to see the use I expect it will well past when >>> pyton.org officially drops it, I wouldn't be surprised if a Python2.7 >>> Windows build based on a newer compiler

Re: [Numpy-discussion] deprecate updateifcopy in nditer operand, flags?

At a higher level: The issue here is that we need to break the nditer API. This might affect you if you np.nditer (in Python) or the NpyIter_* APIs (in C). The exact cases affected are somewhat hard to describe because nditer's flag processing is complicated [1], but basically it's cases where you

Re: [Numpy-discussion] Proposal of timeline for dropping Python 2.7 support

On Nov 8, 2017 16:51, "Matthew Brett" wrote: Hi, On Wed, Nov 8, 2017 at 7:08 PM, Julian Taylor wrote: > On 06.11.2017 11:10, Ralf Gommers wrote: >> >> >> On Mon, Nov 6, 2017 at 7:25 AM, Charles R Harris >> mailto:charlesr.har...@gmail.com>> wrote: >> >> Hi All, >> >> Thought I'd toss th

Re: [Numpy-discussion] Proposal of timeline for dropping Python 2.7 support

On Nov 8, 2017 23:59, "Ralf Gommers" wrote: Regarding http://www.python3statement.org/: I'd say that as long as there are people who want to spend their energy on the LTS release (contributors *and* enough maintainer power to review/merge/release), we should not actively prevent them from doing t

Re: [Numpy-discussion] Proposal of timeline for dropping Python 2.7 support

See Thomas's reply quoted below (it was rejected by the mailing list since he's not subscribed): On Nov 9, 2017 01:24, "Thomas Kluyver" wrote: On Thu, Nov 9, 2017, at 08:52 AM, Nathaniel Smith wrote: On Nov 8, 2017 23:59, "Ralf Gommers" wrote: Regarding http://

Re: [Numpy-discussion] Proposal of timeline for dropping Python 2.7 support

Fortunately we can wait until we're a bit closer before we have to make any final decision on the version numbering :-) Right now though it would be good to start communicating to users/downstreams about whatever our plans our though, so they can make plans. Here's a first attempt at some text we

Re: [Numpy-discussion] deprecate updateifcopy in nditer operand, flags?

On Wed, Nov 8, 2017 at 2:13 PM, Allan Haldane wrote: > On 11/08/2017 03:12 PM, Nathaniel Smith wrote: >> - We could adjust the API so that there's some explicit operation to >> trigger the final writeback. At the Python level this would probably >> mean that we start su

Re: [Numpy-discussion] Proposal of timeline for dropping Python 2.7 support

On Nov 12, 2017 1:12 PM, "Todd" wrote: Might it make sense to do this in a synchronized manner with scipy? So both numpy and scipy drop support for python 2 on the first release after December 31 2018, and numpy's first python3-only release comes before (or simultaneously with) scipy's. Then sc

Re: [Numpy-discussion] Proposal of timeline for dropping Python 2.7 support

On Nov 13, 2017 12:03, "Gael Varoquaux" wrote: On Mon, Nov 13, 2017 at 10:26:31AM -0800, Matthias Bussonnier wrote: > This behavior is "new" (Nov/Dec 2016). [snip] > It _does_ require to have a version of pip which is not decades old Just to check that I am not misunderstanding: the version of p

Re: [Numpy-discussion] numpy grant update

On Thu, Oct 26, 2017 at 12:40 PM, Nathaniel Smith wrote: > On Wed, Oct 18, 2017 at 10:24 PM, Nathaniel Smith wrote: >> I'll also be giving a lunch talk at BIDS tomorrow to let folks locally >> know about what's going on, which I think will be recorded – I'll send

Re: [Numpy-discussion] Proposal of timeline for dropping Python 2.7 support

ect link to the rendered NEP in the repo is: https://github.com/numpy/numpy/blob/master/doc/neps/dropping-python2.7-proposal.rst (I guess that at some point it will also show up on docs.scipy.org.) -n [1] https://github.com/numpy/numpy/pull/10006 On Thu, Nov 9, 2017 at 5:52 PM, Nathaniel Smith wrote

[Numpy-discussion] Upcoming revision of the BLAS standard

Hi NumPy and SciPy developers, Apparently there is some work afoot to update the BLAS standard, with a working document here: https://docs.google.com/document/d/1DY4ImZT1coqri2382GusXgBTTTVdBDvtD5I14QHp9OE/edit This seems like something where we might want to get involved in, so that the new sta

Re: [Numpy-discussion] Type annotations for NumPy

On Sat, Nov 25, 2017 at 3:09 PM, Juan Nunez-Iglesias wrote: > This is a complete outsider’s perspective but > > (a) it would be good if NumPy type annotations could include an “array_like” > type that allows lists, tuples, etc. I'm sure this will exist. > (b) I’ve always thought (since PEP561) t

Re: [Numpy-discussion] Deprecate matrices in 1.15 and remove in 1.17?

On Thu, Nov 30, 2017 at 11:39 AM, Charles R Harris wrote: > > > On Thu, Nov 30, 2017 at 11:43 AM, Ralf Gommers > wrote: >> I'd suggest any release in the next couple of years is fine,but the one >> where we drop Python 2 support is probably the worst choice. That's one of >> the few things the co

Re: [Numpy-discussion] Type annotations for NumPy

On Tue, Dec 5, 2017 at 10:04 AM, Stephan Hoyer wrote: > This discussion has died down, but I don't want to lose momentum . > > It sounds like there is at least strong interest from a subset of our > community in type annotations. Are there any objections to the first part of > my plan, to start de

Re: [Numpy-discussion] NEP process update

On Tue, Dec 5, 2017 at 4:12 PM, Ralf Gommers wrote: > On Wed, Dec 6, 2017 at 12:31 PM, Jarrod Millman > wrote: >> Assuming that sounds good, my tentative next steps are: >> >> - I'll draft a purpose and process NEP based on PEP 1 and a few other >> projects. >> - I'll also create a draft NEP temp

Re: [Numpy-discussion] NEP process update

On Tue, Dec 5, 2017 at 5:32 PM, Ralf Gommers wrote: > > > On Wed, Dec 6, 2017 at 1:49 PM, Nathaniel Smith wrote: >> - NEPs are really part of the development process, not an output for >> end-users -- they're certainly useful to have available as a >> reference,

Re: [Numpy-discussion] Which rule makes x[np.newaxis, :] and x[np.newaxis] equivalent?

On Tue, Dec 12, 2017 at 12:02 AM, Joe wrote: > Hi, > > question says it all. I looked through the basic and advanced indexing, > but I could not find the rule that is applied to make > x[np.newaxis,:] and x[np.newaxis] the same. I think it's the general rule that all indexing expressions have an

Re: [Numpy-discussion] building numpy with python3.7

Try upgrading cython? On Fri, Dec 15, 2017 at 2:11 AM, Hannes Breytenbach wrote: > Hi devs! > > This is my first post to the discussion list! > > Has anyone tried to build numpy with python3.7.0a3? > > I get the following gcc errors during compile: > > . > . > . > > compiling C so

Re: [Numpy-discussion] building numpy with python3.7

On Fri, Dec 15, 2017 at 2:42 AM, Hannes Breytenbach wrote: > > I don't think this is a cython version issue - cloned the latest version from > git yesterday... > > python3.7 -c "import cython; print(cython.__version__)" > 0.28a0 It is a cython version issue: https://github.com/cython/cython/issu

[Numpy-discussion] Another grant update, & numpy job ad is up!

Hi all, Two exciting bits of news: 1) We just posted the announcement of a second grant to BIDS for NumPy, this time from the Sloan Foundation: https://bids.berkeley.edu/news/bids-receives-sloan-foundation-grant-contribute-numpy-development This is for $659,359 over two years, very similar to t

Re: [Numpy-discussion] Another grant update, & numpy job ad is up!

On Dec 22, 2017 8:35 AM, "Charles R Harris" wrote: On Thu, Dec 21, 2017 at 6:38 PM, Nathaniel Smith wrote: > Hi all, > > Two exciting bits of news: > > 1) We just posted the announcement of a second grant to BIDS for > NumPy, this time from the Sloan Foundation: &

Re: [Numpy-discussion] NumPy 1.14.0 release

On Sun, Jan 7, 2018 at 12:59 PM, Allan Haldane wrote: > On 01/07/2018 12:37 PM, Ralf Gommers wrote: >> >> >> >> On Sun, Jan 7, 2018 at 2:00 PM, Charles R Harris >> mailto:charlesr.har...@gmail.com>> wrote: >> >> Hi All, >> >> On behalf of the NumPy team, I am pleased to announce NumPy 1.14

[Numpy-discussion] RFC: comments to BLAS committee from numpy/scipy devs

Hi all, As mentioned earlier [1][2], there's work underway to revise and update the BLAS standard -- e.g. we might get support for strided arrays and lose xerbla! There's a draft at [3]. They're interested in feedback from users, so I've written up a first draft of comments about what we would lik

Re: [Numpy-discussion] [SciPy-Dev] RFC: comments to BLAS committee from numpy/scipy devs

On Tue, Jan 9, 2018 at 3:40 AM, Ilhan Polat wrote: > I couldn't find an item to place this but I think ilaenv and also calling > the function twice (one with lwork=-1 and reading the optimal block size and > the call the function again properly with lwork=) in LAPACK needs to > be gotten rid of. >

Re: [Numpy-discussion] [SciPy-Dev] RFC: comments to BLAS committee from numpy/scipy devs

On Tue, Jan 9, 2018 at 12:53 PM, Tyler Reddy wrote: > One common issue in computational geometry is the need to operate rapidly on > arrays with "heterogeneous shapes." > > So, an array that has rows with different numbers of columns -- shape (1,3) > for the first polygon and shape (1, 12) for the

Re: [Numpy-discussion] Moving NumPy's PRNG Forward

On Fri, Jan 19, 2018 at 6:55 AM, Robert Kern wrote: [...] > There seems to be a lot of pent-up motivation to improve on the random > number generation, in particular the distributions, that has been blocked by > our policy. I think we've lost a few potential first-time contributors that > have run

[Numpy-discussion] New NEP: merging multiarray and umath

Hi all, Well, this is something that we've discussed for a while and I think generally has consensus already, but I figured I'd write it down anyway to make sure. There's a rendered version here: https://github.com/njsmith/numpy/blob/nep-0015-merge-multiarray-umath/doc/neps/nep-0015-merge-multiar

Re: [Numpy-discussion] New NEP: merging multiarray and umath

On Thu, Mar 8, 2018 at 12:47 AM, Eric Wieser wrote: > This means that ndarray needs to know about ufuncs – so instead of a clean > layering, we have a circular dependency. > > Perhaps we should split ndarray into a base_ndarray class with no arithmetic > support (add, sum, etc), and then provide a

[Numpy-discussion] new NEP: np.AbstractArray and np.asabstractarray

Hi all, Here's a more substantive NEP: trying to define how to define a standard way for functions to say that they can accept any "duck array". Biggest open question for me: the name "asabstractarray" kinda sucks (for reasons described in the NEP), and I'd love to have something better. Any idea

Re: [Numpy-discussion] New NEP: merging multiarray and umath

On Thu, Mar 8, 2018 at 1:52 AM, Gregor Thalhammer wrote: > > Hi, > > long time ago I wrote a wrapper to to use optimised and parallelized math > functions from Intels vector math library > geggo/uvml: Provide vectorized math function (MKL) for numpy > > I found it useful to inject (some of) the fa

[Numpy-discussion] Where to discuss NEPs (was: Re: new NEP: np.AbstractArray and np.asabstractarray)

On Thu, Mar 8, 2018 at 7:06 AM, Marten van Kerkwijk wrote: > Hi Nathaniel, > > Overall, hugely in favour! For detailed comments, it would be good to > have a link to a PR; could you put that up? Well, there's a PR here: https://github.com/numpy/numpy/pull/10706 But, this raises a question :-).

Re: [Numpy-discussion] Where to discuss NEPs (was: Re: new NEP: np.AbstractArray and np.asabstractarray)

On Thu, Mar 8, 2018 at 10:26 PM, Ralf Gommers wrote: > > > On Thu, Mar 8, 2018 at 8:22 PM, Nathaniel Smith wrote: >> >> On Thu, Mar 8, 2018 at 7:06 AM, Marten van Kerkwijk >> wrote: >> > Hi Nathaniel, >> > >> > Overall, hugely in favour!

Re: [Numpy-discussion] new NEP: np.AbstractArray and np.asabstractarray

On Thu, Mar 8, 2018 at 7:06 AM, Marten van Kerkwijk wrote: > A larger comment: you state that you think `np.asanyarray` is a > mistake since `np.matrix` and `np.ma.MaskedArray` would pass through > and that those do not strictly mimic `NDArray`. Here, I agree with > `matrix` (but since we're depre

Re: [Numpy-discussion] new NEP: np.AbstractArray and np.asabstractarray

On Thu, Mar 8, 2018 at 9:45 PM, Stephan Hoyer wrote: > On Thu, Mar 8, 2018 at 5:54 PM Juan Nunez-Iglesias > wrote: >> >> On Fri, Mar 9, 2018, at 5:56 AM, Stephan Hoyer wrote: >> >> Marten's case 1: works exactly like ndarray, but stores data differently: >> parallel arrays (e.g., dask.array), spa

Re: [Numpy-discussion] Where to discuss NEPs (was: Re: new NEP: np.AbstractArray and np.asabstractarray)

On Fri, Mar 9, 2018 at 11:51 AM, Stefan van der Walt wrote: > On Fri, 09 Mar 2018 17:00:43 +, Stephan Hoyer wrote: >> I'll note that we basically used GitHub for revising __array_ufunc__ NEP, >> and I think that worked out better for everyone involved. The discussion >> was a little too specia

Re: [Numpy-discussion] New NEP: merging multiarray and umath

On Fri, Mar 9, 2018 at 3:33 AM, Julian Taylor wrote: > As the functions of the different libraries have vastly different > accuracies you want to be able to exchange numeric ops at runtime or at > least during load time (like our cblas) and not limit yourself one > compile time defined set of func

Re: [Numpy-discussion] new NEP: np.AbstractArray and np.asabstractarray

On Thu, Mar 8, 2018 at 5:51 PM, Juan Nunez-Iglesias wrote: >> Finally for the name, what about `asduckarray`? Thought perhaps that could >> be a source of confusion, and given the gradation of duck array like types. > > I suggest that the name should *not* use programmer lingo, so neither > "abstr

Re: [Numpy-discussion] New NEP: merging multiarray and umath

On Mar 12, 2018 12:02, "Charles R Harris" wrote: If we accept this NEP, I'd like to get it done soon, preferably and the next few months, so that it is finished before we drop Python 2.7 support. That will make maintenance of the NumPy long term support release through 2019 easier. The reason

Re: [Numpy-discussion] PR to add a function to calculate histogram edges without calculating the histogram

Instead of an nobs argument, maybe we should have a version that accepts multiple data sets, so that we have the full information and can improve the algorithm over time. On Mar 15, 2018 7:57 PM, "Thomas Caswell" wrote: > Yes I like the name. > > The primary use-case for Matplotlib is that our `

Re: [Numpy-discussion] PR to add a function to calculate histogram edges without calculating the histogram

s passed to the individual > histogram invocations. Does matplotlib handle that correctly for stacked > histograms? > > On Thu, Mar 15, 2018, 20:14 Nathaniel Smith wrote: > >> Instead of an nobs argument, maybe we should have a version that accepts >> multiple data sets, so that w

Re: [Numpy-discussion] new NEP: np.AbstractArray and np.asabstractarray

On Sat, Mar 10, 2018 at 4:27 AM, Matthew Rocklin wrote: > I'm very glad to see this discussion. > > I think that coming up with a single definition of array-like may be > difficult, and that we might end up wanting to embrace duck typing instead. > > It seems to me that different array-like classe

Re: [Numpy-discussion] round(numpy.float64(0.0)) is a numpy.float64

Even knowing that, it's still confusing that round(np.float64(0.0)) isn't the same as round(0.0). The reason is a Python 2 / Python 3 thing: in Python 2, round returns a float, while on Python 3, it returns an integer – but numpy still uses the python 2 behavior everywhere. I'm not sure if it's po

Re: [Numpy-discussion] round(numpy.float64(0.0)) is a numpy.float64

On Mon, Mar 26, 2018 at 6:24 PM, Nathaniel Smith wrote: > Even knowing that, it's still confusing that round(np.float64(0.0)) > isn't the same as round(0.0). The reason is a Python 2 / Python 3 > thing: in Python 2, round returns a float, while on Python 3, it > returns

Re: [Numpy-discussion] Turn numpy.ones_like into a ufunc

I would like to see a plan for how we're going to handle zeroes_like, empty_like, ones_like, and full_like before we start making changes to any of them. On Fri, May 18, 2018, 05:33 Matthew Rocklin wrote: > Hi All, > > I would like to see the numpy.ones_like function operate as a ufunc. > This i

Re: [Numpy-discussion] Efficiency of Numpy wheels and simple way to benchmark Numpy installation?

Performance is an incredibly multi-dimensional thing. Modern computers are incredibly complex, with layers of interacting caches, different microarchitectural features (do you have AVX2? does your cpu's branch predictor interact in a funny way with your workload?), compiler optimizations that vary

Re: [Numpy-discussion] matmul as a ufunc

On Mon, May 28, 2018 at 4:26 PM, Stephan Hoyer wrote: > On Mon, May 21, 2018 at 5:42 PM Matti Picus wrote: >> >> - create a wrapper that can convince the ufunc mechanism to call >> __array_ufunc__ even on functions that are not true ufuncs > > > I am somewhat opposed to this approach, because __a

Re: [Numpy-discussion] matmul as a ufunc

On Mon, May 28, 2018, 20:41 Stephan Hoyer wrote: > On Mon, May 28, 2018 at 7:36 PM Eric Wieser > wrote: > >> which ensure that it is still well defined (as the identity) on 1d >> arrays. >> >> This strikes me as a bad idea. There’s already enough confusion from >> beginners that array_1d.T is a

Re: [Numpy-discussion] Allowing broadcasting of code dimensions in generalized ufuncs

On Wed, May 30, 2018 at 11:14 AM, Marten van Kerkwijk wrote: > Hi All, > > Following on a PR combining the ability to provide fixed and flexible > dimensions [1] (useful for, e.g., 3-vector input with a signature like > `(3),(3)->(3)`, and for `matmul`, resp.; based on earlier PRs by Jaime > [2] a

Re: [Numpy-discussion] Allowing broadcasting of code dimensions in generalized ufuncs

On Thu, May 31, 2018 at 4:20 AM, Marten van Kerkwijk wrote: > Hi Nathaniel, > > I think the case for frozen dimensions is much more solid that just > `cross1d` - there are many operations that work on size-3 vectors. > Indeed, as I noted in the PR, I have just been wrapping a > Standards-of-Astron

Re: [Numpy-discussion] NEP: Random Number Generator Policy

On Sun, Jun 10, 2018 at 11:53 PM, Ralf Gommers wrote: > > On Sun, Jun 10, 2018 at 11:15 PM, Robert Kern wrote: >> >> The intention of this code is to shuffle two same-length sequences in the >> same way. So now if I write my code well to call np.random.seed() once at >> the start of my program, t

[Numpy-discussion] Proposal to accept NEP 15: Merging multiarray and umath

Hi all, I propose that we accept NEP 15: Merging multiarray and umath: http://www.numpy.org/neps/nep-0015-merge-multiarray-umath.html The core part of this proposal was uncontroversial. The main point of discussion was whether it was OK to deprecate set_numeric_ops, or whether it had some legiti

Re: [Numpy-discussion] Proposal to accept NEP 15: Merging multiarray and umath

un 29, 2018 at 3:18 PM, Nathaniel Smith wrote: > Hi all, > > I propose that we accept NEP 15: Merging multiarray and umath: > > http://www.numpy.org/neps/nep-0015-merge-multiarray-umath.html > > The core part of this proposal was uncontroversial. The main point of > discus

Re: [Numpy-discussion] Proposal to accept NEP 15: Merging multiarray and umath

On Fri, Jun 29, 2018 at 3:28 PM, Marten van Kerkwijk wrote: > Agreed on accepting the NEP! But it is not the first proposal to accept > under the new rules - that goes to the broadcasting NEP (though perhaps I > wasn't sufficiently explicit in stating that I was starting a > count-down...). -- Mar

Re: [Numpy-discussion] Fwd: Allowing broadcasting of code dimensions in generalized ufuncs

On Sat, Jun 30, 2018 at 6:51 AM, Marten van Kerkwijk wrote: > Hi All, > > In case it was missed because people have tuned out of the thread: Matti and > I proposed last Tuesday to accept NEP 20 (on coming Tuesday, as per NEP 0), > which introduces notation for generalized ufuncs allowing fixed, fl

  1   2   >