Re: [Numpy-discussion] Converting np.sinc into a ufunc

[Nathan Goldbaum]

It might be worth using BigQuery to search the github repository public
dataset for usages of np.sinc with keyword arguments.

On Wed, May 22, 2019 at 1:05 PM Sebastian Berg 
wrote:

> Hi all,
>
> there is an open PR (https://github.com/numpy/numpy/pull/12924) to
> convert `np.sinc` into a ufunc. Since it should improve general
> precision in `np.sinc`, I thought we could try to move that forward a
> bit. We check whether this is worth it or not in the end.
>
> However, it would also change behaviour slightly since `np.sinc(x=arr)`
> will not work, as ufuncs are positional arguments only (we could wrap
> `sinc`, but that hides all the nice features). Otherwise, there should
> be no change except additional features of ufuncs and the move to a C
> implementation.
>
> This is mostly to see if anyone is worried about possible slight API
> change here.
>
> All the Best,
>
> Sebastian
> ___
> NumPy-Discussion mailing list
> NumPy-Discussion@python.org
> https://mail.python.org/mailman/listinfo/numpy-discussion
>
___
NumPy-Discussion mailing list
NumPy-Discussion@python.org
https://mail.python.org/mailman/listinfo/numpy-discussion

[Numpy-discussion] [ANN] 2019 Scipy Conference: Call for Proposals

[Nathan Goldbaum]

SciPy 2019, the 18th annual Scientific Computing with Python conference,
will be held July 8-14, 2019 in Austin, Texas. The annual SciPy Conference
brings together over 800 participants from industry, academia, and
government to showcase their latest projects, learn from skilled users and
developers, and collaborate on code development. The call for abstracts for
SciPy 2019 for talks, posters and tutorials is now open. The deadline for
submissions is February 10, 2019.

Conference Website: https://www.scipy2019.scipy.org/

Submission Website: https://easychair.org/conferences/?conf=scipy2019

Talks and Posters (July 10-12, 2019)

In addition to the general track, this year will have specialized tracks
focused on:


   -

   Data Driven Discoveries (including Machine Learning and Data Science)
   -

   Open Source Communities (Sustainability)


Mini Symposia

   -

   Science Communication through Visualization
   -

   Neuroscience and Cognitive Science
   -

   Image Processing
   -

   Earth, Ocean, Geo and Atmospheric Science



There will also be a SciPy Tools Plenary Session each day with 2 to 5
minute updates on tools and libraries.

Tutorials (July 8-9, 2019)

Tutorials should be focused on covering a well-defined topic in a hands-on
manner. We are looking for useful techniques or packages, helping new or
advanced Python programmers develop better or faster scientific
applications. We encourage submissions to be designed to allow at least 50%
of the time for hands-on exercises even if this means the subject matter
needs to be limited. Tutorials will be 4 hours in duration. In your
tutorial application, you can indicate what prerequisite skills and
knowledge will be needed for your tutorial, and the approximate expected
level of knowledge of your students (i.e., beginner, intermediate,
advanced). Instructors of accepted tutorials will receive a stipend.
___
NumPy-Discussion mailing list
NumPy-Discussion@python.org
https://mail.python.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Taking back control of the #numpy irc channel

[Nathan Goldbaum]

Hi,

I idle in #scipy and have op in there. I’m happy start idling in #numpy and
be op if the community is willing to let me. I’m also in the process of
getting ops for #matplotlib for similar spam-related reasons. I’d say all
the scientific python IRC channels I’m in get a decent amount of traffic
(perhaps 10% of the number of questions that get asked on StackOverflow)
and it’s a good venue for asking quick questions. Let’s hope that forcing
people to register doesn’t kill that, although there’s not much we can do
given the spam attack.

Nathan

On Mon, Aug 6, 2018 at 9:03 PM Matti Picus  wrote:

> Over the past few days spambots have been hitting freenode's IRC
> channels[0, 1]. It turns out the #numpy channel has no operator, so we
> cannot make the channel mode "|+q $~a"[2] - i.e. only registered
> freenode users can talk but anyone can listen.
>
> I was in touch with the freenode staff, they requested that someone from
> the steering council reach out to them at ||proje...@freenode.net, here
> is the quote from the discussion:
>
> "
> it's pretty much a matter of them sending an email telling us who they'd
> like to represent them on freenode, which channels and cloak namespaces
> they want, and any info we might need on the project
> "
>
> In the mean time they set the channel mode appropriately, so this is
> also a notice that if you want to chat on the #numpy IRC channel you
> need to register.
>
> Hope someone from the council picks this up and reaches out to them, and
> will decide who is to able to become channel operators (the recommended
> practice is to use it like sudo, only assume the role when needed then
> turn it back off).
>
> Matti
>
> [0] https://freenode.net/news/spambot-attack
> [1] https://freenode.net/news/spam-shake
> [2] https://nedbatchelder.com/blog/201808/fighting_spam_on_freenode.html
> |
> ___
> NumPy-Discussion mailing list
> NumPy-Discussion@python.org
> https://mail.python.org/mailman/listinfo/numpy-discussion
>
___
NumPy-Discussion mailing list
NumPy-Discussion@python.org
https://mail.python.org/mailman/listinfo/numpy-discussion

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

[Nathan Goldbaum]

On Wed, Aug 1, 2018 at 9:49 AM, Ralf Gommers  wrote:

>
>
> On Wed, Aug 1, 2018 at 12:20 AM, Nathan Goldbaum 
> wrote:
>
>> I realize this was probably brought up in the discussions about the scipy
>> code of conduct which I have not looked at, but I’m troubled by the
>> inclusion of “political beliefs” in the document.
>>
>
> It was not brought up explicitly as far as I remember.
>
>
>> See e.g.
>> https://github.com/jupyter/governance/pull/5
>>
>
> That's about moving names around. I don't see any mention of political
> beliefs?
>

Sorry about that, I elided the 6. This is the correct link:

https://github.com/jupyter/governance/pull/56


>
>
>> As a thought experiment, what if someone’s political beliefs imply that
>> other contributors are not deserving of human rights? Increasingly ideas
>> like this are coming into the mainstream worldwide and I think this is a
>> real concern that should be considered.
>>
>
> There is a difference between having beliefs, and expressing those beliefs
> in ways that offends others. I don't see any problem with saying that we
> welcome anyone, irrespective of political belief. However, if someone
> starts expressing things that are intolerant (like someone else not
> deserving human rights) on any of our communication forums or in an
> in-person meeting, that would be a clear violation of the CoC. Which can be
> dealt with via the reporting and enforcement mechanism in the CoC.
>
> I don't see a problem here, but I would see a real problem with removing
> the "political beliefs" phrase.
>

For another perspective on this issue see
https://where.coraline.codes/blog/oscon/, where Coraline Ada describes her
reasons for not speaking at OSCON this year due to a similar clause in the
code of conduct.


Cheers,
> Ralf
>
>
>
>>
>> On Mon, Jul 30, 2018 at 8:25 PM Charles R Harris <
>> charlesr.har...@gmail.com> wrote:
>>
>>> On Fri, Jul 27, 2018 at 4:02 PM, Stefan van der Walt <
>>> stef...@berkeley.edu> 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
>>>> stating clearly the kinds of behavior that would and would not be
>>>> tolerated.
>>>>
>>>> I propose that we adopt the SciPy code of conduct for NumPy as well.  It
>>>> is a good way to signal to newcomers that this is a community that cares
>>>> about how people are treated.  And I think we should do anything in our
>>>> power to make NumPy as attractive as possible!
>>>>
>>>> If we adopt this document as policy, we will need to select a Code of
>>>> Conduct committee, to whom potential transgressions can be reported.
>>>> The individuals doing this for SciPy may very well be happy to do the
>>>> same for NumPy, but the community should decide whom will best serve
>>>> those roles.
>>>>
>>>> Let me know your thoughts.
>>>>
>>>
>>> +1 from me.
>>>
>>> Chuck
>>> ___
>>> NumPy-Discussion mailing list
>>> NumPy-Discussion@python.org
>>> https://mail.python.org/mailman/listinfo/numpy-discussion
>>>
>>
>> ___
>> NumPy-Discussion mailing list
>> NumPy-Discussion@python.org
>> https://mail.python.org/mailman/listinfo/numpy-discussion
>>
>>
>
> ___
> NumPy-Discussion mailing list
> NumPy-Discussion@python.org
> https://mail.python.org/mailman/listinfo/numpy-discussion
>
>
___
NumPy-Discussion mailing list
NumPy-Discussion@python.org
https://mail.python.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] NumPy 1.15.0rc2 released.

[Nathan Goldbaum]

Hi Chuck,

Is there a summary of the differences with respect to rc1 somewhere?

Nathan

On Mon, Jul 9, 2018 at 5:08 PM Charles R Harris 
wrote:

> Hi All,
>
> On behalf of the NumPy team I'm pleased to announce the release of NumPy
> 1.15.0rc2.
> This release has an unusual number of cleanups, many deprecations of old
> functions,
> and improvements to many existing functions. A total of 435 pull reguests
> were merged
> for this release, please look at the release notes
> for details. Some
> highlights are:
>
>- NumPy has switched to pytest for testing.
>- A new  `numpy.printoptions` context manager.
>- Many improvements to the histogram functions.
>- Support for unicode field names in python 2.7.
>- Improved support for PyPy.
>- Fixes and improvements to `numpy.einsum`.
>
> The Python versions supported by this release are 2.7, 3.4-3.7.  The
> wheels are linked with
> OpenBLAS v0.3.0, which should fix some of the linalg problems reported for
> NumPy 1.14.
>
> Wheels for this release can be downloaded from PyPI
> , source archives are available
> from Github .
>
> A total of 131 people contributed to this release.  People with a "+" by
> their
> names contributed a patch for the first time.
>
>
>- Aaron Critchley +
>- Aarthi +
>- Aarthi Agurusa +
>- Alex Thomas +
>- Alexander Belopolsky
>- Allan Haldane
>- Anas Khan +
>- Andras Deak
>- Andrey Portnoy +
>- Anna Chiara
>- Aurelien Jarno +
>- Baurzhan Muftakhidinov
>- Berend Kapelle +
>- Bernhard M. Wiedemann
>- Bjoern Thiel +
>- Bob Eldering
>- Cenny Wenner +
>- Charles Harris
>- ChloeColeongco +
>- Chris Billington +
>- Christopher +
>- Chun-Wei Yuan +
>- Claudio Freire +
>- Daniel Smith
>- Darcy Meyer +
>- David Abdurachmanov +
>- David Freese
>- Deepak Kumar Gouda +
>- Dennis Weyland +
>- Derrick Williams +
>- Dmitriy Shalyga +
>- Eric Cousineau +
>- Eric Larson
>- Eric Wieser
>- Evgeni Burovski
>- Frederick Lefebvre +
>- Gaspar Karm +
>- Geoffrey Irving
>- Gerhard Hobler +
>- Gerrit Holl
>- Guo Ci +
>- Hameer Abbasi +
>- Han Shen
>- Hiroyuki V. Yamazaki +
>- Hong Xu
>- Ihor Melnyk +
>- Jaime Fernandez
>- Jake VanderPlas +
>- James Tocknell +
>- Jarrod Millman
>- Jeff VanOss +
>- John Kirkham
>- Jonas Rauber +
>- Jonathan March +
>- Joseph Fox-Rabinovitz
>- Julian Taylor
>- Junjie Bai +
>- Juris Bogusevs +
>- Jörg Döpfert
>- Kenichi Maehashi +
>- Kevin Sheppard
>- Kimikazu Kato +
>- Kirit Thadaka +
>- Kritika Jalan +
>- Lakshay Garg +
>- Lars G +
>- Licht Takeuchi
>- Louis Potok +
>- Luke Zoltan Kelley
>- MSeifert04 +
>- Mads R. B. Kristensen +
>- Malcolm Smith +
>- Mark Harfouche +
>- Marten H. van Kerkwijk +
>- Marten van Kerkwijk
>- Matheus Vieira Portela +
>- Mathieu Lamarre
>- Mathieu Sornay +
>- Matthew Brett
>- Matthew Rocklin +
>- Matthias Bussonnier
>- Matti Picus
>- Michael Droettboom
>- Miguel Sánchez de León Peque +
>- Mike Toews +
>- Milo +
>- Nathaniel J. Smith
>- Nelle Varoquaux
>- Nicholas Nadeau, P.Eng., AVS +
>- Nick Minkyu Lee +
>- Nikita +
>- Nikita Kartashov +
>- Nils Becker +
>- Oleg Zabluda
>- Orestis Floros +
>- Pat Gunn +
>- Paul van Mulbregt +
>- Pauli Virtanen
>- Pierre Chanial +
>- Ralf Gommers
>- Raunak Shah +
>- Robert Kern
>- Russell Keith-Magee +
>- Ryan Soklaski +
>- Samuel Jackson +
>- Sebastian Berg
>- Siavash Eliasi +
>- Simon Conseil
>- Simon Gibbons
>- Stefan Krah +
>- Stefan van der Walt
>- Stephan Hoyer
>- Subhendu +
>- Subhendu Ranjan Mishra +
>- Tai-Lin Wu +
>- Tobias Fischer +
>- Toshiki Kataoka +
>- Tyler Reddy +
>- Unknown +
>- Varun Nayyar
>- Victor Rodriguez +
>- Warren Weckesser
>- William D. Irons +
>- Zane Bradley +
>- fo40225 +
>- lapack_lite code generator +
>- lumbric +
>- luzpaz +
>- mamrehn +
>- tynn +
>- xoviat
>
> Cheers
>
> Chuck
>
>
> ___
> NumPy-Discussion mailing list
> NumPy-Discussion@python.org
> https://mail.python.org/mailman/listinfo/numpy-discussion
>
___
NumPy-Discussion mailing list
NumPy-Discussion@python.org
https://mail.python.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] PEP 574 - zero-copy pickling with out of band data

[Nathan Goldbaum]

On Mon, Jul 2, 2018 at 7:42 PM Andrew Nelson  wrote:

> 
>
> On Tue, 3 Jul 2018 at 09:31, Charles R Harris 
> wrote:
>
>>
>> ISTR that some parallel processing applications sent pickled arrays
>> around to different processes, I don't know if that is still the case, but
>> if so, no copy might be a big gain for them.
>>
>
> That is very much correct. One example is using MCMC, which is massively
> parallel. I do parallelisation with mpi4py, and this requires distribution
> of pickled data of a reasonable size to the entire MPI world. This pickling
> introduces quite a bit of overhead.
>

Doesn’t mpi4py have support for buffered low-level communication of numpy
arrays? See e.g.
https://mpi4py.scipy.org/docs/usrman/tutorial.html

Although I guess with Antoine’s proposal uses of the “lowercase” mpi4py API
where data might get pickled will see speedups.

___
> NumPy-Discussion mailing list
> NumPy-Discussion@python.org
> https://mail.python.org/mailman/listinfo/numpy-discussion
>
___
NumPy-Discussion mailing list
NumPy-Discussion@python.org
https://mail.python.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] rackspace ssl certificates

[Nathan Goldbaum]

I think Matthew Brett needs to fix this.

On Mon, Jun 18, 2018 at 3:20 PM Charles R Harris 
wrote:

> Hi All,
>
> I've been trying to put out the NumPy 1.15.0rc1, but cannot get
> `numpy-wheels` to upload the wheels to rackspace on windows, there is a
> certification problem. I note that that requirement was supposedly disabled:
>
>  on_success:
>   # Upload the generated wheel package to Rackspace
>   # On Windows, Apache Libcloud cannot find a standard CA cert bundle so we
>   # disable the ssl checks.
>
> and nothing relevant seems to have changed in our `.appveyor.yml` since
> the last successful run 7 days ago, 6 if we count 1.14.5, so I'm thinking a
> policy has changed at either at rackspace or appveyor, but that is just a
> guess. I'm experimenting with various changes to the script and the
> `apache-libcloud` version to see if I can get success, but thought I'd ask
> if anyone knew anything that might be helpful.
>
> Chuck
> ___
> NumPy-Discussion mailing list
> NumPy-Discussion@python.org
> https://mail.python.org/mailman/listinfo/numpy-discussion
>
___
NumPy-Discussion mailing list
NumPy-Discussion@python.org
https://mail.python.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Updated 1.15.0 release notes

[Nathan Goldbaum]

Hi Chuck,

Are you planning on doing an rc release this time? I think the NumPy 1.14
release was unusually bumpy and part of that was the lack of an rc. One
example: importing h5py caused a warning under numpy 1.14 and an h5py
release didn’t come out with a workaround or fix for a couple months. There
was also an issue with array printing that caused problems in yt (although
both yt and NumPy quickly did bugfix releases that fixed that).

I guess 1.14 was particularly noisy, but still I’d really appreciate having
a prerelease version to test against and some time to report issues with
the prerelease so numpy and other projects can implement workarounds as
needed without doing a release that might potentially break real users who
happen to install right after numpy 1.x.0 comes out.

Best,
Nathan Goldbaum

On Wed, Jun 13, 2018 at 7:11 PM Charles R Harris 
wrote:

> Hi All,
>
> There is a PR for the updated NumPy 1.15.0 release notes
> <https://github.com/numpy/numpy/pull/11327> . I would appreciate it if
> all those involved in the thatn release would have a look and fix incorrect
> or missing notes.
>
> Cheers,
>
> Chuck
>
> ___
> NumPy-Discussion mailing list
> NumPy-Discussion@python.org
> https://mail.python.org/mailman/listinfo/numpy-discussion
>
___
NumPy-Discussion mailing list
NumPy-Discussion@python.org
https://mail.python.org/mailman/listinfo/numpy-discussion

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

[Nathan Goldbaum]

Hmm, does this mean the callable that gets passed into __array_ufunc__ will
change? I'm pretty sure that will break the dispatch mechanism I'm using in
my __array_ufunc__ implementation, which directly checks whether the
callable is in one of several tuples of functions that have different
behavior.

On Tue, Jun 5, 2018 at 7:32 PM, Marten van Kerkwijk <
m.h.vankerkw...@gmail.com> wrote:

> Yes, the function should definitely be the same as what the user called -
> i.e., the decorated function. I'm only wondering if it would also be
> possible to have access to the undecorated one (via `coerce` or
> `ndarray.__array_function__` or otherwise).
> -- Marten
>
>
> ___
> NumPy-Discussion mailing list
> NumPy-Discussion@python.org
> https://mail.python.org/mailman/listinfo/numpy-discussion
>
>
___
NumPy-Discussion mailing list
NumPy-Discussion@python.org
https://mail.python.org/mailman/listinfo/numpy-discussion

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

[Nathan Goldbaum]

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.

On Sat, Jun 2, 2018 at 5:56 PM Stephan Hoyer  wrote:

> Matthew Rocklin and I have written NEP-18, which proposes a new dispatch
> mechanism for NumPy's high level API:
> http://www.numpy.org/neps/nep-0018-array-function-protocol.html
>
> There has already been a little bit of scattered discussion on the pull
> request (https://github.com/numpy/numpy/pull/11189), but per NEP-0 let's
> try to keep high-level discussion here on the mailing list.
>
> The full text of the NEP is reproduced below:
>
> ==
> NEP: Dispatch Mechanism for NumPy's high level API
> ==
>
> :Author: Stephan Hoyer 
> :Author: Matthew Rocklin 
> :Status: Draft
> :Type: Standards Track
> :Created: 2018-05-29
>
> Abstact
> ---
>
> We propose a protocol to allow arguments of numpy functions to define
> how that function operates on them. This allows other libraries that
> implement NumPy's high level API to reuse Numpy functions. This allows
> libraries that extend NumPy's high level API to apply to more NumPy-like
> libraries.
>
> Detailed description
> 
>
> Numpy's high level ndarray API has been implemented several times
> outside of NumPy itself for different architectures, such as for GPU
> arrays (CuPy), Sparse arrays (scipy.sparse, pydata/sparse) and parallel
> arrays (Dask array) as well as various Numpy-like implementations in the
> deep learning frameworks, like TensorFlow and PyTorch.
>
> Similarly there are several projects that build on top of the Numpy API
> for labeled and indexed arrays (XArray), automatic differentation
> (Autograd, Tangent), higher order array factorizations (TensorLy), etc.
> that add additional functionality on top of the Numpy API.
>
> We would like to be able to use these libraries together, for example we
> would like to be able to place a CuPy array within XArray, or perform
> automatic differentiation on Dask array code. This would be easier to
> accomplish if code written for NumPy ndarrays could also be used by
> other NumPy-like projects.
>
> For example, we would like for the following code example to work
> equally well with any Numpy-like array object:
>
> .. code:: python
>
> def f(x):
> y = np.tensordot(x, x.T)
> return np.mean(np.exp(y))
>
> Some of this is possible today with various protocol mechanisms within
> Numpy.
>
> -  The ``np.exp`` function checks the ``__array_ufunc__`` protocol
> -  The ``.T`` method works using Python's method dispatch
> -  The ``np.mean`` function explicitly checks for a ``.mean`` method on
>the argument
>
> However other functions, like ``np.tensordot`` do not dispatch, and
> instead are likely to coerce to a Numpy array (using the ``__array__``)
> protocol, or err outright. To achieve enough coverage of the NumPy API
> to support downstream projects like XArray and autograd we want to
> support *almost all* functions within Numpy, which calls for a more
> reaching protocol than just ``__array_ufunc__``. We would like a
> protocol that allows arguments of a NumPy function to take control and
> divert execution to another function (for example a GPU or parallel
> implementation) in a way that is safe and consistent across projects.
>
> Implementation
> --
>
> We propose adding support for a new protocol in NumPy,
> ``__array_function__``.
>
> This protocol is intended to be a catch-all for NumPy functionality that
> is not covered by existing protocols, like reductions (like ``np.sum``)
> or universal functions (like ``np.exp``). The semantics are very similar
> to ``__array_ufunc__``, except the operation is specified by an
> arbitrary callable object rather than a ufunc instance and method.
>
> The interface
> ~
>
> We propose the following signature for implementations of
> ``__array_function__``:
>
> .. code-block:: python
>
> def __array_function__(self, func, types, args, kwargs)
>
> -  ``func`` is an arbitrary callable exposed by NumPy's public API,
>which was called in the form ``func(*args, **kwargs)``.
> -  ``types`` is a list of types for all arguments to the original NumPy
>function call that will be checked for an ``__array_function__``
>implementation.
> -  The tuple ``args`` and dict ``**kwargs`` are directly passed on from the
>original call.
>
> Unlike ``__array_ufunc__``, there are no high-level guarantees about the
> type of ``func``, or about which of ``args`` and ``kwargs`` may contain
> objects
> implementing the array API. As a convenience for ``__array_function__``
> implementors of the NumPy API, the ``types`` keyword contains a list of all
> types that implement the ``__array_function__`` 

[Numpy-discussion] Citation for ndarray

[Nathan Goldbaum]

Hi all,

I see listed on the scipy.org site that the preferred citation for NumPy is
the "Guide to NumPy":

https://www.scipy.org/citing.html

This could work for what I'm writing, but I'd prefer to find a citation
specifically for NumPy's ndarray data structure. Does such a citation exist?

Thanks!

-Nathan
___
NumPy-Discussion mailing list
NumPy-Discussion@python.org
https://mail.python.org/mailman/listinfo/numpy-discussion

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

[Nathan Goldbaum]

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]: data = [1, 2, 3]*km

In [4]: np.ones_like(data)
Out[4]: YTArray([1., 1., 1.]) km


On Fri, May 18, 2018 at 9:51 AM, Marten van Kerkwijk <
m.h.vankerkw...@gmail.com> wrote:

> I'm greatly in favour, especially if the same can be done for
> `zeros_like` and `empty_like`, but note that a tricky part is that
> ufuncs do not deal very graciously with structured (void) and string
> dtypes. -- Marten
> ___
> NumPy-Discussion mailing list
> NumPy-Discussion@python.org
> https://mail.python.org/mailman/listinfo/numpy-discussion
>
___
NumPy-Discussion mailing list
NumPy-Discussion@python.org
https://mail.python.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Casting scalars

[Nathan Goldbaum]

On Thu, May 10, 2018 at 9:51 PM Stuart Reynolds 
wrote:

> np.float(scalar)
>

This actually isn't right. It's a common misconception, but np.float is an
alias to the built-in float type. You probably want np.float_(scalar)

In [5]: np.float_(12).dtype
Out[5]: dtype('float64')

In [6]: np.float is float
Out[6]: True


>
> On Thu, May 10, 2018 at 7:49 PM Hameer Abbasi 
> wrote:
>
>> 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/mailman/listinfo/numpy-discussion
>>
> ___
> NumPy-Discussion mailing list
> NumPy-Discussion@python.org
> https://mail.python.org/mailman/listinfo/numpy-discussion
>
___
NumPy-Discussion mailing list
NumPy-Discussion@python.org
https://mail.python.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Casting scalars

[Nathan Goldbaum]

In [1]: import numpy as np

In [2]: np.float64(12)
Out[2]: 12.0

In [3]: np.float64(12).dtype
Out[3]: dtype('float64')

On Thu, May 10, 2018 at 9:49 PM Hameer Abbasi 
wrote:

> 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/mailman/listinfo/numpy-discussion
>
___
NumPy-Discussion mailing list
NumPy-Discussion@python.org
https://mail.python.org/mailman/listinfo/numpy-discussion

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

[Nathan Goldbaum]

On Thu, Apr 26, 2018 at 12:03 PM Joseph Fox-Rabinovitz <
jfoxrabinov...@gmail.com> wrote:

> Would it be useful to have a short-circuited version of the function that
> is not a ufunc?
>

Yes definitely. I could use numba as suggested by Hameer but I'd rather not
add a new runtime dependency. I could use cython or C but I'd need to deal
with the packaging headaches of including C code in your package.

I guess I could also create a new project that just implements the
functions I need in cython, deal with the packaging headaches there, and
then depend on that package. At least that way others won't need to deal
with the pain :)


> - Joe
>
> On Thu, Apr 26, 2018 at 12:51 PM, Hameer Abbasi <einstein.edi...@gmail.com
> > wrote:
>
>> Hi Nathan,
>>
>> np.any and np.all call np.or.reduce and np.and.reduce respectively, and
>> unfortunately the underlying function (ufunc.reduce) has no way of
>> detecting that the value isn’t going to change anymore. It’s also used for
>> (for example) np.sum (np.add.reduce), np.prod (np.multiply.reduce),
>> np.min(np.minimum.reduce), np.max(np.maximum.reduce).
>>
>> You can find more information about this on the ufunc doc page
>> <https://docs.scipy.org/doc/numpy/reference/ufuncs.html>. I don’t think
>> it’s worth it to break this machinery for any and all, as it has numerous
>> other advantages (such as being able 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 <nathan12...@gmail.com> 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]: import numpy as np
>>
>> In [2]: data = np.arange(1e6)
>>
>> In [3]: print(data[:10])
>> [0. 1. 2. 3. 4. 5. 6. 7. 8. 9.]
>>
>> In [4]: %timeit np.any(data)
>> 724 us +- 42.4 us per loop (mean +- std. dev. of 7 runs, 1000 loops each)
>>
>> In [5]: data = np.zeros(int(1e6))
>>
>> In [6]: %timeit np.any(data)
>> 732 us +- 52.9 us per loop (mean +- std. dev. of 7 runs, 1000 loops each)
>>
>> I don't see any discussions about this on the NumPy issue tracker but
>> perhaps I'm missing something.
>>
>> I'm curious if there's a way to get a fast early-terminating search in
>> NumPy? Perhaps there's another package I can depend on that does this? I
>> guess I could also write a bit of cython code that does this but so far
>> this project is pure python and I don't want to deal with the packaging
>> headache of getting wheels built and conda-forge packages set up on all
>> platforms.
>>
>> Thanks for your help!
>>
>> -Nathan
>>
>> ___
>> NumPy-Discussion mailing list
>> NumPy-Discussion@python.org
>> https://mail.python.org/mailman/listinfo/numpy-discussion
>>
>>
>> ___
>> NumPy-Discussion mailing list
>> NumPy-Discussion@python.org
>> https://mail.python.org/mailman/listinfo/numpy-discussion
>>
>>
> ___
> NumPy-Discussion mailing list
> NumPy-Discussion@python.org
> https://mail.python.org/mailman/listinfo/numpy-discussion
>
___
NumPy-Discussion mailing list
NumPy-Discussion@python.org
https://mail.python.org/mailman/listinfo/numpy-discussion

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

[Nathan Goldbaum]

On Thu, Apr 26, 2018 at 11:52 AM Hameer Abbasi <einstein.edi...@gmail.com>
wrote:

> Hi Nathan,
>
> np.any and np.all call np.or.reduce and np.and.reduce respectively, and
> unfortunately the underlying function (ufunc.reduce) has no way of
> detecting that the value isn’t going to change anymore. It’s also used for
> (for example) np.sum (np.add.reduce), np.prod (np.multiply.reduce),
> np.min(np.minimum.reduce), np.max(np.maximum.reduce).
>
> You can find more information about this on the ufunc doc page
> <https://docs.scipy.org/doc/numpy/reference/ufuncs.html>. I don’t think
> it’s worth it to break this machinery for any and all, as it has numerous
> other advantages (such as being able to override in duck arrays, etc)
>

Sure, I'm not saying that numpy should change, more trying to see if
there's an alternate way to get what I want in NumPy or some other package.


>
> Best regards,
> Hameer Abbasi
> Sent from Astro <https://www.helloastro.com> for Mac
>
> On Apr 26, 2018 at 18:45, Nathan Goldbaum <nathan12...@gmail.com> 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]: import numpy as np
>
> In [2]: data = np.arange(1e6)
>
> In [3]: print(data[:10])
> [0. 1. 2. 3. 4. 5. 6. 7. 8. 9.]
>
> In [4]: %timeit np.any(data)
> 724 us +- 42.4 us per loop (mean +- std. dev. of 7 runs, 1000 loops each)
>
> In [5]: data = np.zeros(int(1e6))
>
> In [6]: %timeit np.any(data)
> 732 us +- 52.9 us per loop (mean +- std. dev. of 7 runs, 1000 loops each)
>
> I don't see any discussions about this on the NumPy issue tracker but
> perhaps I'm missing something.
>
> I'm curious if there's a way to get a fast early-terminating search in
> NumPy? Perhaps there's another package I can depend on that does this? I
> guess I could also write a bit of cython code that does this but so far
> this project is pure python and I don't want to deal with the packaging
> headache of getting wheels built and conda-forge packages set up on all
> platforms.
>
> Thanks for your help!
>
> -Nathan
>
> ___
> NumPy-Discussion mailing list
> NumPy-Discussion@python.org
> https://mail.python.org/mailman/listinfo/numpy-discussion
>
> ___
> NumPy-Discussion mailing list
> NumPy-Discussion@python.org
> https://mail.python.org/mailman/listinfo/numpy-discussion
>
___
NumPy-Discussion mailing list
NumPy-Discussion@python.org
https://mail.python.org/mailman/listinfo/numpy-discussion

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

[Nathan Goldbaum]

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]: import numpy as np

In [2]: data = np.arange(1e6)

In [3]: print(data[:10])
[0. 1. 2. 3. 4. 5. 6. 7. 8. 9.]

In [4]: %timeit np.any(data)
724 us +- 42.4 us per loop (mean +- std. dev. of 7 runs, 1000 loops each)

In [5]: data = np.zeros(int(1e6))

In [6]: %timeit np.any(data)
732 us +- 52.9 us per loop (mean +- std. dev. of 7 runs, 1000 loops each)

I don't see any discussions about this on the NumPy issue tracker but
perhaps I'm missing something.

I'm curious if there's a way to get a fast early-terminating search in
NumPy? Perhaps there's another package I can depend on that does this? I
guess I could also write a bit of cython code that does this but so far
this project is pure python and I don't want to deal with the packaging
headache of getting wheels built and conda-forge packages set up on all
platforms.

Thanks for your help!

-Nathan
___
NumPy-Discussion mailing list
NumPy-Discussion@python.org
https://mail.python.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Introduction: NumPy developers at BIDS

[Nathan Goldbaum]

On Tue, Apr 10, 2018 at 9:59 AM, Stefan van der Walt 
wrote:

> Hi Eric,
>
> On Sun, 08 Apr 2018 08:02:19 -1000, Eric Firing wrote:
> > On 2018/04/07 9:19 PM, Stefan van der Walt wrote:
> > > We would love community input on identifying the best areas & issues to
> > > pay attention to,
> >
> > What is the best way to provide this, and how will the decisions be
> > made?
>
> These are good questions.  We are also new at this, so while we have
> some ideas on how things could work, we may have to refine the process
> along the way.
>
> We want to operate as openly as we can, so discussing ideas on the
> mailing list is a preferred first option.  But we're also open to
> inchoate ideas and recommendations (including on how we run things on
> our end) via email.  Unless instructed explicitly otherwise, those ideas
> will likely bubble up into posts here anyway.
>
> Since we're learning the ropes, we'd like to expose the team to a wide
> variety of ideas.  Visitors to the team are most welcome---please reach
> out to me if you want to talk to us, either in person or via video chat.
>
> Can you help us think of good ways to learn "community priorities"?
> E.g., for GitHub issues, should we take monthly polls, count the number
> of "thumbs up"s, consider issues with the most comments, or tally the
> number of explicit mentions of team members?
>

Keep in mind that only a subset of the community engages on GitHub (mostly
developers who are already engaged in the numpy community).

You may want to explore other venues for this sort of feedback, e.g. a
SciPy BoF session, which will capture a different subset of the community.


>
> Best regards,
> Stéfan
> ___
> NumPy-Discussion mailing list
> NumPy-Discussion@python.org
> https://mail.python.org/mailman/listinfo/numpy-discussion
>
___
NumPy-Discussion mailing list
NumPy-Discussion@python.org
https://mail.python.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] is __array_ufunc__ ready for prime-time?

[Nathan Goldbaum]

On Thu, Nov 2, 2017 at 5:21 PM, Stephan Hoyer <sho...@gmail.com> wrote:

> On Thu, Nov 2, 2017 at 12:42 PM Nathan Goldbaum <nathan12...@gmail.com>
> wrote:
>
>> Would this issue be ameliorated given Nathaniel's proposal to try to move
>> away from subclasses and towards storing data in dtypes? Or would that just
>> mean that xarray would need to ban dtypes it doesn't know about?
>>
>
> Yes, I think custom dtypes would definitely help. Custom dtypes have a
> well contained interface, so lots of operations (e.g., concatenate,
> reshaping, indexing) are guaranteed to work in a dtype independent way. If
> you try to do an unsupported operation for such a dtype (e.g.,
> np.datetime64), you will generally get a good error message about an
> invalid dtype.
>
> In contrast, you can overload a subclass with totally arbitrary semantics
> (e.g., np.matrix) and of course for duck-types as well.
>
> This makes a big difference for libraries like dask or xarray, which need
> a standard interface to guarantee they do the right thing. I'm pretty sure
> we can wrap a custom dtype ndarray with units, but there's no way we're
> going to support np.matrix without significant work. It's hard to know
> which is which without well defined interfaces.
>

Ah, but what if the dtype modifies the interface? That might sound evil,
but it's something that's been proposed. For example, if I wanted to
replace yt's YTArray in a backward compatibile way with a dtype and just
use plain ndarrays everywhere, the dtype would need to *at least* modify
ndarray's API, adding e.g. to(), convert_to_unit(), a units attribute, and
several other things.

Of course if I don't care about backward compatibility I can just do all of
these operations on the dtype object itself. However, I suspect whatever
implementation of custom dtypes gets added to numpy, it will have the
property that it can act like an arbitrary ndarray subclass otherwise
libraries like yt, Pint, metpy, and astropy won't be able to switch to it.

-Nathan


>
> ___
> NumPy-Discussion mailing list
> NumPy-Discussion@python.org
> https://mail.python.org/mailman/listinfo/numpy-discussion
>
>
___
NumPy-Discussion mailing list
NumPy-Discussion@python.org
https://mail.python.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] is __array_ufunc__ ready for prime-time?

[Nathan Goldbaum]

I think the biggest issues could be resolved if __array_concatenate__ were
finished. Unfortunately I don't feel like I can take that on right now.

See Ryan May's talk at scipy about using an ndarray subclass for units and
the issues he's run into:

https://www.youtube.com/watch?v=qCo9bkT9sow

On Wed, Nov 1, 2017 at 5:50 PM, Marten van Kerkwijk <
m.h.vankerkw...@gmail.com> wrote:

> From my experience with Quantity, routines that properly ducktype work
> well, those that feel the need to accept list and blatantly do
> `asarray` do not - even if in many cases they would have worked if
> they used `asanyarray`...  But there are lots of nice surprises, with,
> e.g., `np.fft.fftfreq` just working as one would hope.  Anyway, bottom
> line, I think you should let this stop you from trying only if you
> know something important does not work. -- Marten
> ___
> NumPy-Discussion mailing list
> NumPy-Discussion@python.org
> https://mail.python.org/mailman/listinfo/numpy-discussion
>
___
NumPy-Discussion mailing list
NumPy-Discussion@python.org
https://mail.python.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] is __array_ufunc__ ready for prime-time?

[Nathan Goldbaum]

I’m using it in yt. If we were able to drop support for all old numpy
versions, switching would allow me to delete hundreds of lines of code.
As-is since we need to simultaneously support old and new versions, it adds
some additional complexity. If you’re ok with only supporting numpy >=
1.13, array_ufunc will make you life a lot easier.

On Fri, Oct 27, 2017 at 6:55 PM Marten van Kerkwijk <
m.h.vankerkw...@gmail.com> wrote:

> Just to second Stephan's comment: do try it! I've moved astropy's
> Quantity over to it, and am certainly counting on the basic interface
> staying put...  -- Marten
> ___
> NumPy-Discussion mailing list
> NumPy-Discussion@python.org
> https://mail.python.org/mailman/listinfo/numpy-discussion
>
___
NumPy-Discussion mailing list
NumPy-Discussion@python.org
https://mail.python.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] numpy grant update

[Nathan Goldbaum]

My understanding of this is that the dtype will only hold the unit
metadata. So that means units would propogate through calculations
automatically, but the dtype wouldn't be able to manipulate the array data
(in an in-place unit conversion for example).

In this world, astropy quantities and yt's YTArray would become containers
around an ndarray that would make use of the dtype metadata but also
implement all of the unit semantics that they already implement. Since they
would become container classes and would no longer be ndarray subclasses,
that avoids most of the pitfalls one encounters these days.

Please correct me if I'm wrong, Nathaniel.

-Nathan

On Thu, Oct 26, 2017 at 5:14 PM, Marten van Kerkwijk <
m.h.vankerkw...@gmail.com> wrote:

> Hi Nathaniel,
>
> Thanks for the link. The plans sounds great! You'll not be surprised
> to hear I'm particularly interested in the units aspect (and, no, I
> don't mind at all if we can stop subclassing ndarray...). Is the idea
> that there will be a general way for allow a dtype to define how to
> convert an array to one with another dtype? (Just as one now
> implicitly is able to convert between, say, int and float.) And, if
> so, is the idea that one of those conversion possibilities might
> involve checking units? Or were you thinking of implementing units
> more directly? The former would seem most sensible, if only so you can
> initially focus on other things than deciding how to support, say, esu
> vs emu units, or whether or not to treat radians as equal to
> dimensionless (which they formally are, but it is not always handy to
> do so).
>
> Anyway, do keep us posted! All the best,
>
> Marten
>
> On Thu, Oct 26, 2017 at 3:40 PM, Nathaniel Smith  wrote:
> > On Wed, Oct 18, 2017 at 10:24 PM, Nathaniel Smith  wrote:
> >> I'll also be giving a lunch talk at BIDS tomorrow to let folks locally
> >> know about what's going on, which I think will be recorded – I'll send
> >> around a link after in case others are interested.
> >
> > Here's that link: https://www.youtube.com/watch?v=fowHwlpGb34
> >
> > -n
> >
> > --
> > Nathaniel J. Smith -- https://vorpus.org
> > ___
> > NumPy-Discussion mailing list
> > NumPy-Discussion@python.org
> > https://mail.python.org/mailman/listinfo/numpy-discussion
> ___
> NumPy-Discussion mailing list
> NumPy-Discussion@python.org
> https://mail.python.org/mailman/listinfo/numpy-discussion
>
___
NumPy-Discussion mailing list
NumPy-Discussion@python.org
https://mail.python.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Github overview change

[Nathan Goldbaum]

This is a change in the UI that github introduced a couple weeks ago during
their annual conference.

See https://github.com/blog/2447-a-more-connected-universe

On Wed, Oct 18, 2017 at 11:49 AM Charles R Harris 
wrote:

> On Wed, Oct 18, 2017 at 7:23 AM, Sebastian Berg <
> sebast...@sipsolutions.net> wrote:
>
>> Hi all,
>>
>> probably silly, but is anyone else annoyed at not seeing comments
>> anymore in the github overview/start page? I stopped getting everything
>> as mails and had a (bad) habit of glancing at them which would spot at
>> least bigger discussions going on, but now it only shows actual
>> commits, which honestly are less interesting to me.
>>
>> Probably just me, was just wondering if anyone knew a setting or so?
>>
>
> Don't know any settings. It's almost as annoying as not forwarding my own
> comments ...
>
> Chuck
>
> ___
> NumPy-Discussion mailing list
> NumPy-Discussion@python.org
> https://mail.python.org/mailman/listinfo/numpy-discussion
>
___
NumPy-Discussion mailing list
NumPy-Discussion@python.org
https://mail.python.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Dropping support for Accelerate

[Nathan Goldbaum]

See
https://mail.scipy.org/pipermail/numpy-discussion/2012-August/063589.html
and replies in that thread.

Quote from an Apple engineer in that thread:

"For API outside of POSIX, including GCD and technologies like Accelerate,
we do not support usage on both sides of a fork(). For this reason among
others, use of fork() without exec is discouraged in general in processes
that use layers above POSIX."

On Sun, Jul 23, 2017 at 10:16 AM, Ilhan Polat  wrote:

> That's probably because I know nothing about the issue, is there any
> reference I can read about?
>
> But in general, please feel free populate new items in the wiki page.
>
> On Sun, Jul 23, 2017 at 11:15 AM, Nathaniel Smith  wrote:
>
>> I've been wishing we'd stop shipping Accelerate for years, because of
>> how it breaks multiprocessing – that doesn't seem to be on your list
>> yet.
>>
>> On Sat, Jul 22, 2017 at 3:50 AM, Ilhan Polat 
>> wrote:
>> > A few months ago, I had the innocent intention to wrap LDLt
>> decomposition
>> > routines of LAPACK into SciPy but then I am made aware that the minimum
>> > required version of LAPACK/BLAS was due to Accelerate framework. Since
>> then
>> > I've been following the core SciPy team and others' discussion on this
>> > issue.
>> >
>> > We have been exchanging opinions for quite a while now within various
>> SciPy
>> > issues and PRs about the ever-increasing Accelerate-related issues and
>> I've
>> > compiled a brief summary about the ongoing discussions to reduce the
>> > clutter.
>> >
>> > First, I would like to kindly invite everyone to contribute and sharpen
>> the
>> > cases presented here
>> >
>> > https://github.com/scipy/scipy/wiki/Dropping-support-for-Accelerate
>> >
>> > The reason I specifically wanted to post this also in NumPy mailing
>> list is
>> > to probe for the situation from the NumPy-Accelerate perspective. Is
>> there
>> > any NumPy specific problem that would indirectly effect SciPy should the
>> > support for Accelerate is dropped?
>> >
>> >
>> >
>> >
>> > ___
>> > NumPy-Discussion mailing list
>> > NumPy-Discussion@python.org
>> > https://mail.python.org/mailman/listinfo/numpy-discussion
>> >
>>
>>
>>
>> --
>> Nathaniel J. Smith -- https://vorpus.org
>> ___
>> NumPy-Discussion mailing list
>> NumPy-Discussion@python.org
>> https://mail.python.org/mailman/listinfo/numpy-discussion
>>
>
>
> ___
> NumPy-Discussion mailing list
> NumPy-Discussion@python.org
> https://mail.python.org/mailman/listinfo/numpy-discussion
>
>
___
NumPy-Discussion mailing list
NumPy-Discussion@python.org
https://mail.python.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Controlling NumPy __mul__ method or forcing it to use __rmul__ of the "other"

[Nathan Goldbaum]

I don't think there's any real standard here. Just doing a github search
reveals many different choices people have used:

https://github.com/search?l=Python=__array_priority__=Code=%E2%9C%93

On Mon, Jun 19, 2017 at 11:07 AM, Ilhan Polat  wrote:

> Thank you. I didn't know that it existed. Is there any place where I can
> get a feeling for a sane priority number compared to what's being done in
> production? Just to make sure I'm not stepping on any toes.
>
> On Mon, Jun 19, 2017 at 5:36 PM, Stephan Hoyer  wrote:
>
>> I answered your question on StackOverflow:
>> https://stackoverflow.com/questions/40694380/forcing-multipl
>> ication-to-use-rmul-instead-of-numpy-array-mul-or-byp/44634634#44634634
>>
>> In brief, you need to set __array_priority__ or __array_ufunc__ on your
>> object.
>>
>> On Mon, Jun 19, 2017 at 5:27 AM, Ilhan Polat 
>> wrote:
>>
>>> I will assume some simple linear systems knowledge but the question can
>>> be generalized to any operator that implements __mul__ and __rmul__
>>> methods.
>>>
>>> Motivation:
>>>
>>> I am trying to implement a gain matrix, say 3x3 identity matrix, for
>>> time being with a single input single output (SISO) system that I have
>>> implemented as a class modeling a Transfer or a state space representation.
>>>
>>> In the typical usecase, suppose you would like to create an n-many
>>> parallel connections with the same LTI system sitting at each branch.
>>> MATLAB implements this as an elementwise multiplication and returning a
>>> multi input multi output(MIMO) system.
>>>
>>> G = tf(1,[1,1]);
>>> eye(3)*G
>>>
>>> produces (manually compactified)
>>>
>>> ans =
>>>
>>>   From input 1 to output...
>>>[1  ]
>>>[  --,   0   , 0]
>>>[  s + 1]
>>>[ 1 ]
>>>[  0,   -- ,   0]
>>>[   s + 1   ]
>>>[  1]
>>>[  0,   0,  --  ]
>>>[s + 1  ]
>>>
>>> Notice that the result type is of LTI system but, in our context, not a
>>> NumPy array with "object" dtype.
>>>
>>> In order to achieve a similar behavior, I would like to let the __rmul__
>>> of G take care of the multiplication. In fact, when I do
>>> G.__rmul__(np.eye(3)) I can control what the behavior should be and I
>>> receive the exception/result I've put in. However the array never looks for
>>> this method and carries out the default array __mul__ behavior.
>>>
>>> The situation is similar if we go about it as left multiplication
>>> G*eye(3) has no problems since this uses directly the __mul__ of G.
>>> Therefore we get a different result depending on the direction of
>>> multiplication.
>>>
>>> Is there anything I can do about this without forcing users subclassing
>>> or just letting them know about this particular quirk in the documentation?
>>>
>>> What I have in mind is to force the users to create static LTI objects
>>> and then multiply and reject this possibility. But then I still need to
>>> stop NumPy returning "object" dtyped array to be able to let the user know
>>> about this.
>>>
>>>
>>> Relevant links just in case
>>>
>>> the library : https://github.com/ilayn/harold/
>>>
>>> the issue discussion (monologue actually) :
>>> https://github.com/ilayn/harold/issues/7
>>>
>>> The question I've asked on SO (but with a rather offtopic answer):
>>> https://stackoverflow.com/q/40694380/4950339
>>>
>>>
>>> ilhan
>>>
>>> ___
>>> NumPy-Discussion mailing list
>>> NumPy-Discussion@python.org
>>> https://mail.python.org/mailman/listinfo/numpy-discussion
>>>
>>>
>>
>> ___
>> NumPy-Discussion mailing list
>> NumPy-Discussion@python.org
>> https://mail.python.org/mailman/listinfo/numpy-discussion
>>
>>
>
> ___
> NumPy-Discussion mailing list
> NumPy-Discussion@python.org
> https://mail.python.org/mailman/listinfo/numpy-discussion
>
>
___
NumPy-Discussion mailing list
NumPy-Discussion@python.org
https://mail.python.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] __array_ufunc__ counting down to launch, T-24 hrs.

[Nathan Goldbaum]

Thanks for linking to the updated NEP, I've been looking for a good
overview of this discussion. Up until now I haven't wanted to wade through
the extensive discussion on this topic.

I'm curious, if I want to simultaneously support older Numpy versions as
well as newer versions, will I be able to leave implementations of
__array_wrap__ and __array_prepare__ defined alongside __array_ufunc__?
Optimally in such a way that older numpy versions use __array_wrap__ and
newer versions only use __array_ufunc__.

There isn't discussion about this in the NEP, but does this also have
impacts on non-ufunc numpy operations like concatenate, dot, norm, hstack,
and others? We currently make use of wrappers around those functions in yt
but unfortunately they have poor discoverability for users, it would be
nice if NumPy could do the right thing with nearest subclasses.

On Fri, Mar 31, 2017 at 12:04 PM Marten van Kerkwijk <
m.h.vankerkw...@gmail.com> wrote:

> Hi All,
>
> Following Nathaniel's request, I have made a PR that changes the
> original NEP to describe the current implementation.
> * PR at https://github.com/charris/numpy/pull/9
> * Rendered relevant page at
> http://www.astro.utoronto.ca/~mhvk/numpy-doc/neps/ufunc-overrides.html
> It may still be somewhat short on detail, but should now give the
> rationale for what we want to implement.
>
> All the best,
>
> Marten
> ___
> NumPy-Discussion mailing list
> NumPy-Discussion@python.org
> https://mail.python.org/mailman/listinfo/numpy-discussion
>
___
NumPy-Discussion mailing list
NumPy-Discussion@python.org
https://mail.python.org/mailman/listinfo/numpy-discussion