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

Perhaps `np.encoded_str[encoding]` as the name for the new type, if we decide a new type is necessary? Am I right in thinking that the general problem here is that it's very easy to discard metadata when working with dtypes, and that by adding metadata to `unicode_`, we risk existing code

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

> if you truncate a utf-8 bytestring, you may get invalid data Note that in general truncating unicode codepoints is not a safe operation either, as combining characters are a thing. So I don't think this is a good argument against UTF8. Also, is silent truncation a think that we want to allow

Re: [Numpy-discussion] How to compare an array of arrays elementwise to None in Numpy 1.13 (was easy before)?

Here’s a hack that lets you keep using ==: class IsCompare: __array_priority__ = 99 # needed to make it work on either side of `==` def __init__(self, val): self._val = val def __eq__(self, other): return other is self._val def __neq__(self, other): return other is not

[Numpy-discussion] Changing MaskedArray.squeeze() to never return masked

When using ndarray.squeeze, a view is returned, which means you can do the follow (somewhat-contrived) operation: >>> def fill_contrived(a): a.squeeze()[...] = 2 return a >>> fill_contrived(np.array([1])) array(2) However, when tried with a masked array, this can fail, breaking

Re: [Numpy-discussion] Vector stacks

What would these classes offer over these simple functions: def rvec(x): return x[...,np.newaxis,:]def cvec(x): return x[...,:,np.newaxis] That also makes rvec(x) + cvec(y) behave in the least surprising way, with no extra work Eric ​ On Sat, 1 Jul 2017 at 23:32 Charles R Harris

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

> I think we can implement viewers for strings as ndarray subclasses. Then one > could > do `my_string_array.view(latin_1)`, and so on. Essentially that just > changes the default > encoding of the 'S' array. That could also work for uint8 arrays if needed. > > Chuck To handle structured

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

Chuck: That sounds like something we want to deprecate, for the same reason that python3 no longer allows str(b'123') to do the right thing. Specifically, it seems like astype should always be forbidden to go between unicode and byte arrays - so that would need to be written as: In [1]: a =

Re: [Numpy-discussion] How to concatenate 2 recarrays into a single recarray

If that's the case, can you file an issue on github along with a minimal example that produces the error, and the full stack trace? On Thu, 11 May 2017 at 19:29 Isaac Gerg wrote: > newtable = np.lib.recfunctions.merge_arrays([a, b], asrecarray=True) > > yeilds: > >

Re: [Numpy-discussion] How to concatenate 2 recarrays into a single recarray

On Thu, May 11, 2017 at 2:31 PM, Eric Wieser <wieser.eric+nu...@gmail.com> > wrote: > >> If that's the case, can you file an issue on github along with a minimal >> example that produces the error, and the full stack trace? >> >> On Thu, 11 May 2017

Re: [Numpy-discussion] accumulating version of numpy.put?

Frank, I think you’re looking for np.add.at(a, ind, v), documented here Eric ​ On Fri, 19 May 2017 at 17:13 Frank Horowitz wrote: > Hi All, > > In the numpy library, are there any equivalences of

Re: [Numpy-discussion] Does x[True] trigger basic or advanced indexing?

Increasingly, NumPy does not considers booleans to be integer types, and indexing is one of these cases. So no, it will not be treated as a tuple of integers, but as a 0d mask Eric On Wed, 13 Dec 2017 at 12:44 Joe wrote: > Hi, > > yet another question. > > I looked

Re: [Numpy-discussion] np.vstack vs. np.stack

I think the primary problems with it are: - A poor definition of “vertical” in the world of stacked matrices - in np.linalg land, this means axis=-2, but in vstack land, it means axis=0. - Mostly undocumented auto-2d behavior that doesn’t make you think well enough about dimensions.

Re: [Numpy-discussion] The meaning of threshold in numpy.set_printoptions()?

Whether summarization happens is also determined by edgeitems (defaults to 3), which is the number of items to print on each edge when summarizing. It wouldn’t make sense for summarization to cause the output to be longer than if no summarization occured! Feel free to submit an improvement to

Re: [Numpy-discussion] MATLAB to Numpy

David, that doesn’t work, because np.cumsum(mask)[mask] is always equal to np.arange(mask.sum()) + 1. Robert’s answer is correct. Eric On Sat, 21 Oct 2017 at 13:12 Daπid wrote: On 21 October 2017 at 21:03, Robert Kern wrote: > >> Index with a

Re: [Numpy-discussion] Changing the return type of np.histogramdd

r 2018 at 22:26 Ralf Gommers <ralf.gomm...@gmail.com> wrote: > On Wed, Apr 25, 2018 at 11:00 PM, Eric Wieser <wieser.eric+nu...@gmail.com > > wrote: > >> For precision loss of the order of float64 eps, I disagree. >> >> I was thinking more about precision loss

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

I don’t understand your alternative here. If we overload np.matmul using *array_function*, then it would not use *ether* of these options for writing the operation in terms of other gufuncs. It would simply look for an *array_function* attribute, and call that method instead. Let me explain that

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

ing a reduction with a broadcasting ufunc? Eric On Sun, 10 Jun 2018 at 16:02 Eric Wieser wrote: Rendered here: > https://github.com/mhvk/numpy/blob/nep-gufunc-signature-enhancement/doc/neps/nep-0020-gufunc-signature-enhancement.rst > > > Eric > > On Sun, 10 Jun 2018 at 09:3

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

Rendered here: https://github.com/mhvk/numpy/blob/nep-gufunc-signature-enhancement/doc/neps/nep-0020-gufunc-signature-enhancement.rst Eric On Sun, 10 Jun 2018 at 09:37 Marten van Kerkwijk wrote: > OK, I spent my Sunday morning writing a NEP. I hope this can lead to some > closure... > See

Re: [Numpy-discussion] matmul as a ufunc

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 no-op. If we introduce a matrix-transpose, it should either error on <1d inputs with a useful message, or insert the extra

[Numpy-discussion] Adding take_along_axis and put_along_axis functions

These functions provide a vectorized way of using one array to look up items in another. In particular, they extend the 1d: a = np.array([4, 5, 6, 1, 2, 3]) b = np.array(["four", "five", "six", "one", "two", "three"]) i = a.argsort() b_sorted = b[i] To work for higher-dimensions: a =

Re: [Numpy-discussion] Polynomial evaluation inconsistencies

Here's my take on this, but it may not be an accurate summary of the history. `np.poly` is part of the original matlab-style API, built around `poly1d` objects. This isn't a great design, because they represent: p(x) = c[0] * x^2 + c[1] * x^1 + c[2] * x^0 For this reason, among others, the

Re: [Numpy-discussion] Revised NEP-18, __array_function__ protocol

- irrespective of the resolution of the discussion on python-dev. Eric ​ On Fri, 29 Jun 2018 at 18:24 Stephan Hoyer wrote: > On Thu, Jun 28, 2018 at 5:36 PM Eric Wieser > wrote: > >> Another option would be to directly compare the methods against known >> ones: >

Re: [Numpy-discussion] NEP 21: Simplified and explicit advanced indexing

> Hameer Abbasi > > Sent from Astro for Mac > > > > > On 26. Jun 2018 at 09:46, Robert Kern > > > wrote: > > > > > > On Tue, Jun 26, 2018 at 12:13 AM Eric Wieser > > il.com> wrote: > > > > > I don't think it should be

Re: [Numpy-discussion] NEP 21: Simplified and explicit advanced indexing

Generally +1 on this, but I don’t think we need To ensure that existing subclasses of ndarray that override indexing do not inadvertently revert to default behavior for indexing attributes, these attribute should have explicit checks that disable them if __getitem__ or __setitem__ has been

Re: [Numpy-discussion] NEP 21: Simplified and explicit advanced indexing

> I don't think it should be relegated to the "officially discouraged" ghetto of `.legacy_index` The way I read it, the new spelling lof that would be the explicit but not discouraged `image.vindex[rr, cc]`. > I would reserve warnings for the cases where the current behavior is something no one

Re: [Numpy-discussion] NEP 21: Simplified and explicit advanced indexing

Another thing I’d say is arr.?index should be replaced with arr.?idx. Or perhaps arr.o_[] and arr.v_[], to match the style of our existing np.r_, np.c_, np.s_, etc? ___ NumPy-Discussion mailing list NumPy-Discussion@python.org

Re: [Numpy-discussion] Polynomial evaluation inconsistencies

olyval() to use conventional indexing (c[0] > * x^0 + c[1] * x^1 + c[2] * x^2). np.polyval() can be convenient when a > polynomial object is just not needed, but if a single program uses both > np.polyval() and np.polynomail.Polynomial, it seems bound to cause > unnecessary confusion. > >

Re: [Numpy-discussion] Polynomial evaluation inconsistencies

But shouldn't it call >> the constructor with Polynomial([0,1])? >> >> On Sat, Jun 30, 2018 at 5:41 PM, Eric Wieser > > wrote: >> >>> Since the one of the arguments for the decreasing order seems to just be >>> textual representation - do we want to tweak th

Re: [Numpy-discussion] Polynomial evaluation inconsistencies

“the intuitive way” is the decreasing powers. An argument against this is that accessing the ith power of x is spelt: - x.coeffs[i] for increasing powers - x.coeffs[-i-1] for decreasing powers The former is far more natural than the latter, and avoids a potential off-by-one error If I

Re: [Numpy-discussion] Polynomial evaluation inconsistencies

Eric Wieser wrote: > “the intuitive way” is the decreasing powers. > > An argument against this is that accessing the ith power of x is spelt: > >- x.coeffs[i] for increasing powers >- x.coeffs[-i-1] for decreasing powers > > The former is far more natural tha

Re: [Numpy-discussion] Extending ufunc signature syntax for matmul, frozen dimensions

I think I’m -1 on this - this just makes things harder on the implementers of _array_ufunc__ who now might have to work out which signature matches. I’d prefer the solution where np.matmul is a wrapper around one of three gufuncs (or maybe just around one with axis insertion) - this is similar to

Re: [Numpy-discussion] Changing the return type of np.histogramdd

scipy functions from the basic numpy ones? ​ On Wed, 25 Apr 2018 at 22:51 Ralf Gommers <ralf.gomm...@gmail.com> wrote: > On Wed, Apr 25, 2018 at 10:07 PM, Eric Wieser <wieser.eric+nu...@gmail.com > > wrote: > >> what does that gain over having the user do something li

Re: [Numpy-discussion] Changing the return type of np.histogramdd

aw too, but I suppose that can be dealt with separately. Eric ​ On Wed, 25 Apr 2018 at 21:57 Ralf Gommers <ralf.gomm...@gmail.com> wrote: > On Mon, Apr 9, 2018 at 10:24 PM, Eric Wieser <wieser.eric+nu...@gmail.com> > wrote: > >> Numpy has three histogram f

Re: [Numpy-discussion] numpy.pad -- problem?

I would consider this a bug, and think we should fix this. On Sun, 29 Apr 2018 at 13:48 Virgil Stokes wrote: > Here is a python code snippet: > > # python vers. 3.6.5 (v3.6.5:f59c0932b4, Mar 28 2018, 17:00:18) [MSC > v.1900 64 bit (AMD64)] > import numpy as np # numpy vers.

Re: [Numpy-discussion] Setting custom dtypes and 1.14

Why is the list of tuples a useful thing to have in the first place? If the goal is to convert an array into a structured array, you can do that far more efficiently with: def make_tup_dtype(arr): """ Attempt to make a type capable of viewing the last axis of an array, even if it is

Re: [Numpy-discussion] Setting custom dtypes and 1.14

Apologies, it seems that I skipped to the end of @ahaldane's remark - we're on the same page. On Fri, 26 Jan 2018 at 11:17 Eric Wieser <wieser.eric+nu...@gmail.com> wrote: > Why is the list of tuples a useful thing to have in the first place? If > the goal is to conv

Re: [Numpy-discussion] Setting custom dtypes and 1.14

arr.names should have been arr.dtype.names in that pack_last_axis function Eric ​ On Fri, 26 Jan 2018 at 12:45 Chris Barker wrote: > On Fri, Jan 26, 2018 at 10:48 AM, Allan Haldane > wrote: > >> > What do folks think about a totuple() method —

Re: [Numpy-discussion] Setting custom dtypes and 1.14

I think that there's a lot of confusion going around about recarrays vs structured arrays. [`recarray`]( https://github.com/numpy/numpy/blob/v1.13.0/numpy/core/records.py) are a wrapper around structured arrays that provide: * Attribute access to fields as `arr.field` in addition to the normal

Re: [Numpy-discussion] NumPy should not silently promote numbers to strings

Presumably you would extend that to all (str, np.number), or even (str, np.generic_)? I suppose there’s the argument that with python-3-only support around the corner, even (str, bytes) should go to object. Right now, promote_types gives examples in the docs of int/string conversions, so changing

Re: [Numpy-discussion] Remove sctypeNA and typeNA from numpy core

> I bet the NA is for the missing value support thatnever happened Nope - NA stands for NumArray Eric On Thu, 21 Jun 2018 at 11:07 Sebastian Berg wrote: > On Thu, 2018-06-21 at 09:25 -0700, Matti Picus wrote: > > numpy.core has many ways to catalogue dtype names: sctypeDict, > > typeDict > >

Re: [Numpy-discussion] pytest, fixture and parametrize

Is another nice feature You forget that we already have that feature in our testing layer, with np.testing.assert_raises(AnException): pass ​ On Wed, 8 Aug 2018 at 09:08 Chris Barker - NOAA Federal < chris.bar...@noaa.gov> wrote: > BTW: > > with pytest.raises(AnException): > > >

Re: [Numpy-discussion] Possible Deprecation of np.ediff1d

There is already a patch to add such a feature to np.diff at https://github.com/numpy/numpy/pull/8206 ​ On Mon, 27 Aug 2018 at 10:47 Charles R Harris wrote: > On Mon, Aug 27, 2018 at 11:37 AM Robert Kern > wrote: > >> On Mon, Aug 27, 2018 at 10:30 AM Tyler Reddy >> wrote: >> >>> Chuck

Re: [Numpy-discussion] C99

Thanks for the first step on this! Should we allow // style comments I don’t think it matters too much. I think it might be a little messy to have a mix of the two styles where // means “post py3” and /* */ means pre-py3 - but at the same time, I do slightly prefer the C++-style. For C

Re: [Numpy-discussion] NumPy 1.14.0 release

Did recarrays change? I didn’t see anything in the release notes. Not directly, but structured arrays did , for which recarrays are really just a thin and somewhat buggy

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

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 an ndarray subclass from umath instead (either the separate

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

his is not >> actually what we want >> >> Tom >> >> On Mon, Mar 12, 2018 at 11:35 PM <josef.p...@gmail.com> wrote: >> >>> On Mon, Mar 12, 2018 at 11:20 PM, Eric Wieser >>> <wieser.eric+nu...@gmail.com> wrote: >>> >&g

Re: [Numpy-discussion] Adding a return value to np.random.shuffle

I’m against this change, because it: - Is inconsistent with the builtin random.shuffle - Makes it easy to fall into the trap of assuming that np.random.shuffle does not mutate it’s input Eric ​ On Thu, 12 Apr 2018 at 10:37 Joseph Fox-Rabinovitz wrote: >

[Numpy-discussion] Changing the return type of np.histogramdd

Numpy has three histogram functions - histogram, histogram2d, and histogramdd. histogram is by far the most widely used, and in the absence of weights and normalization, returns an np.intp count for each bin. histogramdd (for which histogram2d is a wrapper) returns np.float64 in all

Re: [Numpy-discussion] PR to add an initializer kwarg to ufunc.reduce (and similar functions)

ame "initial_value", but > consistency with functools.reduce makes a compelling case for "initializer". > > On Sun, Mar 25, 2018 at 1:15 PM Eric Wieser <wieser.eric+nu...@gmail.com> > wrote: > >> To reiterate my comments in the issue - I'm in favor o

Re: [Numpy-discussion] PR to add an initializer kwarg to ufunc.reduce (and similar functions)

ools.reduce > > > Sent from Astro <https://www.helloastro.com> for Mac > > On Mar 26, 2018 at 09:54, Eric Wieser <wieser.eric+nu...@gmail.com> wrote: > > > It turns out I mispoke - functools.reduce calls the argument `initial` > > On Mon, 26 Mar 2018 at 00

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

I would have thought that a simple tuple of types would be more appropriate than using integer flags, since that means that isinstance can be used on the individual elements. Ideally there’d be a typing.Intersection[TraitA, TraitB] for this kind of thing. ​ On Sat, 17 Mar 2018 at 15:10 Thomas

Re: [Numpy-discussion] Revised NEP-18, __array_function__ protocol

Another option would be to directly compare the methods against known ones: obj = func.__self__ if isinstance(obj, np.ufunc): if func is obj.reduce: got_reduction() Eric ​ On Thu, 28 Jun 2018 at 17:19 Stephan Hoyer wrote: > On Thu, Jun 28, 2018 at 1:12 PM Marten van Kerkwijk < >

Re: [Numpy-discussion] ndrange, like range but multidimensiontal

gt;> m[tuple(ind)] 1.0 On Wed, 10 Oct 2018 at 09:08 Stephan Hoyer sho...@gmail.com <http://mailto:sho...@gmail.com> wrote: On Tue, Oct 9, 2018 at 9:34 PM Eric Wieser > wrote: > >> One thing that worries me here - in python, range(...) in essence >> generates a lazy list

Re: [Numpy-discussion] ndrange, like range but multidimensiontal

/18 12:34 AM, Eric Wieser wrote: > > One thing that worries me here - in python, |range(...)| in essence > > generates a lazy |list| - so I’d expect |ndrange| to generate a lazy > > |ndarray|. In practice, that means it would be a duck-type defining an > > |__array__| m

Re: [Numpy-discussion] ndrange, like range but multidimensiontal

to. > > I'm not sure if we ever want the `ndrange` object to return a full matrix. > It seems like we would be creating a custom tuple class just for this which > seems pretty niche. > > > On Thu, Oct 11, 2018 at 10:21 AM Eric Wieser > wrote: > >> Isn’t that what a

Re: [Numpy-discussion] asanyarray vs. asarray

ept as "soft support". We >>> intend to not break anything that now has asanyarray, i.e. it's supported >>> and ideally we have regression tests for all such functions. For anything >>> we transition over from asarray to asanyarray, PRs should come with new >

Re: [Numpy-discussion] asanyarray vs. asarray

The latter - changing the behavior of multiplication breaks the principle. But this is not the main reason for deprecating matrix - almost all of the problems I’ve seen have been caused by the way that matrices behave when sliced. The way that m[i][j] and m[i,j] are different is just one example

Re: [Numpy-discussion] Attribute hiding APIs for PyArrayObject

In NumPy 1.14 we changed UPDATEIFCOPY to WRITEBACKIFCOPY, and in 1.16 we would like to deprecate PyArray_SetNumericOps and PyArray_GetNumericOps. The strange warning when NPY_NO_DEPRICATED_API is annoying I’m not sure I make the connection here between hidden fields and API deprecation. You seem

Re: [Numpy-discussion] Depreciating asfortranarray and ascontiguousarray

in order to be used prior to calling C or Fortran code that expected at least a 1-d array I’d argue that the behavior for these functions should have just been to raise an error saying “this function does not support 0d arrays”, rather than silently inserting extra dimensions. As a bonus, that

Re: [Numpy-discussion] asarray/anyarray; matrix/subclass

> If the only way MaskedArray violates Liskov is in terms of NA skipping aggregations by default, then this might be viable One of the ways to fix these liskov substitution problems is just to introduce more base classes - for instance, if we had an `NDContainer` base class with only slicing

Re: [Numpy-discussion] numpy pprint?

how L R U P or combination of these >plus some numbers (similar to Pandas .head .tail) methods and then show the >rest by unicod 3dot > > P.S. I had no idea our university Microsoft services also offers Azure > Notebooks awesome :P > > F. > > On Tue, Nov

Re: [Numpy-discussion] numpy pprint?

ked for it :)) > for IPython/Jupyter using Markdown/LaTeX would be awesome > or even better using HTML to add sliders just like Pandas... > > F. > > On Tue, Nov 6, 2018 at 6:51 AM Eric Wieser > wrote: > >> Hijacking this thread while on the topic of pprint - we might want to >&g

Re: [Numpy-discussion] numpy pprint?

Hijacking this thread while on the topic of pprint - we might want to look into a table-based `_html_repr_` or `_latex_repr_` for use in ipython - where we can print the full array and let scrollbars replace ellipses. Eric On Mon, 5 Nov 2018 at 21:11 Mark Harfouche wrote: > Foad, > >

Re: [Numpy-discussion] Vectorized version of numpy.linspace

I too buy into axis=0 being the better default here for broadcasting reasons. Having it possible to specify explicitly would be handy though, for something like: x_ramped = np.linspace(x.min(axis=2), x.max(axis=2), 100, axis=2) ​ On Wed, 14 Nov 2018 at 15:20 Stephan Hoyer wrote: > On Wed, Nov

Re: [Numpy-discussion] ndrange, like range but multidimensiontal

One thing that worries me here - in python, range(...) in essence generates a lazy list - so I’d expect ndrange to generate a lazy ndarray. In practice, that means it would be a duck-type defining an __array__ method to evaluate it, and only implement methods already present in numpy. It’s not

Re: [Numpy-discussion] Adding a hex version like PY_VERSION_HEX

+1 on Ralf's suggestion. I'm not sure there's any case where the C code should be using a hex version number - either it's using the C api, in which case it should just be looking at the C api version - or it's calling back into the python API, in which case it's probably not unreasonable to ask

Re: [Numpy-discussion] py3k.os_fspath enforces inconsist rules with python3 os.fspath

This looks like a bug to me - can you file it on the issue tracker. Evidently I did not consider python 2 behavior when backporting `os.fspath` from python 3. Eric On Mon, 14 Jan 2019 at 16:28 Stuart Reynolds wrote: > After a recent upgrade of numpy (1.13.1 -> 1.6.0), my code is failing >

Re: [Numpy-discussion] three-dim array

In the latest version of numpy, this runs without an error, although may or may not be what you want: In [1]: np.array([[1,2],[[1,2],[3,4]]]) Out[1]: array([[1, 2], [list([1, 2]), list([3, 4])]], dtype=object) Here the result is a 2x2 array, where some elements are numbers and others are

Re: [Numpy-discussion] three-dim array

get accepted this way. > > On Wed, Dec 26, 2018 at 1:59 AM Eric Wieser > wrote: > >> In the latest version of numpy, this runs without an error, although may >> or may not be what you want: >> >> In [1]: np.array([[1,2],[[1,2],[3,4]]]) >> Out[1]: >>

Re: [Numpy-discussion] lstsq underdetermined behaviour

> In 1.15 the call is instead to `_umath_linalg.lstsq_m` and I'm not sure what this actually ends up doing - does this end up being the same as `dgelsd`? When the arguments are real, yes. What changed is that the dispatching now happens in C, which was done as a step towards the incomplete

Re: [Numpy-discussion] timedelta64 remainder behavior with div by 0

If we consider it a bug, we could patch it in 1.16.1 (or are we still waiting on 1.16.0?), which would minimize the backwards compatibility cost. Eric On Tue, 8 Jan 2019 at 10:05 Stefan van der Walt wrote: > On Tue, 08 Jan 2019 09:57:03 -0800, Tyler Reddy wrote: > > np.timedelta64(5) %

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

could go for the more heavy-handed np.CopyMode.NEVER, which still has a unique enough case for name clashes with functions never to be an issue. Eric ​ On Wed, 9 Jan 2019 at 22:25 Ralf Gommers wrote: > On Mon, Jan 7, 2019 at 11:30 AM Eric Wieser > wrote: > >> >> @

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

@Matthias: Most of the time I would not assign to arr.shape, but in some rare occasions I find it very useful. And one of those rare occasions is when you want guaranteed no-copy behavior. Can you come up with any other example? The only real argument you seem to have here is “my code uses

[Numpy-discussion] Adding more detailed exception types to numpy

PR #12593 adds a handful of new exception types for . Some consequences of this change are that: 1. The string formatting is moved to python, allowing us to give better error messages without a lot of work 2. The formatting is dispatched

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

I don’t think a NEVERCOPY entry in arr.flags would make much sense. Is this really a sensible limitation to put on how data gets used? Isn’t it up to the algorithm to decide whether to copy its data, not the original owner of the data? It also leads to some tricky questions of precedence - would

Re: [Numpy-discussion] Porting code for Numpy 1.13+ to get rid of "boolean index did not match indexed array along dimension 1" error

It looks like your code is wrong, and numpy 1.12 happened to let you get away with it This line: evals = evals[evals > tolerance] Reduces the eigenvalues to only those which are greater than the tolerance When you do U[:, evals > tolerance], evals > tolerance is just going to be [True, True,

Re: [Numpy-discussion] defining a NumPy API standard?

Some of your categories here sound like they might be suitable for ABCs that provide mixin methods, which is something I think Hameer suggested in the past. Perhaps it's worth re-exploring that avenue. Eric On Sat, Jun 1, 2019, 18:18 Marten van Kerkwijk wrote: > > Our API is huge. A simple

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

One other approach here that perhaps treads a little too close to np.matrix: class MatrixOpWrapper: def __init__(self, arr): # todo: accept axis arguments here? self._array = arr # todo: assert that arr.ndim >= 2 / call atleast1d @property def T(self): return

Re: [Numpy-discussion] New release note strategy after branching 1.17.

It's worth linking to the issue where this discussion started, so we avoid repeating ourselves - https://github.com/numpy/numpy/issues/13707. Eric On Wed, Jun 12, 2019, 11:51 Nathaniel Smith wrote: > It might be worth considering a tool like 'towncrier'. It's automation to > support the

Re: [Numpy-discussion] new MaskedArray class

I think we’d need to consider separately the operation on the mask and on the data. In my proposal, the data would always do np.sum(array, where=~mask), while how the mask would propagate might depend on the mask itself, I quite like this idea, and I think Stephan’s strawman design is actually

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

need some way to filter for intent, as the > > > people > > > > who write this code are the ones who didn’t read docs on it at > > > the > > > > time, and so there might be a fair amount of noise even if it > > > fixes > > > > their code.

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

This might be contentious, but I wonder if, with a long enough deprecation cycle, we can change the meaning of .T. That would look like: * Emit a future warning on `more_than_2d.T` with a message like "in future .T will transpose just the last two dimensions, not all dimensions. Use

Re: [Numpy-discussion] Style guide for numpy code?

Joe, While most of your style suggestions are reasonable, I would actually recommend the opposite of the first point you make in (a)., especially if you're trying to write generic reusable code. > For example, an item count is always an integer, but a distance is always a > float. This is

Re: [Numpy-discussion] Boolean arrays with nulls?

One option here would be to use masked arrays: arr = np.ma.zeros(3, dtype=bool) arr[0] = True arr[1] = False arr[2] = np.ma.masked giving masked_array(data=[True, False, --], mask=[False, False, True], fill_value=True) On Thu, 18 Apr 2019 at 10:51, Stuart Reynolds wrote:

Re: [Numpy-discussion] NEP 31 — Context-local and global overrides of the NumPy API

> In other words `np.arange(100)` (but with a completely different syntax, probably hidden away only for libraries to use). It sounds an bit like you're describing factory classmethods there. Is the solution to this problem to move (leaving behind aliases) `np.arange` to `ndarray.arange`,

Re: [Numpy-discussion] Forcing gufunc to error with size zero input

Can you just raise an exception in the gufuncs inner loop? Or is there no mechanism to do that today? I don't think you were proposing that core dimensions should _never_ be allowed to be 0, but if you were I disagree. I spent a fair amount of work enabling that for linalg because it provided

Re: [Numpy-discussion] argmax() indexes to value

> On my system plain fancy indexing is fastest Hardly surprising, since take_along_axis is doing that under the hood, after constructing the index for you :) https://github.com/numpy/numpy/blob/v1.17.0/numpy/lib/shape_base.py#L58-L172 I deliberately didn't expose the internal function that

Re: [Numpy-discussion] Problem with np.savetxt

You're trying to read a file with a name of literally `${d}.log`, which is unlikely to be the name of your file. `${}` is bash syntax, not python syntax. This has drifted out of numpy territory and into "how to coordinate between bash and python" territory - I'd perhaps recommend you ask this to

Re: [Numpy-discussion] NEP 37: A dispatch protocol for NumPy-like modules

> scipy.linalg is a superset of numpy.linalg This isn't completely accurate - numpy.linalg supports almost all operations* over stacks of matrices via gufuncs, but scipy.linalg does not appear to. Eric *: not lstsq due to an ungeneralizable public API On Wed, 5 Feb 2020 at 17:38, Ralf Gommers

[Numpy-discussion] Adding an nd generalization of np.ma.mask_rowscols

Today, numpy has a np.ma.mask_rowcols function, which stretches masks along the full length of an axis. For example, given the matrix:: >>> a2d = np.zeros((3, 3), dtype=int) >>> a2d[1, 1] = 1 >>> a2d = np.ma.masked_equal(a2d, 1) >>> print(a2d) [[0 0 0] [0 -- 0] [0 0 0]] The API allows:: >>>

Re: [Numpy-discussion] Adding an nd generalization of np.ma.mask_rowscols

refer a more functional approach: Where we take in an input 1-D or N-D > boolean array in addition to a masked array with multiple axes over which > to extend the mask. > > > > *From: *NumPy-Discussion gmail@python.org> on behalf of Eric Wieser < > wieser.eric+nu...@gmail.com

[Numpy-discussion] Deprecating ndarray.tostring()

Hi all, Just a heads up that in https://github.com/numpy/numpy/pull/15867 I plan to deprecate ndarray.tostring(), which is just a confusing way to spell ndarray.tobytes(). This function has been documented as a compatibility alias since NumPy 1.9, but never emitted a warning upon use. Given

Re: [Numpy-discussion] Is `numpy.lib.shape_base.normalize_axis_index` considered part of the public API?

in which the function was created is > > https://github.com/numpy/numpy/pull/8584. Whether or not the function > > was to be public is discussed starting here: > > https://github.com/numpy/numpy/pull/8584#issuecomment-281179399. A > > leading underscore was discuss

Re: [Numpy-discussion] Proposal: add `force=` or `copy=` kwarg to `__array__` interface

Perhaps worth mentioning that we've discussed this sort of API before, in https://github.com/numpy/numpy/pull/11897. Under that proposal, the api would be something like: * `copy=True` - always copy, like it is today * `copy=False` - copy if needed, like it is today * `copy=np.never_copy` -

Re: [Numpy-discussion] Deprecate Promotion of numbers to strings?

> Another larger visible change will be code such as: > > np.concatenate([np.array(["string"]), np.array([2])]) > > will result in an error instead of returning a string array. (Users > will have to cast manually here.) I wonder if we can lessen the blow by allowing

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

> Putting > aside ndarray, as more challenging, even annotations for numpy functions > and method parameters with built-in types would help, as a start. This is a good idea in principle, but one thing concerns me. If we add type annotations to numpy, does it become an error to have numpy-stubs

Re: [Numpy-discussion] Using nditer + external_loop to Always Iterate by Column

Hi Will, To force an iteration to run along certain axes, I believe you should be using `op_axes`. Your diagnosis is correct that `external_loop` is trying to help you be more optimal, since it's purpose is exactly that: optimization. Unfortunately, if you use `op_axes` you'll run into

Re: [Numpy-discussion] number datetime64 dtypes

It's interesting to confirm that people are aware of this syntax! This is intended but perhaps not useful behavior. `datetime64[15D]` is a type that stores dates by the nearest date that is a multiple of 15 days from the unix epoch. Arguably there isn't a situation where using `15D` makes a

Re: [Numpy-discussion] Request for comments on PEP 637 - Support for indexing with keyword arguments

I agree with Stephan's suggestion of having no default value for positional indices, and letting the user supply it. It seems I replied badly to the mail on the python-ideas list, and my response ended up as a separate thread, at

Re: [Numpy-discussion] log of negative real numbers -> RuntimeWarning: invalid value encountered in log

One explanation for this behavior is that doing otherwise would be slow. Consider an array like arr = np.array([1]*10**6 + [-1]) ret = np.log(arr) Today, what happens is: - The output array is allocated as np.double - The input array is iterated over, and log evaluated on each element in

  1   2   >