[Numpy-discussion] Re: welcome Raghuveer, Chris, Mateusz and Matt to the NumPy maintainers team

Welcome, Raghuveer, Chris, Mateusz and Matt! > Am 26.01.2024 um 21:04 schrieb Ralf Gommers : > > Hi all, > > We've got four new NumPy maintainers! Welcome to the team, and > congratulations to: > > - Raghuveer Devulapalli (https://github.com/r-devulap) > - Chris Sidebottom

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

[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] Re: removing NUMPY_EXPERIMENTAL_ARRAY_FUNCTION env var

+1 from my side as well.Von meinem iPhone gesendetAm 10.03.2023 um 19:10 schrieb Stephan Hoyer :+1 for removing this environment variable. It was never intended to stick around this long.On Fri, Mar 10, 2023 at 6:48 AM Ralf Gommers wrote:Hi all,In

[Numpy-discussion] ANN: A new version (0.14.0) of sparse has been released.

I’d like to announce the release of PyData/Sparse 0.14.0. PyData/Sparse is available on conda-forge and PyPI. PyData/Sparse is a package that provides sparse arrays conforming to the NumPy API, along with a subset of NumPy operations on sparse arrays. The highlights of this release include

[Numpy-discussion] Re: Invalid value encoutered : how to prevent numpy.where to do this?

Hi! You can use a context manager: with np.errstate(all=”ignore”): … Best regards, Hameer Abbasi Von meinem iPhone gesendet > Am 18.02.2023 um 16:00 schrieb David Pine : > > I agree. The problem can be avoided in a very inelegant way by turning > warnings off before c

[Numpy-discussion] Re: Out paramter for argsort?

, Hameer Abbasi Von meinem iPhone gesendet > Am 22.10.2022 um 17:51 schrieb Paul Rudin : > > Argsort returns its result in a new array. It would be useful if allocation > of the new array could be avoided when a suitable array is already available. > > Is there a reason

[Numpy-discussion] Re: representation of valid float type range

points. I believe this would fix the issue here among many others. However, it was always rejected due to backward-incompatibility concerns. Perhaps it’s time to revisit this issue. Best regards, Hameer Abbasi > Am 10.01.2022 um 12:59 schrieb alejandro.giacome...@gmail.com: > > I se

[Numpy-discussion] Re: Make the pickle default protocol 4.

ng list -- numpy-discussion@python.org > To unsubscribe send an email to numpy-discussion-le...@python.org > https://mail.python.org/mailman3/lists/numpy-discussion.python.org/ > Member address: einstein.edi...@gmail.com Best regards, Hameer Abbasi ___ Num

[Numpy-discussion] Re: spam on the mailing lists

, hoping it’ll get better, but it hasn’t so far. I’d very much prefer Discourse or GitHub discussions, of the two I prefer Discussions, but Discourse isn’t too bad either. With best regards, Hameer Abbasi > Am 06.10.2021 um 22:57 schrieb Aaron Meurer : > > Coming back to earth on the

Re: [Numpy-discussion] deprecating float(x) for ndim > 0

Hello Nico, Any step in the direction of consistency and type safety is a good one to me. I’m +1 on this change. Best regards, Hameer Abbasi > Am 15.09.2021 um 14:18 schrieb Nico Schlömer : > > Hi everyone, > > This is seeking input on PR [1] which I've worked on wi

[Numpy-discussion] Announcing PyData/Sparse 0.13.0

ta.org/en/0.13.0/ <https://sparse.pydata.org/en/0.13.0/> Changelog: https://sparse.pydata.org/en/0.13.0/changelog.html <https://sparse.pydata.org/en/0.13.0/changelog.html> Best regards, Hameer Abbasi signature.asc Description: Message s

Re: [Numpy-discussion] Value based promotion and user DTypes

ng types. Which is nice. It eliminates whole classes of bugs. > > Or maybe better just limit it completely to always use the default for > user DTypes? > > > But I would be interested if the "limit to Python operators" is > something we should aim for here. This does m

Re: [Numpy-discussion] Comment published in Nature Astronomy about The ecological impact of computing with Python

that requirement. It can’t do arbitrary non-pointwise functions, e.g. SVD, inverse. This is a long way from being completely solved. As for why not Numba/llvmlite: Re-writing TACO is a large task that would be hard to do, wrapping/extending it is much easier. Best regards, Hameer Abbasi -- Sent

Re: [Numpy-discussion] Comment published in Nature Astronomy about The ecological impact of computing with Python

Hello, We’re trying to do a part of this in the TACO team, and with a Python wrapper in the form of PyData/Sparse. It will allow an abstract array/scheduling to take place, but there are a bunch of constraints, the most important one being that a C compiler cannot be required at runtime.

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

(a, kw) arr[*a] # arr.__setitem__(a) arr[**kw] # arr.__setitem__((), kw) This is driven by my love for generality and hatred of special cases. So I’m +1 for empty tuple or the third form. Best regards, Hameer Abbasi -- Sent from Canary (https://canarymail.io) > On Friday, Sep 25, 2020 at 4:22

[Numpy-discussion] [ANN] PyData/Sparse 0.11.1

. The official website and documentation is available at: https://sparse.pydata.org (https://sparse.pydata.org/) The sources and bug tracker: https://github.com/pydata/sparse The changelog for this release can be viewed at: https://sparse.pydata.org/en/0.11.1/changelog.html Best Regards, Hameer

[Numpy-discussion] [Release] PyData/Sparse 0.11.0

The sources and bug tracker: https://github.com/pydata/sparse The changelog for this release can be viewed at: https://sparse.pydata.org/en/0.11.0/changelog.html Best Regards, Hameer Abbasi -- Sent from Canary (https://canarymail.io) ___ NumPy-Discussion

Re: [Numpy-discussion] Experimental `like=` attribute for array creation functions

Hi, We should have a higher-bandwidth meeting/communication for all stakeholders, and particularly some library authors, to see what would be good for them. We should definitely have language in the NEP that says it won’t be in a release unless the NEP is accepted. Best regards, Hameer Abbasi

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

]: a = np.arange(3).reshape((1, 3)) In [3]: for x in a.T: ...: print(x) ...: [0] [1] [2] Best regards, Hameer Abbasi From: NumPy-Discussion on behalf of William Ayd Reply to: Discussion of Numerical Python Date: Tuesday, 19. May 2020 at 01:42 To: "numpy-discussion@pytho

[Numpy-discussion] Announcing PyData/Sparse 0.10.0

users who can upgrade to Numba 0.49 or later to upgrade to this release. For users who cannot update to this version, we recommend staying with 0.9.x until you can. Best regards, Hameer Abbasi ___ NumPy-Discussion mailing list NumPy-Discussion@python.org

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

Hi! Yes, I would advocate for a `force=` kwarg but personally I don't think it's explicit enough, but probably as explicit as can be given NumPy's API. Personally, I'd also raise a warning within PyData/Sparse and I hope it's in big bold letters in the docs in NumPy to be careful with this.

Re: [Numpy-discussion] Output type of round is inconsistent with python built-in

problem but can have significant impact. Best regards, Hameer Abbasi ___ NumPy-Discussion mailing list NumPy-Discussion@python.org https://mail.python.org/mailman/listinfo/numpy-discussion

[Numpy-discussion] Output type of round is inconsistent with python built-in

nd the following plan of action was proposed: * change scalar floats to return integers for __round__ (which integer type was not discussed, I propose np.int64) * not change anything else: not 0d arrays and not other numpy functionality Does an

Re: [Numpy-discussion] New DTypes: Are scalars a central concept in NumPy or not?

Hi, Sebastian, On 22.02.20, 02:37, "NumPy-Discussion on behalf of Sebastian Berg" wrote: Hi all, When we create new datatypes, we have the option to make new choices for the new datatypes [0] (not the existing ones). The question is: Should every NumPy datatype have

Re: [Numpy-discussion] NEP 38 - Universal SIMD intrinsics

—snip— > 1) Once NumPy adds the framework and initial set of Universal Intrinsic, if > contributors want to leverage a new architecture specific SIMD instruction, > will they be expected to add software implementation of this instruction for > all other architectures too? In my opinion, if

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

793>. NEP 31 — Context-local and global overrides of the NumPy API :Author: Hameer Abbasi :Author: Ralf Gommers :Author: Peter Bell :Status: Draft :Type: Standards Track :Created: 2019-08-22 Ab

Re: [Numpy-discussion] Recommended way to utilize GPUs via OpenCL, ROCm

Hello Pankaj, There's ClPy for OpenCL: https://github.com/fixstars/clpy Also this pull request for CuPy (merged, but as yet unreleased): https://github.com/cupy/cupy/pull/1094 Best regards, Hameer Abbasi On 18.10.19, 12:53, "NumPy-Discussion on behalf of Pankaj Jangid&quo

Re: [Numpy-discussion] "Spring cleaning" sprint

My bad... It's not until later. On 15.10.19, 16:16, "NumPy-Discussion on behalf of Hameer Abbasi" wrote: Is the meeting ongoing? I tried to join but there were no participants. On 10.10.19, 02:56, "NumPy-Discussion on behalf of Sebastian Berg" wrote:

Re: [Numpy-discussion] "Spring cleaning" sprint

Is the meeting ongoing? I tried to join but there were no participants. On 10.10.19, 02:56, "NumPy-Discussion on behalf of Sebastian Berg" wrote: Hi all, we are planning to remote spring to try to reduce the number of open PRs and issues, and do triage work. This is

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

On 07.09.19 22:06, Sebastian Berg wrote: On Fri, 2019-09-06 at 14:45 -0700, Ralf Gommers wrote: Let me try to move the discussion from the github issue here (this may not be the best place). (https://github.com/numpy/numpy/issues/14441 which asked for easier creation functions together with

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

On 10.09.19 05:32, Stephan Hoyer wrote: On Mon, Sep 9, 2019 at 6:27 PM Ralf Gommers > wrote: I think we've chosen to try the former - dispatch on functions so we can reuse the NumPy API. It could work out well, it could give some long-term maintenance

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

On 09.09.19 03:26, Nathaniel Smith wrote: [snip] Generic in the sense that you can write __array_ufunc__ once and have it work for all ufuncs. You can do that too with __ua_function__, you get np.ufunc.__call__, with self=. The same holds for say, RandomState objects, once implemented. Most

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

On 08.09.19 10:56, Nathaniel Smith wrote: On Sun, Sep 8, 2019 at 1:04 AM Hameer Abbasi wrote: On 08.09.19 09:53, Nathaniel Smith wrote: OTOH, __array_function__ doesn't allow this kind of simplification: if we were using __array_function__ for ufuncs, every library would have to special-case

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

On 08.09.19 10:56, Nathaniel Smith wrote: On Sun, Sep 8, 2019 at 1:04 AM Hameer Abbasi wrote: On 08.09.19 09:53, Nathaniel Smith wrote: OTOH, __array_function__ doesn't allow this kind of simplification: if we were using __array_function__ for ufuncs, every library would have to special-case

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

On 08.09.19 09:53, Nathaniel Smith wrote: On Fri, Sep 6, 2019 at 11:53 AM Ralf Gommers wrote: On Fri, Sep 6, 2019 at 12:53 AM Nathaniel Smith wrote: On Tue, Sep 3, 2019 at 2:04 AM Hameer Abbasi wrote: The fact that we're having to design more and more protocols for a lot of very similar

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

goal of "replatforming SciPy" from as far back as I met him, he's spawned quite a few efforts in that direction along with others from Quansight (and they've led to nice projects). Quansight, as I see it, is unlikely to abandon something like this if it becomes successful (and acceptan

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

. NEP 31 — Context-local and global overrides of the NumPy API :Author: Hameer Abbasi :Author: Ralf Gommers :Author: Peter Bell :Status: Draft :Type: Standards Track :Created: 2019-08-22 Abstract This NEP proposes

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

Hi Nathaniel, On 02.09.19 23:09, Nathaniel Smith wrote: On Mon, Sep 2, 2019 at 2:15 AM Hameer Abbasi wrote: Me, Ralf Gommers and Peter Bell (both cc’d) have come up with a proposal on how to solve the array creation and duck array problems. The solution is outlined in NEP-31, currently

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

: NEP 31 — Context-local and global overrides of the NumPy API :Author: Hameer Abbasi <mailto:habb...@quansight.com> :Author: Ralf Gommers <mailto:rgomm...@quansight.com> :Author

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

The full-text of the NEP is quoted below, apologies for not including it earlier: NEP 31 — Context-local and global overrides of the NumPy API :Author: Hameer Abbasi

Re: [Numpy-discussion] Adding generic dtypes

Hi Sebastian; all: I plan to attend the dtype meeting. Monday 11 AM California time is fine for me. Best regards, Hameer Abbasi Get Outlook for iOS<https://aka.ms/o0ukef> From: NumPy-Discussion on behalf of Sebastian Berg Sent: Thursday, July 25, 2019

Re: [Numpy-discussion] Creating a sine wave with exponential decay

Hi Ram, No, NumPy doesn’t have a way. And it newer versions, it probably won’t create two arrays if all the dtypes match, it’ll do some magic to re use the existing ones, although it will use multiple loops instead of just one. You might want to look into NumExpr or Numba if you want an

[Numpy-discussion] uarray update: API changes, overhead and comparison to __array_function__

Hello all, I just wrote a blog post on uarray and how it compares against NumPy’s __array_function__ protocol. Give it a read here: https://labs.quansight.org/blog/2019/07/uarray-update-api-changes-overhead-and-comparison-to-__array_function__/ Best Regards, Hameer Abbasi

Re: [Numpy-discussion] Problem with absolute value

with how the integer is stored in memory and how you're running out of space. Regards, Hameer Abbasi On 03.07.19, 17:03, "NumPy-Discussion on behalf of Nicolas Rougier" wrote: Hi, I’m a bit surprised with the following code: >>> import numpy as np

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

Given that np.dot and np.matmul do the right thing for 1-D arrays, I would be opposed to introducing an error as well. From: NumPy-Discussion on behalf of Ilhan Polat Reply-To: Discussion of Numerical Python Date: Monday, 24. June 2019 at 11:58 To: Discussion of Numerical Python

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

+1 for this. I have often seen (and sometimes written) code that does this automatically, and it is a common mistake. However, we will 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

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

On Tue, 2019-06-18 at 04:28 +0200, Hameer Abbasi wrote: > On Wed, 2019-06-12 at 12:55 -0500, Sebastian Berg wrote: > > On Wed, 2019-06-05 at 15:41 -0500, Sebastian Berg wrote: > > > Hi all, > > > > > > TL;DR: > > > > > > Value

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

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 where floats cannot.

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] 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(..., >

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

[Numpy-discussion] defining a NumPy API standard?

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

[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] 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)>

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

atibility > 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 ___ NumPy-

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

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

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

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

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

ter/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 accompany

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

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] Debugging NumPy development build in conda environment

> > 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 your case, it might be the second that helps. If it’s no

[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] Warn or immidiately change readonly flag on broadcast_arrays return value?

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

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

[Numpy-discussion] Vectorized version of numpy.linspace

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

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

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

ng 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 > > -- M

[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 in pu

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

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

l 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, such as how to treat explicit > zeros (that debate s

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

, 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 scipy.spars

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

into 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 matr

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

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] asanyarray vs. asarray

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

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

the 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] random.choice(replace=False) very slow

ple 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

[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] Proposal to accept NEP-18, __array_function__ protocol

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/doc/numpy/dev/go

[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

> 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

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

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

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

t;Callable >> objects generated at runtime" clarifying that to handle such objects is out >> of scope for the initial proposal in the NEP. >> >> If there are no substantive objections within 7 days from this email, then >> the NEP will be accepted; see NEP 0 for more

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

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 ___ NumPy-

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 >

  1   2   >