[Numpy-discussion] Plans for new sparse compilation backend for PyData/Sparse

Hello everyone, The stated goal for sparse is to provide a NumPy-like API with a sparse representation of arrays. To this end, Quansight and I have been collaborating with researchers at MIT CSAIL - in particular Prof. Amarasinge's group

[Numpy-discussion] [ANN] sparse 0.15.1 released

Hi all, On behalf of the sparse developers, I’m pleased to announce the release of sparse 0.15.1. This is a significant release with Array API support, pyproject.toml packaging, einsum support and other miscellaneous improvements. Source Code: https://github.com/pydata/sparse Documentation: http

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

Not that I’m against different “levels” of ndarray granularity, but I just don’t want it to introduce complexity for the end-user. For example, it would be unreasonable to expect the end-user to check for all parts of the interface that they need support for separately. Keeping this in view; diffe

Re: [Numpy-discussion] ENH: softmax

I possible, write it as a `gufunc`, so duck arrays can override with `__array_ufunc__` if necessary. -- Marten Softmax is a very simple combination of elementary `ufunc`s with two inputs, the weight vector `w` and the data `x`. Writing it as a `gufunc` would be going overboard, IMO. Writing it as

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

Hello, everyone. I’ve submitted a PR to add a initializer kwarg to ufunc.reduce. This is useful in a few cases, e.g., it allows one to supply a “default” value for identity-less ufunc reductions, and specify an initial value for reductions such as sum (other than zero.) Please feel free to review

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

It would be nice if there was an IntEnum [1] that was taken is an input to `np.asarrayish` and `np.isarrayish` to require a combination of the groups of attributes/methods/semantics. Don’t you mean IntFlag ? I like Marten’s idea of “grouping to

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

I think that with your comments in mind, it may just be best to embrace duck typing, like Matthew suggested. I propose the following workflow: - __array_concatenate__ and similar "protocol" functions return NotImplemented if they won't work. - "Base functions" that can be called directly

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

sistent with `functools.reduce`. >> too. >> >> The only argument I can see against merging this would be `kwarg`-creep >> of `reduce`, and I think this has enough use cases to justify that. >> >> I'd like to merge in a few days, if no one else has any opin

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

ot the case), in which case it might be nice. However, "start" seems a bit like solving a different issue in any case. Anyway, mostly noise. I really like adding this, the only thing worth discussing a bit is the name :). - Sebastian On Mon, 2018-03-26 at 05:57 -0400, Hameer Abbasi wro

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

-0400, Hameer Abbasi wrote: > Actually, the behavior right now isn’t that of `default` but that of > `initializer` or `start`. > > This was discussed further down in the PR but to reiterate: > `np.sum([10], initializer=5)` becomes `15`. > > Also, `np.min([5], initializer=0)` becom

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

It'll need to be thought out for object arrays and subclasses. But for Regular numeric stuff, Numpy uses fmin and this would have the desired effect. On 26/03/2018 at 17:45, Sebastian wrote: On Mon, 2018-03-26 at 11:39 -0400, Hameer Abbasi wrote: That is the idea, but NaN functions are

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

lizer was passed in to change that behaviour. If this is agreed upon and someone is kind enough to point me to the code, I'd be willing to make this change. On 26/03/2018 at 18:54, Sebastian wrote: On Mon, 2018-03-26 at 18:48 +0200, Sebastian Berg wrote: On Mon, 2018-03-26 at 11:53 -0400, Ham

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

ven more useful to simplify special casing the empty case. > > Anyway, still just pointing out that I it gives me some headaches to > see such a special case for objects :(. > > - Sebastian > > > > > > On Mon, 26 Mar 2018 at 10:10 Sebastian Berg > et> wro

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

> > The reason would be the case of NaN which is not a possible initial > value for the reduction. > Ah, I didn't think of that. However, at least for `min` and `max` this can be accomplished with `fmin` and `fmax`. ___ NumPy-Discussion mailing list NumP

Re: [Numpy-discussion] Short-circuiting equivalent of np.any or np.all?

ble to override in duck arrays, etc) Best regards, Hameer Abbasi Sent from Astro <https://www.helloastro.com> for Mac On Apr 26, 2018 at 18:45, Nathan Goldbaum wrote: Hi all, I was surprised recently to discover that both np.any and np.all() do not have a way to exit early: In [1]: imp

Re: [Numpy-discussion] Short-circuiting equivalent of np.any or np.all?

Ah, in that case, if exotic platforms aren’t important for you, Numba can do the trick quite well. Best regards, Hameer Abbasi Sent from Astro <https://www.helloastro.com> for Mac On Apr 26, 2018 at 18:58, Nathan Goldbaum wrote: On Thu, Apr 26, 2018 at 11:52 AM Hameer Abbasi wrote:

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

I agree with Eric here. As one of the users of __array_ufunc__, I'd much rather have three separate gufuncs or a single one with axis insertion and removal. On 30/04/2018 at 23:38, Eric wrote: I think I’m -1 on this - this just makes things harder on the implementers of _array_ufunc__ who now might

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

There is always the option of any downstream object overriding matmul, and I fail to see which objects won't have a shape. - Hameer On 01/05/2018 at 21:08, Marten wrote: Just for completeness: there are *four* gufuncs (matmat, matvec, vecmat, and vecvec). I remain torn about the best way forwar

[Numpy-discussion] Casting scalars

Hello, everyone! I might be missing something and this might be a very stupid and redundant question, but is there a way to cast a scalar to a given dtype? Hameer ___ NumPy-Discussion mailing list NumPy-Discussion@python.org https://mail.python.org/mail

Re: [Numpy-discussion] Casting scalars

Yes, that I know. I meant given a dtype string such as 'uint8' or a dtype object. I know I can possibly do np.array(scalar, dtype=dtype)[()] but I was looking for a less hacky method. On 11/05/2018 at 07:50, Stuart wrote: np.float(scalar) On Thu, May 10, 2018 at 7:49 PM Hameer Abbasi wr

Re: [Numpy-discussion] Casting scalars

This is exactly what I needed! Thanks! On 11/05/2018 at 08:20, Warren wrote: On Thu, May 10, 2018 at 10:53 PM, Hameer Abbasi wrote: Yes, that I know. I meant given a dtype string such as 'uint8' or a dtype object. I know I can possibly do np.array(scalar, dtype=dtype)[()] but I was loo

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

You can preserve this with (for example) __array_ufunc__. On 18/05/2018 at 18:57, Nathan wrote: I don't particularly need this, although it would be nice to make this behavior explicit, instead of happening more or less by accident: In [1]: from yt.units import km In [2]: import numpy as np In [3]:

Re: [Numpy-discussion] Splitting MaskedArray into a separate package

I also somewhat like the idea of taking it out (once we have a first replacement) in the case that we have a plan to do a better/lower level replacement at a later point within numpy. Removal generally has its merits, but if a (mid term) replacement will come in any case, it would be nice to get th

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

he __array_ufunc__ api changing, but I’d like it if there was a way to still access the information that was previously available. [1] https://github.com/scipy-conference/scipy_proceedings/pull/388 Regards, Hameer Abbasi Sent from Astro <https://www.helloastro.com> for Mac __

Re: [Numpy-discussion] NEP: Dispatch Mechanism for NumPy’s high level API

Perhaps I missed this but I didn’t see: what happens when both __array_ufunc__ and __array_function__ are defined? I might want to do this to for example add support for functions like concatenate or stack to a class that already has an __array_ufunc__ defines. This is mentioned in the section “N

Re: [Numpy-discussion] NEP: Dispatch Mechanism for NumPy’s high level API

The rules for dispatch with ``__array_function__`` match those for ``__array_ufunc__`` (see `NEP-13 `_). In particular: - NumPy will gather implementations of ``__array_function__`` from all specified inputs and call them in order: subcl

Re: [Numpy-discussion] NEP: Dispatch Mechanism for NumPy’s high level API

I also am not sure there is an actual problem: In the scheme as proposed, implementations could just coerce themselves to array and call the routine again. (Or, in the scheme I proposed, call the routine again but with `coerce=True`.) Ah, I didn’t think of the first solution. `coerce=True` may no

Re: [Numpy-discussion] NEP: Dispatch Mechanism for NumPy’s high level API

Mixed return values of NotImplementedButCoercible and NotImplemented would still result in TypeError, and there would be no second chances for overloads. I would like to differ with you here: It can be quite useful to have second chances for overloads. Think ``np.func(list, custom_array))``: If s

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

How about this: "There will be no concept of a separate RNG version. In order to get consistent or reproducible results from the RNG, it will be necessary to specify the NumPy version that was used to generate those results. Results from the RNG may change across different releases of Num Py." S

Re: [Numpy-discussion] NEP: Dispatch Mechanism for NumPy’s high level API

On 6. Jun 2018 at 05:41, Nathan Goldbaum wrote: Oh wait, since the decorated version of the ufunc will be the one in the public numpy API it won't break. It would only break if the callable that was passed in *wasn't* the decorated version, so it kinda *has* to pass in the decorated function to

Re: [Numpy-discussion] Circle CI moving from 1.0 to 2.0

issue, not one with our configuration. It can be safely ignored. Regards, Hameer Abbasi On 14/06/2018 at 23:13, Matti wrote: I stumbled across this notice (only seems to appear in a failed build) "This project is currently running on CircleCI 1.0 which will no longer be supported after

Re: [Numpy-discussion] Dropping Python 3.4 support for NumPy 1.16

It was a small task. I created a PR for it here <https://github.com/numpy/numpy/pull/11337>. Feel free to merge after CI passes or close. Hameer Abbasi Sent from Astro <https://www.helloastro.com> for Mac On 14. Jun 2018 at 22:50, Marten van Kerkwijk wrote: It seems everyone

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

internals for pydata/sparse, fearing that I’d have to rewrite/modify them when behaviour changes or I find other corner cases. Best Regards, Hameer Abbasi Sent from Astro <https://www.helloastro.com> for Mac On 26. Jun 2018 at 09:46, Robert Kern wrote: On Tue, Jun 26, 2018 at 12:13 AM Eric

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

for someone not super into NumPy indexing, this is kind of opaque to read, so I propose this less verbose but hopefully equally clear version, for my (and others’) brains. Best Regards, Hameer Abbasi Sent from Astro <https://www.helloastro.com> for Mac

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

might disagree. :-) Best Regards, Hameer Abbasi Sent from Astro <https://www.helloastro.com> for Mac On 26. Jun 2018 at 10:28, Eric Wieser wrote: 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 n

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

, and warnings followed by errors for cases where the transposing behaviour occurs. Best Regards, Hameer Abbasi Sent from Astro <https://www.helloastro.com> for Mac On 26. Jun 2018 at 10:33, Robert Kern wrote: On Tue, Jun 26, 2018 at 1:26 AM Travis Oliphant wrote: > I like the

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

r :Author: Matthew Rocklin :Author: Marten van Kerkwijk :Author: Hameer Abbasi :Author: Eric Wieser :Status: Draft :Type: Standards Track :Created: 2018-05-29 Abstact --- We propose the ``__array_function__`` protocol, to allow arguments of NumPy functions to define how that function operat

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

RandomState objects with a seed sequential in the job numbers. Looping in Matt Rocklin for this — He might have some input about the design. Best Regards, Hameer Abbasi Sent from Astro <https://www.helloastro.com> for Mac On 28. Jun 2018 at 14:37, Marten van Kerkwijk wrote: On Wed,

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

Hi Martin, It is. The point of the proposed feature was to handle array generation mechanisms, that don't take an array as input in the standard NumPy API. Giving them a reference handles both the dispatch and the decision about which implementation to call. I'm confused: Isn't your reference arr

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

, array_reference=np._NoValue): if array_reference is not np._NoValue: success, result = try_array_function_override(wrapped, [array_reference], args, kwargs) if success: return result return func(*args, **kwargs) return wrapped Hameer

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

f the reason I’m pushing so hard for it. See #11074 <https://github.com/numpy/numpy/issues/11074> for a context, and I think it was part of the reason that inspired Matt and Stephan to write this protocol in the first place. Best Regards, Hameer Abbasi __

Re: [Numpy-discussion] backwards compatibility and deprecation policy NEP

we could onboard a lot more active developers and existing developers can also get a lot more work done. I may be getting ahead of myself on this, but feel free to leave your thoughts and opinions. Best regards, Hameer Abbasi Sent from Astro <https://www.helloastro.com> for Mac On 22. Jul 2018

Re: [Numpy-discussion] backwards compatibility and deprecation policy NEP

possible to prohibit problematically in Python This isn’t really true. Metaprogramming to the rescue I guess. https://stackoverflow.com/questions/16564198/pythons-equivalent-of-nets-sealed-class#16564232 Best regards, Hameer Abbasi Sent from Astro <https://www.helloastro.com> for Mac ), then you can e

Re: [Numpy-discussion] Roadmap proposal, v3

Hey Stefan/Ralf/Stephan, This looks nice, generally what the community agrees on. Great work, and thanks for putting this together. Best regards, Hameer Abbasi Sent from Astro <https://www.helloastro.com> for Mac On 24. Jul 2018 at 21:04, Stefan van der Walt wrote: Hi everyone, Pleas

Re: [Numpy-discussion] Adoption of a Code of Conduct

> On 28. Jul 2018, at 00:02, Stefan van der Walt wrote: > > Hi everyone, > > A while ago, SciPy (the library) adopted its Code of Conduct: > https://docs.scipy.org/doc/scipy/reference/dev/conduct/code_of_conduct.html > > We worked hard to make that document friendly, while at the same time > st

Re: [Numpy-discussion] Adoption of a Code of Conduct

Hi! I feel we should make it clear that being in any specific category does not give you a free pass on any of the other rules. We should make that explicit, otherwise this looks fine to me. Best Regards, Hameer Abbasi > On 3. Aug 2018, at 10:57, Stefan van der Walt wrote: > >

Re: [Numpy-discussion] Adoption of a Code of Conduct

> On 3. Aug 2018, at 17:44, Ralf Gommers wrote: > > > > On Fri, Aug 3, 2018 at 2:04 AM, Matthew Brett > wrote: > Hi, > > On Fri, Aug 3, 2018 at 9:35 AM, Stefan van der Walt > mailto:stef...@berkeley.edu>> wrote: > > On August 3, 2018 09:50:38 Robert Kern >

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

ly we are to move away from Pytest. And I’m assuming not very likely. Anything likely to replace it (which won’t happen short-term in any case) will already have something similar, IMO. So my vote is we go ahead and use them. Hameer Abbasi ___ N

Re: [Numpy-discussion] Proposal to accept NEP-18, __array_function__ protocol

>> array functions": >> http://www.numpy.org/neps/nep-0018-array-function-protocol.html >> >> Since the last round of discussion, we added a new section on "Callable >> objects generated at runtime" clarifying that to handle such objects is out >> of s

Re: [Numpy-discussion] Proposal to accept NEP-18, __array_function__ protocol

y-Discussion mailing list > NumPy-Discussion@python.org > https://mail.python.org/mailman/listinfo/numpy-discussion > <https://mail.python.org/mailman/listinfo/numpy-discussion> Best Regards, Hameer Abbasi ___ NumPy-Discussion mailing list NumPy-Discussion@python.org https://mail.python.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Proposal to accept NEP-18, __array_function__ protocol

” for machine learning. Regards, Hameer Abbasi > On 22. Aug 2018, at 03:46, Nathaniel Smith wrote: > > On Tue, Aug 21, 2018 at 9:39 AM, Stephan Hoyer <mailto:sho...@gmail.com>> wrote: >> On Tue, Aug 21, 2018 at 12:21 AM Nathaniel Smith wrote: >>> >>>

Re: [Numpy-discussion] Proposal to accept NEP-18, __array_function__ protocol

> On 23. Aug 2018, at 18:37, Stephan Hoyer wrote: > > RE: the types argument > > On Tue, Aug 21, 2018 at 12:21 AM Nathaniel Smith > wrote: > This is much more of a detail as compared to the rest of the > discussion, so I don't want to quibble too much about it. (Especia

Re: [Numpy-discussion] Proposal to accept NEP-18, __array_function__ protocol

t; ___________ > NumPy-Discussion mailing list > NumPy-Discussion@python.org > https://mail.python.org/mailman/listinfo/numpy-discussion Best Regards, Hameer Abbasi ___ NumPy-Discussion mailing list NumPy-Discussion@python.org https://mail.python.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Proposal to accept NEP-18, __array_function__ protocol

On Fri, Aug 24, 2018 at 5:55 PM Stephan Hoyer wrote: > On Thu, Aug 23, 2018 at 1:06 PM Hameer Abbasi > wrote: > >> I might add that if it’s a mandatory part of the protocol, then not all >> things will work. For example, if XArray and Dask want to support sparse >>

Re: [Numpy-discussion] Proposal to accept NEP-18, __array_function__ protocol

> On 29. Aug 2018, at 11:44, Matti Picus wrote: > > On 29/08/18 10:37, Nathaniel Smith wrote: >> it's easy to imagine scenarios where the >> people being broken aren't the ones who had a chance to read the docs >> – e.g. if a major package starts relying on __array_function__, then >> it's all*th

[Numpy-discussion] ANN: PyData/Sparse 0.4.1

. It depends on NumPy, SciPy and Numba. Where can I find PyData/Sparse? ——— The project is available on GitHub at https://github.com/pydata/sparse and is available on PyPI and conda-forge as “sparse”. Documentation is hosted as https://sparse.pydata.org. Best Regards, Hameer Abbasi

Re: [Numpy-discussion] Proposal to accept NEP-18, __array_function__ protocol

ill have major objections to this version of proposal, please > raise them unambiguously -- preferably with an formal veto [2]. > > Best, > Stephan > > > > > [1] https://mail.python.org/pipermail/numpy-discussion/2018-August/078669.html > [2] https://docs.scipy.org/d

[Numpy-discussion] Exact semantics of ufunc.reduce

/sparse/issues/191) when trying to match the two where the only thing differing is the number of zeros for sum, which shouldn’t change the result. Best Regards, Hameer Abbasi ___ NumPy-Discussion mailing list NumPy-Discussion@python.org https

Re: [Numpy-discussion] random.choice(replace=False) very slow

e a maximum of ``N // 2`` samples and then select the “unselected” samples instead. Although this has a faster expected run-time than the standard algorithm in all cases, it would break backwards-compatibility guarantees. Best Regards, Hameer Abbasi [1] https://en.wikipedia.org/wiki/Fisher%E2

Re: [Numpy-discussion] Approving NEP 27 - Historical discussion of 0-D arrays

equivalent of np.wherefor PyData/Sparse. Best Regards, Hameer Abbasi > On Wednesday, Oct 17, 2018 at 7:59 PM, Matti Picus (mailto:matti.pi...@gmail.com)> wrote: > In PR 12166 https://github.com/numpy/numpy/pull/12166 we revived an old > wiki document discussing the implementation of 0

Re: [Numpy-discussion] BIDS/NumPy dev meetings, Wednesdays 12pm Pacific

Dial in: https://berkeley.zoom.us/zoomconference?m=ta2dUMqcdK219Ov78Sj7CMIzzoX2CHGZ Join in via PC: https://berkeley.zoom.us/j/400054438 Best Regards, Hameer Abbasi > On Wednesday, Oct 17, 2018 at 8:59 PM, Mark Harfouche > mailto:mark.harfou...@gmail.com)> wrote: > Stefan. I w

Re: [Numpy-discussion] asanyarray vs. asarray

of hard to do. > > > > > > Matti > > > ___ > NumPy-Discussion mailing list > NumPy-Discussion@python.org > https://mail.python.org/mailman/listinfo/numpy-discussion Best Regards, Hameer Abbasi __

Re: [Numpy-discussion] asanyarray vs. asarray

listinfo/numpy-discussion > ___ > NumPy-Discussion mailing list > NumPy-Discussion@python.org > https://mail.python.org/mailman/listinfo/numpy-discussion Best Regards, Hameer Abbasi ___ NumPy-Discussion mailing list NumPy-Discussion@python.org https://mail.python.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Reminder: weekly status meeting

conversions to/from SciPy, if these could depend on Cython wrappers instead that’d be nice. I should probably update the docs on that. If anyone is willing to discuss pydata/sparse with me, I’ll be available for a meeting anytime. Best Regards, Hameer Abbasi > On Thursday, Oct 25, 2018 at 12

Re: [Numpy-discussion] Reminder: weekly status meeting

and the like. Everything else is for inter-operability. Best Regards, Hameer Abbasi > On Friday, Oct 26, 2018 at 1:19 AM, Tyler Reddy (mailto:tyler.je.re...@gmail.com)> wrote: > What exactly would you like Cython wrappers for? Some of the C++ code in > scipy/sparse/sparsetools? &

Re: [Numpy-discussion] Reminder: weekly status meeting

SciPy. Best Regards, Hameer Abbasi > On Friday, Oct 26, 2018 at 7:03 PM, Stefan van der Walt (mailto:stef...@berkeley.edu)> wrote: > Hi Hameer, > > On Fri, 26 Oct 2018 10:47:09 +0200, Hameer Abbasi wrote: > > The only core functionality dependent on scipy.sparse is matrix &

Re: [Numpy-discussion] Reminder: weekly status meeting

s the case, but even in the later days he shifted much of his code to pure NumPy. I followed that path further, not out of unwillingness to depend on it, but out of desire for generality. In its current state, the only things in PyData/Sparse that depend on scipy.sparse are: Conversion to/from s

Re: [Numpy-discussion] Reminder: weekly status meeting

;re right I think that that > will need some careful design work. Not sure anyone has thought about that in > a lot of detail yet. > They don’t yet. That is a planned feature, allowing an arbitrary permutation of input coordinates. > > There are interesting API questions probably, s

Re: [Numpy-discussion] Reminder: weekly status meeting 31.10 at 12:00 pacific time

Hello! If I may make a suggestion, it might be nice to create a separate calendar and add people to it as needed for better management. Best Regards, Hameer Abbasi > On Tuesday, Oct 30, 2018 at 8:16 PM, Matti Picus (mailto:matti.pi...@gmail.com)> wrote: > > The draft agenda

Re: [Numpy-discussion] Reminder: weekly status meeting 31.10 at 12:00 pacific time

Hi, I meant we should have a calendar that’s possible to subscribe to, and in addition announce the agenda here, and that the calendar could contain a link to the meeting agenda. Best Regards, Hameer Abbasi > On Tuesday, Oct 30, 2018 at 11:52 PM, Stefan van der Walt > mailt

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

> Begin forwarded message: > > From: Stephan Hoyer > Date: Friday, Nov 09, 2018 at 3:19 PM > To: Hameer Abbasi > Cc: Stefan van der Walt , Marten van Kerkwijk > Subject: asarray/anyarray; matrix/subclass > > This is a great discussion, but let's try to have it

Re: [Numpy-discussion] Should unique types of all arguments be passed on in __array_function__?

vincing to you too? If so, I'll close the PR. I agree with Stephan here, other than the fact that ndarray should be in the list of types. I can think of many cases in PyData/Sparse where I dont want to allow mixed inputs, but maybe that’s a tangential discussion. Best Regards, Hameer Abbasi >

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

> On Saturday, Nov 10, 2018 at 9:16 PM, Stephan Hoyer (mailto:sho...@gmail.com)> wrote: > On Sat, Nov 10, 2018 at 9:49 AM Marten van Kerkwijk > mailto:m.h.vankerkw...@gmail.com)> wrote: > > Hi Hameer, > > > > I do not think we should change `asanyarray` itself to special-case matrix; > > rather

Re: [Numpy-discussion] Should unique types of all arguments be passed on in __array_function__?

In that case, ignore my comment. :) Best Regards, Hameer Abbasi > On Saturday, Nov 10, 2018 at 11:52 PM, Stephan Hoyer (mailto:sho...@gmail.com)> wrote: > On Sat, Nov 10, 2018 at 2:08 PM Hameer Abbasi (mailto:einstein.edi...@gmail.com)> wrote: > > I agree with Stephan here, o

[Numpy-discussion] Vectorized version of numpy.linspace

se, we are “composing/combining” lots of 1D arrays over all the other dimensions, so to preserve C-contiguous-ness, it’s better to have axis=-1. > ___ > NumPy-Discussion mailing list > NumPy-Discussion@python.org > https://mail.python.org/mailman/listinfo/numpy-discussion Best Regards, Hameer Abbasi ___ NumPy-Discussion mailing list NumPy-Discussion@python.org https://mail.python.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Reminder: Numpy dev meeting Fri-Sat Nov 30-Dec 1

Hi everyone! Just want to add that I’ll be available remotely for some of the time. You can reach me via email and we can set up a call. Best Regards, Hameer Abbasi > On Wednesday, Nov 28, 2018 at 10:15 PM, Matti Picus (mailto:matti.pi...@gmail.com)> wrote: > We will be meeting at BI

Re: [Numpy-discussion] Warn or immidiately change readonly flag on broadcast_arrays return value?

kind of hairy problem with no clear solution. Best Regards, Hameer Abbasi > On Tuesday, Dec 25, 2018 at 12:13 PM, Matti Picus (mailto:matti.pi...@gmail.com)> wrote: > In PR 12609 https://github.com/numpy/numpy/pull/12609 I added code to > emit a DepricationWarning when broadcast_ar

[Numpy-discussion] Testing radix sort on big-endian architectures

if they could run the test suite on that PR. Best Regards, Hameer Abbasi ___ NumPy-Discussion mailing list NumPy-Discussion@python.org https://mail.python.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Debugging NumPy development build in conda environment

ext --inplace -j 4 > > > pip install -e . > > Often, when I run into issues with the build, I simply do this: > [backup site.cfg] > git clean -xfd > > > [restore site.cfg] > > python setup.py build_ext --inplace -j 4 > > pip install -e . > > In y

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

I would say this is desirable behaviour, but I’m still +0.8 on this for backward compatibility reasons. I doubt anyone would build code that relies on this though… They would almost certainly check for the zero in the denominator rather than the return value. Best Regards, Hameer Abbasi >

Re: [Numpy-discussion] Removing undocumented __buffer__ attribute lookup

Cc-ing in Travis, because he was the original author of the buffer protocol, and this is most definitely related. Best Regards, Hameer Abbasi > On Wednesday, Feb 27, 2019 at 9:20 AM, Matti Picus (mailto:matti.pi...@gmail.com)> wrote: > In digging around the code, I found

Re: [Numpy-discussion] Complex Normal Generator in NEP-19 extension

ment. If not, then we can just delete it. > > Kevin > > ___ > NumPy-Discussion mailing list > NumPy-Discussion@python.org > https://mail.python.org/mailman/listinfo/numpy-discussion +1 Best Regards, Hameer Abbasi signature.asc Descript

Re: [Numpy-discussion] Complex Normal Generator in NEP-19 extension

> On Friday, Mar 29, 2019 at 6:03 PM, Hameer Abbasi (mailto:einstein.edi...@gmail.com)> wrote: > > On Friday, Mar 29, 2019 at 6:01 PM, Kevin Sheppard > > mailto:kevin.k.shepp...@gmail.com)> wrote: > > One part of moving randomgen closer to fulfilling NEP-19 is

Re: [Numpy-discussion] Beginner Help: Generating HTML using Sphinx

Hi Mbeng! What is the output of python --version and python3 --version? It seems to me that you’re still using Python 2.7. You may need to use the command python3 rather than python. Best Regards, Hameer Abbasi > On Tuesday, Apr 02, 2019 at 10:34 AM, Mbeng Tanyi (mailto:valentin

Re: [Numpy-discussion] Adding to the non-dispatched implementation of NumPy methods

b/master/uarray/tests/test_backend.py Backend infrastructure: https://github.com/Quansight-Labs/uarray/blob/master/unumpy/tests/test_numpy.py Examples of how to write NumPy MultiMethods are here: https://github.com/Quansight-Labs/uarray/blob/master/unumpy/multimethods.py, along with the acco

Re: [Numpy-discussion] Adding to the non-dispatched implementation of NumPy methods

> What's __array_dtype__? That string doesn't seem to appear in the > numpy source, and google has no hits… This was a proposed protocol for dispatching over user-defined dtype objects, I think Stephan and a few others wrote up a mock at SciPy 2018. Best Regards, Hameer Abbasi

Re: [Numpy-discussion] Adding to the non-dispatched implementation of NumPy methods

can dispatch over, so there’s no repition by definition. Best Regards, Hameer Abbasi > On Friday, Apr 26, 2019 at 10:31 AM, Ralf Gommers (mailto:ralf.gomm...@gmail.com)> wrote: > > > On Fri, Apr 26, 2019 at 1:02 AM Stephan Hoyer (mailto:sho...@gmail.com)> wrote: > > O

Re: [Numpy-discussion] Adding to the non-dispatched implementation of NumPy methods

> guarantees are not accepted to you, do not rely upon overrides of NumPy > functions for non-NumPy arrays. See “Non-goals” below for more details. What I’m presenting is within scope, as it’s an alternative method. Best Regards, Hameer Abbasi signature.asc Description: PGP signature

Re: [Numpy-discussion] Adding to the non-dispatched implementation of NumPy methods

s compatibility > guarantees are not accepted to you, do not rely upon overrides of NumPy > functions for non-NumPy arrays. See “Non-goals” below for more details. [snip] Best Regards, Hameer Abbasi signature.asc Description: PGP signature

Re: [Numpy-discussion] Adding to the non-dispatched implementation of NumPy methods

Hi Stephan, > On Saturday, Apr 27, 2019 at 6:21 PM, Stephan Hoyer (mailto:sho...@gmail.com)> wrote: > On Fri, Apr 26, 2019 at 9:16 AM Hameer Abbasi (mailto:einstein.edi...@gmail.com)> wrote: > > > That said, please save it a separate discussion thread, given that the >

Re: [Numpy-discussion] Adding to the non-dispatched implementation of NumPy methods

prefer to keep the experimental tag, for this very reason: Avoiding having to write a new NEP for adding functionality. However, I’m open to declaring it non-experimental it as well. Best Regards, Hameer Abbasi > On Sunday, Apr 28, 2019 at 5:50 AM, Stephan Hoyer (mailto:sho...@gmail.com)>

[Numpy-discussion] New Proposed Time for the NumPy Community Meeting

, my fast for the month of Ramadan breaks at 9:07 PM, and will only get later. I’d hate to eat during the meeting. Best Regards, Hameer Abbasi ___ NumPy-Discussion mailing list NumPy-Discussion@python.org https://mail.python.org/mailman/listinfo/numpy

Re: [Numpy-discussion] Keep __array_function__ unexposed by default for 1.17?

On Thu, 2019-05-23 at 10:19 -0700, Stephan Hoyer wrote: > On Thu, May 23, 2019 at 2:43 AM Ralf Gommers > wrote: > > On Thu, May 23, 2019 at 3:02 AM Marten van Kerkwijk < > > m.h.vankerkw...@gmail.com> wrote: > > > > If we want to keep an "off" switch we might want to add some > > > > sort of API f

Re: [Numpy-discussion] Keep __array_function__ unexposed by default for 1.17?

On Wed, 2019-05-22 at 08:52 -0700, Stephan Hoyer wrote: > Thanks for raising these concerns. > The full implications of my recent __skip_array_function__ proposal > are only now becoming evident to me now, looking at it's use in GH- > 13585. Guaranteeing that it does not expand NumPy's API surface

[Numpy-discussion] defining a NumPy API standard?

existed. Maybe I think the issue is bigger than it really is, but there’s definitely a coordination problem. See the section in the original email on “who cares and why”... Best Regards, Hameer Abbasi > On Saturday, Jun 01, 2019 at 11:32 AM, Nathaniel Smith (mailto:n...@pobox.com)> wrote: &

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

Re: Successful specifications (I’ll avoid using the word standard): Moving: HTML5/CSS3, C++, Rust, Python, Java. Static: C I’d really like this to be a moving spec... A static one is never much use, and is doomed to miss use cases, either today or some from the future. Best Regards, Hameer

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

Regards, Hameer Abbasi > On Sunday, Jun 02, 2019 at 10:16 PM, Stephan Hoyer (mailto:sho...@gmail.com)> wrote: > On Sun, Jun 2, 2019 at 1:08 PM Marten van Kerkwijk (mailto:m.h.vankerkw...@gmail.com)> wrote: > > > > > > On Sun, Jun 2, 2019 at 2:21 PM Eric Wies

Re: [Numpy-discussion] Extent to which to work around matrix and other duck/subclass limitations

On Mon, 2019-06-10 at 13:47 -0400, Marten van Kerkwijk wrote: > Hi All, > > In https://github.com/numpy/numpy/pull/12801, Tyler has been trying > to use the new `where` argument for reductions to implement `nansum`, > etc., using simplifications that boil down to `np.sum(..., > where=~isnan(...))`

Re: [Numpy-discussion] (Value Based Promotion) Current Behaviour

, Hameer Abbasi > On Wednesday, Jun 12, 2019 at 9:50 PM, Sebastian Berg > mailto:sebast...@sipsolutions.net)> wrote: > On Wed, 2019-06-12 at 12:03 -0500, Sebastian Berg wrote: > > On Tue, 2019-06-11 at 22:08 -0400, Marten van Kerkwijk wrote: > > > HI Sebastian, > >

Re: [Numpy-discussion] Moving forward with value based casting

-accuracy question, and I would argue that people using integers expect exactness. Of course, I doubt anyone is actually relying on the fact that adding two integers produces floating-point results, and it has been the cause of at least one bug, which highlights that integers can be used in places w

  1   2   >