[Numpy-discussion] argmin/argmax underspecification?

The docs say "Returns the indices of the maximum values along an axis." When axis=None, I presume the implementation is actually "Returns the first index (assuming ravel ordering) of the maximum value." I also presume that people are now relying on the fact that it always returns the first suc

[Numpy-discussion] Consistency of random number functions APIs.

Some NumPy random number generation functions take a dtype parameter whereas others don't. Some of them take an out parameter whereas others don't. Just glancing at it, there seems to be no rhyme or reason why this would be the case but is there some hidden consistency underneath the hood to e

Re: [Numpy-discussion] size of arrays

ent is smaller than one array > with size of 100 elements? > > 14.03.2021, 00:06, "Todd" : > > Ideally float64 uses 64 bits for each number while float16 uses 16 bits. > 64/16=4. However, there is some additional overhead. This overhead makes > up a large po

Re: [Numpy-discussion] size of arrays

Ideally float64 uses 64 bits for each number while float16 uses 16 bits. 64/16=4. However, there is some additional overhead. This overhead makes up a large portion of small arrays, but becomes negligible as the array gets bigger. On Sat, Mar 13, 2021, 16:01 wrote: > Dear colleagues! > > Size

Re: [Numpy-discussion] String accessor methods

On Sat, Mar 6, 2021 at 12:57 PM dan_patterson wrote: > The are in np.char > > mystr = np.array(["test first", "test second", "test third"]) > > np.char.title(mystr) > array(['Test First', 'Test Second', 'Test Third'], dtype=' I mentioned those in my email, but they are far less convenient to us

[Numpy-discussion] String accessor methods

Currently. working with strings in numpy is not very convenient. You have to use a separate set of functions in a separate namespace, and those functions are relatively limited and poorly-documented. A solution several other projects, including pandas [0] and xarray [1], have found are string acce

Re: [Numpy-discussion] Proposal to add clause to license prohibiting use by oil and gas extraction companies

On Thu, Jul 2, 2020 at 5:06 PM John Preston wrote: > Thank you all for your input on this proposal. I am very grateful for > the time you have all spent to provide such well reasoned critiques > and I'm especially glad to see that this thread has triggered > discussion of other, more pragmatic, a

Re: [Numpy-discussion] Put type annotations in NumPy proper?

What about migrating numpy-stubs over time to just be a literal stub for numpy's own built-in implications? Once numpy's version is done, a depreciation warming can then be added to numpy-stubs. On Tue, Mar 24, 2020, 14:15 Eric Wieser wrote: > > Putting > > aside ndarray, as more challenging,

Re: [Numpy-discussion] ENH: Add Moving Average Function

I think having some function for common cases like moving average and spectrogram would be good. Having a jumping-off point and simple reference for testing against could encourage someone to make a faster implementation down the road. -Todd On Mon, Aug 26, 2019 at 12:24 AM Stephan Hoyer wrote

Re: [Numpy-discussion] Syntax Improvement for Array Transpose

int here. I haven't seen any bugs because > somebody thought they are just transposing. > > Using transpose to reshape an array is a different story. That we can > discuss. > > On Tue, Jun 25, 2019, 16:10 Todd wrote: > >> That is how it is in your field, but not mine. F

Re: [Numpy-discussion] Syntax Improvement for Array Transpose

On Tue, Jun 25, 2019 at 11:47 AM Alan Isaac wrote: > On 6/25/2019 11:03 AM, Todd wrote: > > Fair enough. But although there are valid reasons to do a divide by > zero, it still causes a warning because it is a problem often enough that > people should be made aware of it. I >

Re: [Numpy-discussion] Syntax Improvement for Array Transpose

On Tue, Jun 25, 2019 at 10:42 AM Stephan Hoyer wrote: > On Tue, Jun 25, 2019 at 7:20 AM Todd wrote: > >> On Tue, Jun 25, 2019 at 9:35 AM Juan Nunez-Iglesias >> wrote: >> >>> On Mon, 24 Jun 2019, at 11:25 PM, Marten van Kerkwijk wrote: >>> >&g

Re: [Numpy-discussion] Syntax Improvement for Array Transpose

On Tue, Jun 25, 2019 at 9:35 AM Juan Nunez-Iglesias wrote: > On Mon, 24 Jun 2019, at 11:25 PM, Marten van Kerkwijk wrote: > > Just to be sure: for a 1-d array, you'd both consider `.T` giving a shape > of `(n, 1)` the right behaviour? I.e., it should still change from what it > is now - which is

Re: [Numpy-discussion] Syntax Improvement for Array Transpose

That is how it is in your field, but not mine. For us we only use the conventional transpose, even for complex numbers. And I routinely see bugs in MATLAB because of its choice of defaults, and there are probably many more that don't get caught because they happen silently. I think the principle

Re: [Numpy-discussion] Syntax Improvement for Array Transpose

On Mon, Jun 24, 2019 at 11:00 AM Stephan Hoyer wrote: > On Sun, Jun 23, 2019 at 10:05 PM Stewart Clelland < > stewartclell...@gmail.com> wrote: > >> Hi All, >> >> Based on discussion with Marten on github >> , I have a couple of >> suggestions on synta

Re: [Numpy-discussion] Syntax Improvement for Array Transpose

I think the corresponding MATLAB function/operation is this: https://www.mathworks.com/help/matlab/ref/transpose.html On Mon, Jun 24, 2019, 10:33 Alan Isaac wrote: > Points of reference: > Mathematica: https://reference.wolfram.com/language/ref/Transpose.html > Matlab: https://www.mathworks.co

Re: [Numpy-discussion] Syntax Improvement for Array Transpose

I think we need to do something about the 1D case. I know from a strict mathematical standpoint it doesn't do anything, and philosophically we should avoid special cases, but I think the current solution leads to enough confusion and silently doing an unexpected thing that I think we need a better

Re: [Numpy-discussion] Add guaranteed no-copy to array creation and reshape?

On Thu, Jan 10, 2019, 01:55 Eric Wieser Slicing is a lot more important than some keyword. And design-wise, > filling the numpy namespace with singletons for keyword to other things in > that same namespace just makes no sense to me. > > At least from the perspective of discoverability, you could

Re: [Numpy-discussion] Add guaranteed no-copy to array creation and reshape?

On Wed, Dec 26, 2018, 18:29 Sebastian Berg 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 gua

Re: [Numpy-discussion] Add guaranteed no-copy to array creation and reshape?

On Mon, Jan 7, 2019, 14:22 Feng Yu Hi, > > Was it ever brought up the possibility of a new array class (ndrefonly, > ndview) that is strictly no copy? > > All operations on ndrefonly will return ndrefonly and if the operation > cannot be completed without making a copy, it shall throw an error. >

Re: [Numpy-discussion] A roadmap for NumPy - longer term planning

On Fri, Jun 1, 2018, 11:27 Todd wrote: > > > On Thu, May 31, 2018, 19:50 Matti Picus wrote: > >> At the recent NumPy sprint at BIDS (thanks to those who made the trip) >> we spent some time brainstorming about a roadmap for NumPy, in the >> spirit of similar work

Re: [Numpy-discussion] A roadmap for NumPy - longer term planning

On Thu, May 31, 2018, 19:50 Matti Picus wrote: > At the recent NumPy sprint at BIDS (thanks to those who made the trip) > we spent some time brainstorming about a roadmap for NumPy, in the > spirit of similar work that was done for Jupyter. The idea is that a > document with wide community accept

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

On Nov 30, 2017 09:24, "Marten van Kerkwijk" wrote: Hi All, I wondered if the move to python3-only starting with numpy 1.17 would be a good reason to act on what we all seem to agree: that the matrix class was a bad idea, with its overriding of multiplication and lack of support for stacks of ma

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

On Nov 9, 2017 20:52, "Nathaniel Smith" wrote: 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 ma