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 to

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 careless

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 = array

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 data-typ

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

I don’t think that np.search is really solving the same problem as find_first would. IMO, we should solve that problem with an argfirst(bool_array, axis=0, keepdims=False) -> intp function, with almost the same semantics as argmax, but special-casing an array of Falses, to return bool_array.shape[

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

>- Andres Guzman-Ballen + >- Antoine Pitrou >- Antony Lee >- B R S Recht + >- Baurzhan Muftakhidinov + >- Ben Rowland >- Benda Xu + > - Blake Griffith >- Bradley Wogsland + >- Brandon Carter + >- CJ Carey >- Charle

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: > > builtins.SystemError: ..\Objec

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

Even if you solve your own problem, please do - a SystemError is 100% a mistake in numpy, and should never be raised from python code, even if you call a numpy function with the wrong inputs. Eric On Thu, 11 May 2017 at 19:35 Isaac Gerg wrote: > Sure. > > On Thu, May 11, 2017 at 2:31

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 numpy.put to > additive

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

It seems to me that after a healthy post-deprecation cycle, and if we choose to keep the Z/2 meaning of __sub__, it might be worth reintroducing __neg__ as a no-op? AFAICT, this is consistent with the Z/2 interpretation? Eric On Wed, 28 Jun 2017 at 00:08 Nathaniel Smith wrote: > On Tue, Jun 27,

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 wrote: > Hi

Re: [Numpy-discussion] Polynomial silent breakage with 1.13

That’s a regression, and it’s on me, in 8762. That was a side effect of a fix for the weird behaviour here . I think we need to fix this in 1.13.2, so we should file an issue about it. Eric ​ On Fri, 7 Jul 2017 at 18:31 Matthew Br

Re: [Numpy-discussion] Polynomial silent breakage with 1.13

I've gone ahead and filed one at https://github.com/numpy/numpy/issues/9385, along with links to relevant PRs. On Fri, 7 Jul 2017 at 22:28 Matthew Brett wrote: > Hi, > > On Fri, Jul 7, 2017 at 6:14 PM, Eric Wieser > wrote: > > That’s a regression, and it’s on me, in 8

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 self._v

[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 li

Re: [Numpy-discussion] quantile() or percentile()

Let’s try and keep this on topic - most replies to this message has been about #9211, which is an orthogonal issue. There are two main questions here: 1. Would the community prefer to use np.quantile(x, 0.25) instead of np.percentile(x, 25), if they had the choice 2. Is this desirable en

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

I'm also in favor of fixing this, although we might need a deprecation cycle with a warning advising to use arr.size in future to detect emptiness - just in case anyone is using it. On Sat, Aug 19, 2017, 06:01 Stephan Hoyer wrote: > I agree, this behavior seems actively harmful. Let's fix it. >

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

Defining falseness​ as emptiness in numpy is problematic, as then bool(array(0)) and bool(0) would have different results. 0d arrays are supposed to behave as much like their scalar values as possible, so this is not acceptable. More importantly though, allowing your proposed semantics would cause

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

Andrew, that can only be useful if you also require that all non-empty arrays are True - else code looking for empty arrays gets false positives on arrays of zeros. But as I mention above, that is not acceptable, as it produces silent traps for new users, or functions not written with numpy in min

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 boolean mask. >> >> mask = (tmp_px > 2) >> px = tmp

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. Nu

Re: [Numpy-discussion] PyArray_GETITEM and PyArray_SETITEM

It’s worth noting that PyArray_GETITEM is the equivalent of arr[].item(), not arr[...]. If you want the behavior of the latter, use PyArray_Scalar instead. Similarly, PyArray_SETITEM is only guaranteed to be equivalent to arr[...] = x when isinstance(x, np.generic) is false. I don’t think the

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 the

Re: [Numpy-discussion] What is the pythonic way to write a function that handles arrays and scalars?

Using np.iscalar is a bad idea, as it fails for 0d arrays. x.ndim is the better option there. I’d maybe suggest not special-casing 0d arrays though, and using: def func_for_scalars_or_vectors(x): x = np.asanyarray(x) # convert scalars to 0d arrays # The magic happens here return ret

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 through the indexing rules i

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

is basic indexing then with one the rules > - obj is an integer > - obj is a tuple of slice objects and integers. > ? > > > Am 13.12.2017 21:49 schrieb Eric Wieser: > > Increasingly, NumPy does not considers booleans to be integer types, > > and indexing is one of the

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] 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 non-co

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 wrote: > 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,

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 — even before this I’ve >> > wanted that. But in t

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 `ar

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

Because dtypes were low level with clear memory layout and stayed that way Dtypes have supported padded and out-of-order-fields since at least 2005 (v0.8.4) , and I would gue

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] improving arange()? introducing fma()?

Can’t arange and linspace operations with floats be done internally Yes, and they probably should be - they’re done this way as a hack because the api exposed for custom dtypes is here

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 e

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

As likely one of the primary users, Tom - does the function name seem reasonable? Eric On Mon, Mar 12, 2018, 21:45 Thomas Caswell wrote: > As commented in the OP, this would be very useful for Matplotlib. > > Tom > > On Fri, Mar 9, 2018 at 1:42 PM Kirit Thadaka > wrote: > >> Hi! >> >> I've cre

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

> Given that the bin selection are data driven, transferring them across > datasets might not be so useful. The main application would be to compute bins across the union of all datasets. This is already possibly by using `np.histogram` and discarding the first result, but that's super wasteful.

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

what we want >> >> Tom >> >> On Mon, Mar 12, 2018 at 11:35 PM wrote: >> >>> On Mon, Mar 12, 2018 at 11:20 PM, Eric Wieser >>> wrote: >>> >> Given that the bin selection are data driven, transferring them >>> acr

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 Casw

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

To reiterate my comments in the issue - I'm in favor of this. It seems seem especially valuable for identity-less functions (`min`, `max`, `lcm`), and the argument name is consistent with `functools.reduce`. too. The only argument I can see against merging this would be `kwarg`-creep of `reduce`,

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

itial_value", but > consistency with functools.reduce makes a compelling case for "initializer". > > On Sun, Mar 25, 2018 at 1:15 PM Eric Wieser > wrote: > >> To reiterate my comments in the issue - I'm in favor of this. >> >> It seems seem especially

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

t; Sent from Astro <https://www.helloastro.com> for Mac > > On Mar 26, 2018 at 09:54, Eric Wieser wrote: > > > It turns out I mispoke - functools.reduce calls the argument `initial` > > On Mon, 26 Mar 2018 at 00:17 Stephan Hoyer wrote: > >> This looks like a very logical ad

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

Sebastian Berg > t> wrote: > > > > > > Initializer or this sounds fine to me. As an other data point which > > > > I > > think has been mentioned before, `sum` uses start and min/max > > > > use > > default. `start` does not work, unless we

Re: [Numpy-discussion] Right way to do fancy indexing from argsort() result?

https://github.com/numpy/numpy/issues/8708 is a proposal to add such a function, with an implementation in https://github.com/numpy/numpy/pull/8714 Eric On Mon, 26 Mar 2018 at 11:35 Benjamin Root wrote: > Ah, yes, I should have thought about that. Kind of seems like something > that we could m

Re: [Numpy-discussion] best way of speeding up a filtering-like algorithm

Well, one tip to start with: numpy.where(some_comparison, True, False) is the same as but slower than some_comparison Eric On Wed, 28 Mar 2018 at 18:36 Moroney, Catherine M (398E) < catherine.m.moro...@jpl.nasa.gov> wrote: > Hello, > > > > I have the following sample code (pretty simple algor

[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 circumstances

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: > Would it break backwards compat

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 wrote: > On Mon, Apr 9, 2018 at 10:24 PM, Eric Wieser > wrote: > >> Numpy has three histogram functions - histogram, histogram2d, and >> histogramdd. >> >> h

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 wrote: > On Wed, Apr 25, 2018 at 10:07 PM, Eric Wieser > wrote: > >> what does that gain over having the user do something like result.astype() >> >> It means that the user can use integ

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

Apr 2018 at 22:26 Ralf Gommers wrote: > On Wed, Apr 25, 2018 at 11:00 PM, Eric Wieser > wrote: > >> For precision loss of the order of float64 eps, I disagree. >> >> I was thinking more about precision loss on the order of 1, for large >> 64-bit i

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. 1.14.3 > #import mat

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 h

Re: [Numpy-discussion] Matrix opreation

I’d recommend asking this kind of question on stackoverflow in future, but you can do that with: b = (a .reshape((2, 2, 4, 4)) # split up the (4,) axis into (2, 2) .transpose((2, 0, 3, 1)) # reorder to (4, 2, 4, 2) .reshape((8, 8)) # collapse adjacent dimensions ) ​ On Tue,

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 = np.array([[

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

You make a bunch of good points refuting reproducible research as an argument for not changing the random number streams. However, there’s a second use-case you don’t address - unit tests. For better or worse, downstream, or even our own

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 http

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

g 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

Frozen dimensions: I started with just making every 3-vector and 3x3-matrix structured arrays with the relevant single sub-array entry I was actually suggesting omitting the structured dtype (ie, field names) altogether, and just using the subarray dtypes (which exist alone, but not in arrays).

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 s

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] 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 overrid

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 r

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 https://mail.python.org/mai

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 shoul

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 < > m.

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] 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] Polynomial evaluation inconsistencies

more sense for np.polyval() 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 c

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 ask

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 than

Re: [Numpy-discussion] Polynomial evaluation inconsistencies

t 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 t

Re: [Numpy-discussion] Polynomial evaluation inconsistencies

is sound like a good idea to anyone? > > Max > > > On Sat, Jun 30, 2018 at 6:47 PM, Charles R Harris < > charlesr.har...@gmail.com> wrote: > >> >> >> On Sat, Jun 30, 2018 at 4:42 PM, Charles R Harris < >> charlesr.har...@gmail.com> wrote: &

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): > > > I

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 suggeste

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 contributo

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 it

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 cle

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

valid indices >>> 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 >> gene

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

t; should they need 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: > &

Re: [Numpy-discussion] asanyarray vs. asarray

have or want such a concept 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

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 wou

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 o

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 t

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, > > Visualizin

Re: [Numpy-discussion] numpy pprint?

)) > 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 >&

Re: [Numpy-discussion] numpy pprint?

Mark to show 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

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 suppo

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] 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 https:/

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 l

Re: [Numpy-discussion] three-dim array

; to 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] Add guaranteed no-copy to array creation and reshape?

I think np.never_copy is really ugly. I’d much rather simply use ‘never’, I actually think np.never_copy is the better choice of the two. Arguments for it: - It’s consistent with np.newaxis in spelling (modulo the _) - If mistyped, it can be caught easily by IDEs. - It’s typeable with my

[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 lazily,

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 arr.s

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) % np.timed

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: > >> >> @Ralf &g

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 n

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 > wher

  1   2   >