How would this proposed function compare to using the modulo operator, like
'arr % (2*pi)'?
On Mon, Nov 23, 2020, 16:13 Thomas wrote:
> Hi,
>
> I have a proposal for a feature and I hope this is the right place to post
> this.
>
> The idea is to have a function to map any input angle to the rang
Off the cuff, my intuition is that dtypes will want to be able to
define how scalar indexing works, and let it return objects other than
arrays. So e.g.:
- some dtypes might just return a zero-d array
- some dtypes might want to return some arbitrary domain-appropriate
type, like a datetime dtype
Pretty sure the 2010 and 2014 images both have much newer compilers than
that.
There are still a lot of users on CentOS 6, so I'd still stick to 2010 for
now on x86_64 at least. We could potentially start adding 2014 wheels for
the other platforms where we currently don't ship wheels – gotta be be
It is pretty weird that these two statements don't necessarily produce the
same result:
someufunc(*inputs, out=out_arr)
out_arr[...] = someufunc(*inputs)
On Fri, Sep 27, 2019, 15:02 Sebastian Berg
wrote:
> On Fri, 2019-09-27 at 11:50 -0700, Sebastian Berg wrote:
> > Hi all,
> >
> > Looking at t
On Sun, Sep 8, 2019 at 8:40 AM Ralf Gommers wrote:
>
>
>
> On Sun, Sep 8, 2019 at 12:54 AM 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 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
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
On Sat, Sep 7, 2019 at 5:08 PM Ralf Gommers wrote:
>
> On Sat, Sep 7, 2019 at 4:16 PM Nathaniel Smith wrote:
>>
>> On Fri, Sep 6, 2019 at 11:04 PM Ralf Gommers wrote:
>> > Vendoring means "include the code". So no dependency on an external
>> >
On Fri, Sep 6, 2019 at 11:04 PM Ralf Gommers wrote:
> Vendoring means "include the code". So no dependency on an external package.
> If we don't vendor, it's going to be either unused, or end up as a dependency
> for the whole SciPy/PyData stack.
If we vendor it then it also ends up as a depen
On Fri, Sep 6, 2019 at 11:44 AM Ralf Gommers wrote:
>
>
>
> On Fri, Sep 6, 2019 at 1:32 AM Hameer Abbasi
> wrote:
>>
>> That's a lot of very good questions! Let me see if I can answer them
>> one-by-one.
>>
>> On 06.09.19 09:49, Nathaniel Smit
On Fri, Sep 6, 2019 at 2:45 PM Ralf Gommers wrote:
> There may be another very concrete one (that's not yet in the NEP): allowing
> other libraries that consume ndarrays to use overrides. An example is
> numpy.fft: currently both mkl_fft and pyfftw monkeypatch NumPy, something we
> don't like a
On Mon, Sep 2, 2019 at 11:21 PM Ralf Gommers wrote:
> On Mon, Sep 2, 2019 at 2:09 PM Nathaniel Smith wrote:
>> The reason this is challenging is that there's a lot of code written
>> in Cython/C/C++ that calls np.asarray,
>
> Cython code only perhaps? It would surprise
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 in the form of a PR, [1]
Thanks for putting this together!
AFAICT all these services work by creating branches inside your repo and
then making a PR from that – they don't make their own forks. (Which makes
some sense when you consider they would need tens of thousands of forked
epos for all the projects they work with.)
I don't think there's any need to
On Wed, Jun 12, 2019 at 12:58 PM Marten van Kerkwijk
wrote:
>
> Overall, in favour of splitting the large files, but I don't like that the
> notes stop being under version control (e.g., a follow-up PR slightly changes
> things, how does the note gets edited/reverted?).
>
> Has there been any di
It might be worth considering a tool like 'towncrier'. It's automation to
support the workflow where PRs that make changes also include their release
notes, so when the release comes you've already done all the work and just
have to hit the button.
On Wed, Jun 12, 2019, 07:59 Sebastian Berg
wrote
I haven't read all the thread super carefully, so I might have missed
something, but I think we might want to look at this together with the
special rule for scalar casting.
IIUC, the basic end-user problem that motivates all thi sis: when you
have a simple Python constant whose exact dtype is uns
On Sat, Jun 1, 2019 at 11:59 PM Ralf Gommers wrote:
> On Sun, Jun 2, 2019 at 12:35 AM Nathaniel Smith wrote:
>>
>> On Sat, Jun 1, 2019 at 1:05 PM Ralf Gommers wrote:
>> > I think this is potentially useful, but *far* more prescriptive and
>> > detailed
On Sat, Jun 1, 2019 at 1:05 PM Ralf Gommers wrote:
> I think this is potentially useful, but *far* more prescriptive and detailed
> than I had in mind. Both you and Nathaniel seem to have not understood what I
> mean by "out of scope", so I think that's my fault in not being explicit
> enough.
On Sat, Jun 1, 2019, 09:13 Ralf Gommers wrote:
>
>
> On Sat, Jun 1, 2019 at 11:32 AM Nathaniel Smith wrote:
>
>> It's possible I'm not getting what you're thinking, but from what you
>> describe in your email I think it's a bad idea.
>>
>
&g
On Sat, Jun 1, 2019, 05:23 Hameer Abbasi wrote:
> I think this hits the crux of the issue... There *is* a huge coordination
> problem. Users want to move their code from NumPy to Sparse or Dask all the
> time, but it’s not trivial to do. And libraries like sparse and Dask want
> to follow a stand
It's possible I'm not getting what you're thinking, but from what you
describe in your email I think it's a bad idea.
Standards take a tremendous amount of work (no really, an absurdly
massively huge amount of work, more than you can imagine if you
haven't done it). And they don't do what people u
On Mon, May 13, 2019, 10:26 Charles R Harris
wrote:
> I just checked that current wheels show the warnings when `numpy.test()`
> is run with latest pytest. However, moving the `pytest.ini` file into the
> `numpy` directory is tricky, as we need to tell pytest where to find the
> installed file (
On Sun, Apr 28, 2019 at 1:38 PM Marten van Kerkwijk
wrote:
>
> Hi Nathaniel,
>
> I'm a bit confused why` np.concatenate([1, 2], [3, 4])` would be a problem.
> In the current model, all (numpy) functions fall back to
> `ndarray.__array_function__`, which does know what to do with anything that
>
On Sun, Apr 28, 2019, 02:22 Ralf Gommers wrote:
> One other thought: the proposal in this thread is about skipping the
> override mechanism for numpy functions. NEP 18 reserves the freedom to swap
> out __array_function__ with __array_ufunc__ if we make something a ufunc.
> So __skipping_array_fu
On Sun, Apr 28, 2019, 08:41 Marten van Kerkwijk
wrote:
> Hi Ralf,
>
> Thanks for the comments and summary slides. I think you're
> over-interpreting my wish to break people's code! I certainly believe - and
> think we all agree - that we remain as committed as ever to ensure that
> ```
> np.funct
On Sat, Apr 27, 2019 at 7:46 PM Stephan Hoyer wrote:
> Worst, "__wrapped__" would be difficult to search for, because it already
> means something in Python (referring to functools.wrapped). At least
> "__numpy_implementation__" and "__skipping_array_function__" are both unique
> tokens without
On Sat, Apr 27, 2019 at 4:38 PM Hameer Abbasi
wrote:
> Of course, here’s my proposal:
>
> We leave NEP-18 as-is for now, and instead of writing separate protocols
> for coercion, dtypes and ufuncs (which will be needed somewhere down the
> line), we have a discussion about uarray and see if it ca
On Thu, Apr 25, 2019 at 1:30 PM Hameer Abbasi wrote:
> Although, in general, I agree with Stephan’s design goals, I agree with
> Marten that the number of protocols are getting larger and may get out of
> hand if not handled properly. There’s even one Marten forgot to mention:
> __array_dtype__
On Thu, Apr 25, 2019 at 10:10 AM Stephan Hoyer wrote:
>
> On Wed, Apr 24, 2019 at 9:56 PM Nathaniel Smith wrote:
>>
>> When you say "numpy array specific" and
>> "__numpy_(nd)array_implementation__", that sounds to me like you're
>> trying
On Wed, Apr 24, 2019 at 9:45 PM Stephan Hoyer wrote:
> With "__numpy_implementation__" I was hoping to evoke "the implementation
> used by numpy.ndarray.__array_function__" and "the implementation for NumPy
> arrays" rather than "the implementation found in the NumPy library." So it
> would sti
On Mon, Apr 22, 2019 at 11:13 PM Stephan Hoyer wrote:
>
>> On Mon, Apr 22, 2019 at 9:26 PM Nathaniel Smith wrote:
>>>
>>> Your last email didn't really clarify anything for me. I get that
>>> np.func.__numpy_implementation__ is intended to have the se
Your last email didn't really clarify anything for me. I get that
np.func.__numpy_implementation__ is intended to have the semantics of
numpy's implementation of func, but that doesn't tell me much :-). And
also, that's exactly the definition of np.func, isn't it?
You're talking about ~doubling th
On Mon, Apr 15, 2019 at 4:39 PM Stephan Hoyer wrote:
>
> On Mon, Apr 15, 2019 at 1:21 PM Nathaniel Smith wrote:
>>
>> What's the difference between
>>
>> np.concatenate.__numpy_implementation__(...)
>>
>> and
>>
>> np.ndarray.__array
What's the difference between
np.concatenate.__numpy_implementation__(...)
and
np.ndarray.__array_function__(np.concatenate, ...)
?
More generally, I guess I'm not quite clear on how to think about what the
"no dispatch" version does, because obviously it doesn't make sense to have
*no* dispat
My concern would be that to implement (2), I think .copy() has to
either special-case certain dtypes, or else we have to add some kind
of "simplify for copy" operation to the dtype protocol. These both add
architectural complexity, so maybe it's better to avoid it unless we
have a compelling reason
Yeah, the libgfortran dependency is expected. The question is why this
should cause any problems. The wheel building infrastructure goes to great
lengths to make sure that the dynamic libraries in the wheels shouldn't
interfere with other packages. The original complaint in this thread is
very vagu
Hi all,
As part of our relationship with NumFOCUS, we have to have some liasons so
they know who to contact etc. So far that's been Ralf and me. But, I
haven't had as much time for numpy recently, and I think it would be better
to hand this off to someone who's more active. Is anyone interested?
S
This is a pretty good article on what -fno-strict-aliasing actually does:
https://blog.regehr.org/archives/1307
-n
On Fri, Jan 4, 2019, 09:36 Charles R Harris Hi All,
>
> Just asking if the `-fno-strict-aliasing` flag is still required for gcc.
> Supposedly `-fstrict-aliasing` is enabled by defa
On Thu, Dec 27, 2018 at 3:27 PM Juan Nunez-Iglesias wrote:
>
> On Fri, Dec 28, 2018, at 3:40 AM, Sebastian Berg wrote:
>
> > It’s consistent with np.newaxis in spelling (modulo the _)
> > If mistyped, it can be caught easily by IDEs.
> > It’s typeable with mypy, unlike constant string literals whi
On Fri, Nov 9, 2018 at 4:59 PM, Stephan Hoyer wrote:
> On Fri, Nov 9, 2018 at 6:46 PM Nathaniel Smith wrote:
>>
>> But matrix isn't the only problem with asanyarray. np.ma also violates
>> Liskov. No doubt there are other problematic ndarray subclasses out
>> ther
But matrix isn't the only problem with asanyarray. np.ma also violates
Liskov. No doubt there are other problematic ndarray subclasses out
there too...
If we were going to try to reuse asanyarray through some deprecation
mechanism, I think we'd need to deprecate allowing asanyarray to
return *any*
On Wed, Sep 5, 2018 at 4:37 PM, David Grote wrote:
>
> Hi - I have recently come across this problem. On my mac, I build a Fortran
> code, producing a shared object, that I import into Python along with numpy.
> This had been working fine until recently when I started seeing sag faults
> deep insi
It's probably helpful to know that Py_LIMITED_API is a
kinda-experimental thing that was added in CPython 3.2 (see PEP 384)
and remains almost 100% unused. It has never been a popular or
influential thing (for better or worse).
-n
On Tue, Oct 30, 2018 at 6:41 PM, Eric Wieser
wrote:
> In NumPy 1.
On Fri, Oct 19, 2018 at 6:23 PM, Marten van Kerkwijk
wrote:
> Hi All,
>
> It seems there are two extreme possibilities for general functions:
> 1. Put `asarray` everywhere. The main benefit that I can see is that even if
> people put in list instead of arrays, one is guaranteed to have shape,
> dt
On Fri, Oct 19, 2018 at 7:00 PM, Charles R Harris
wrote:
>
> On Fri, Oct 19, 2018 at 7:50 PM Eric Wieser
> wrote:
>>
>> Subclasses such as MaskedArray and, yes, Quantity, are widely used, and if
>> they cause problems perhaps that should be seen as a sign that ndarray
>> subclassing should be mad
On Fri, Oct 19, 2018 at 3:28 PM, Ralf Gommers
wrote:
>
>
> On Fri, Oct 19, 2018 at 4:15 PM Hameer Abbasi
> wrote:
>
>> Hi!
>>
>> On Friday, Oct 19, 2018 at 6:09 PM, Stephan Hoyer
>> wrote:
>> I don't think it makes much sense to change NumPy's existing usage of
>> asarray() to asanyarray() unle
On Thu, Sep 13, 2018 at 10:30 AM, Stephan Hoyer wrote:
> I have now drafted these revisions to the NEP to clarify its stance around
> backwards compatibility, and the type of the "types" argument:
> https://github.com/numpy/numpy/pull/11943
Okay, so this is a pretty substantial change! Before, th
On Tue, Sep 18, 2018 at 6:04 PM, Stefan van der Walt
wrote:
> On Tue, 18 Sep 2018 16:54:16 -0500, Andy Ray Terrel wrote:
>> FYI, Donald Fischer will be at the NumFOCUS forum next week if folks want
>> to talk to him about it. It looks like individuals sign up with Tidelift
>> and perform services
On Fri, Sep 7, 2018 at 6:33 PM, Charles R Harris
wrote:
> Thanks for the link. It would be nice to improve the Windows numbers, Linux
> is still very dominant. I suppose that might be an artifact of the systems
> used by developers as opposed to end users. It would be a different open
> source wor
On Fri, Sep 7, 2018 at 1:19 AM, Hans Dembinski wrote:
>
>> On 7. Sep 2018, at 06:33, Nathaniel Smith wrote:
>>
>> Looking at https://pypistats.org/packages/numpy , it appears that
>> August 24 was the last day when numpy had more Python 2 downloads than
>&g
Looking at https://pypistats.org/packages/numpy , it appears that
August 24 was the last day when numpy had more Python 2 downloads than
Python 3 downloads (maybe ever?).
-n
--
Nathaniel J. Smith -- https://vorpus.org
___
NumPy-Discussion mailing list
jsmith/1056379 (authors Matthew Brett, Nathaniel
> Smith),
> 2. https://gist.github.com/njsmith/1068264 (author Nathaniel Smith),
> as well as another summary:
> https://github.com/njsmith/numpy/wiki/NA-discussion-status
>
> I'd like to see the NEPs rescued, and the summary
On Wed, Aug 29, 2018, 02: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 __arra
On Fri, Aug 24, 2018 at 4:00 PM, Stephan Hoyer wrote:
> On Fri, Aug 24, 2018 at 3:14 PM Nathaniel Smith wrote:
>>
>> Yeah, the reason warnings are normally recommended is because
>> normally, you want to make it easy to silence. But this is the rare
>> case where I did
On Fri, Aug 24, 2018 at 1:46 PM, Stephan Hoyer wrote:
> On Fri, Aug 24, 2018 at 1:36 AM Hameer Abbasi
> wrote:
>>
>>
>> On Fri, Aug 24, 2018 at 9:38 AM Nathaniel Smith wrote:
>>>
>>> On Thu, Aug 23, 2018 at 9:02 AM, wrote:
>>> > I might a
On Fri, Aug 24, 2018, 09:07 Hameer Abbasi wrote:
>
>
> 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 an
On Thu, Aug 23, 2018 at 9:02 AM, wrote:
> I might add that most duck array authors are highly unlikely to be newcomers
> to the Python space. We should just put a big warning there while enabling
> and that’ll be enough to scare away most devs from doing it by default.
That's a reasonable idea..
On Tue, Aug 21, 2018 at 6:12 PM, Stephan Hoyer wrote:
> On Tue, Aug 21, 2018 at 12:21 AM Nathaniel Smith wrote:
>>
>> >> My suggestion: at numpy import time, check for an envvar, like say
>> >> NUMPY_EXPERIMENTAL_ARRAY_FUNCTION=1. If it's not set, then all t
On Tue, Aug 21, 2018 at 9:39 AM, Stephan Hoyer wrote:
> On Tue, Aug 21, 2018 at 12:21 AM Nathaniel Smith wrote:
>>
>> On Wed, Aug 15, 2018 at 9:45 AM, Stephan Hoyer wrote:
>> > This avoids a classic subclassing problem that has plagued NumPy for
>> > years,
>
On Wed, Aug 15, 2018 at 9:45 AM, Stephan Hoyer wrote:
> RE: accidental differences in behavior:
>
> I actually think that the __array_function__ approach is *less* prone to
> accidental differences in behavior, because we require implementing every
> function directly (or it raises an error).
>
>
On Mon, Aug 13, 2018 at 2:44 AM, Nathaniel Smith wrote:
> So this is like... an extreme version of technical debt. You're making
> a deal with the devil for wealth and fame, and then eventually the
> bill becomes due. It's hard for me to say categorically that this is a
>
Hey all,
So I've finally read through NEP 18 (__array_function__). Sorry again
for the delay!
It's an impressive piece of work! Thanks to the many authors; there's
clearly been a lot of thought put into this.
# The trade-off between comprehensive APIs versus clean APIs
At a high-level, what mak
I'm sorry, I've been trying to find the time to read what you ended up
with, and haven't managed yet – could I get a few days extension? :-)
-n
On Wed, Aug 1, 2018 at 5:27 PM, Stephan Hoyer wrote:
> I propose to accept NEP-18, "A dispatch mechanism for NumPy’s high level
> array functions":
> ht
On Wed, Aug 1, 2018 at 10:04 PM, Robert Kern wrote:
> A CoC has to pull a kind of double
> duty: be friendly enough to digest for a newcomer and also be helpful to
> project organizers to make tough balancing decisions. We don't have to
> expect each sentence to pull that double duty on its own. I
On Thu, Aug 2, 2018 at 10:07 AM, Antoine Pitrou wrote:
> What if someone is wearing a religious symbol?
>
> If one is concerned about horrible beliefs or opinions, there are a
> good deal of them in many religious ("holy") books (*), yet CoCs are
> generally meant to prohibit discrimination based
On Wed, Aug 1, 2018 at 8:34 PM, Ryan May wrote:
> So I hear all the arguments about people feeling unsafe due to some truly
> despicable, discriminatory behavior, and I want absolutely no parts of
> protecting that. However, I also recognize that we in the U.S. are in a
> particularly divisive atm
On Wed, Aug 1, 2018 at 8:37 AM, Ralf Gommers wrote:
>
> On Wed, Aug 1, 2018 at 8:12 AM, Nathan Goldbaum
> wrote:
>>
>> 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
On Sun, Jul 22, 2018 at 12:28 PM, Ralf Gommers wrote:
> On Sat, Jul 21, 2018 at 7:15 PM, Nathaniel Smith wrote:
>> Speaking of examples: I hate to say this because in general I think
>> using examples is a great idea. But... I think you should delete most
>> of these exa
On Sat, Jul 21, 2018 at 5:46 PM, Hameer Abbasi
wrote:
> The possibility of another major version change (possibly the same one)
> where we re-write all portions that were agreed upon (via NEPs) to be
> re-written, with a longer LTS release (3 years? 5?).
>
> I’m thinking this one could be similar
On Sat, Jul 21, 2018 at 4:48 PM, Ralf Gommers wrote:
> Hi all,
>
> Here is a first draft of a NEP on backwards compatibility and deprecation
> policy. This I think mostly formalized what we've done for the last couple
> of years, however I'm sure opinions and wish lists will differ here.
Oh *awes
A few quick things that jumped out at me:
- I think the discussion of __array_ufunc__ on dtypes is confused.
Dtypes already have a generic mechanism for overriding ufuncs (the
ufunc loop dispatch mechanism), it's separate from __array_ufunc__ (so
in theory you could e.g. have a user-defined array
On Tue, Jul 3, 2018, 05:01 Tom Cook wrote:
> I have a remote sensing platform that uses Numpy on a raspberry pi. There
> are about a dozen of these installed. Three days ago, the Python part of
> the software started crashing during startup, with this exception message:
>
> Traceback (most rece
Hi all,
Here's a NEP that Stephan and I wrote (actually a few months ago, but
then I was super slow, thank you Stephan for your patience). It tries
to lay out a high-level overview of where we're trying to go with all
this duck array stuff, and some general guidelines that we've
gradually come aro
On Sat, Jun 30, 2018 at 6:51 AM, Marten van Kerkwijk
wrote:
> Hi All,
>
> In case it was missed because people have tuned out of the thread: Matti and
> I proposed last Tuesday to accept NEP 20 (on coming Tuesday, as per NEP 0),
> which introduces notation for generalized ufuncs allowing fixed, fl
On Fri, Jun 29, 2018 at 3:28 PM, Marten van Kerkwijk
wrote:
> Agreed on accepting the NEP! But it is not the first proposal to accept
> under the new rules - that goes to the broadcasting NEP (though perhaps I
> wasn't sufficiently explicit in stating that I was starting a
> count-down...). -- Mar
un 29, 2018 at 3:18 PM, Nathaniel Smith wrote:
> Hi all,
>
> I propose that we accept NEP 15: Merging multiarray and umath:
>
> http://www.numpy.org/neps/nep-0015-merge-multiarray-umath.html
>
> The core part of this proposal was uncontroversial. The main point of
> discus
Hi all,
I propose that we accept NEP 15: Merging multiarray and umath:
http://www.numpy.org/neps/nep-0015-merge-multiarray-umath.html
The core part of this proposal was uncontroversial. The main point of
discussion was whether it was OK to deprecate set_numeric_ops, or
whether it had some legiti
On Sun, Jun 10, 2018 at 11:53 PM, Ralf Gommers wrote:
>
> On Sun, Jun 10, 2018 at 11:15 PM, Robert Kern wrote:
>>
>> The intention of this code is to shuffle two same-length sequences in the
>> same way. So now if I write my code well to call np.random.seed() once at
>> the start of my program, t
On Thu, May 31, 2018 at 4:20 AM, Marten van Kerkwijk
wrote:
> Hi Nathaniel,
>
> I think the case for frozen dimensions is much more solid that just
> `cross1d` - there are many operations that work on size-3 vectors.
> Indeed, as I noted in the PR, I have just been wrapping a
> Standards-of-Astron
On Wed, May 30, 2018 at 11:14 AM, Marten van Kerkwijk
wrote:
> Hi All,
>
> Following on a PR combining the ability to provide fixed and flexible
> dimensions [1] (useful for, e.g., 3-vector input with a signature like
> `(3),(3)->(3)`, and for `matmul`, resp.; based on earlier PRs by Jaime
> [2] a
On Mon, May 28, 2018, 20:41 Stephan Hoyer wrote:
> On Mon, May 28, 2018 at 7:36 PM Eric Wieser
> wrote:
>
>> which ensure that it is still well defined (as the identity) on 1d
>> arrays.
>>
>> This strikes me as a bad idea. There’s already enough confusion from
>> beginners that array_1d.T is a
On Mon, May 28, 2018 at 4:26 PM, Stephan Hoyer wrote:
> On Mon, May 21, 2018 at 5:42 PM Matti Picus wrote:
>>
>> - create a wrapper that can convince the ufunc mechanism to call
>> __array_ufunc__ even on functions that are not true ufuncs
>
>
> I am somewhat opposed to this approach, because __a
Performance is an incredibly multi-dimensional thing. Modern computers are
incredibly complex, with layers of interacting caches, different
microarchitectural features (do you have AVX2? does your cpu's branch
predictor interact in a funny way with your workload?), compiler
optimizations that vary
I would like to see a plan for how we're going to handle zeroes_like,
empty_like, ones_like, and full_like before we start making changes to any
of them.
On Fri, May 18, 2018, 05:33 Matthew Rocklin wrote:
> Hi All,
>
> I would like to see the numpy.ones_like function operate as a ufunc.
> This i
On Mon, Mar 26, 2018 at 6:24 PM, Nathaniel Smith wrote:
> Even knowing that, it's still confusing that round(np.float64(0.0))
> isn't the same as round(0.0). The reason is a Python 2 / Python 3
> thing: in Python 2, round returns a float, while on Python 3, it
> returns
Even knowing that, it's still confusing that round(np.float64(0.0))
isn't the same as round(0.0). The reason is a Python 2 / Python 3
thing: in Python 2, round returns a float, while on Python 3, it
returns an integer – but numpy still uses the python 2 behavior
everywhere.
I'm not sure if it's po
On Sat, Mar 10, 2018 at 4:27 AM, Matthew Rocklin wrote:
> I'm very glad to see this discussion.
>
> I think that coming up with a single definition of array-like may be
> difficult, and that we might end up wanting to embrace duck typing instead.
>
> It seems to me that different array-like classe
s passed to the individual
> histogram invocations. Does matplotlib handle that correctly for stacked
> histograms?
>
> On Thu, Mar 15, 2018, 20:14 Nathaniel Smith wrote:
>
>> Instead of an nobs argument, maybe we should have a version that accepts
>> multiple data sets, so that w
Instead of an nobs argument, maybe we should have a version that accepts
multiple data sets, so that we have the full information and can improve
the algorithm over time.
On Mar 15, 2018 7:57 PM, "Thomas Caswell" wrote:
> Yes I like the name.
>
> The primary use-case for Matplotlib is that our `
On Mar 12, 2018 12:02, "Charles R Harris" wrote:
If we accept this NEP, I'd like to get it done soon, preferably and the
next few months, so that it is finished before we drop Python 2.7 support.
That will make maintenance of the NumPy long term support release through
2019 easier.
The reason
On Thu, Mar 8, 2018 at 5:51 PM, Juan Nunez-Iglesias wrote:
>> Finally for the name, what about `asduckarray`? Thought perhaps that could
>> be a source of confusion, and given the gradation of duck array like types.
>
> I suggest that the name should *not* use programmer lingo, so neither
> "abstr
On Fri, Mar 9, 2018 at 3:33 AM, Julian Taylor
wrote:
> As the functions of the different libraries have vastly different
> accuracies you want to be able to exchange numeric ops at runtime or at
> least during load time (like our cblas) and not limit yourself one
> compile time defined set of func
On Fri, Mar 9, 2018 at 11:51 AM, Stefan van der Walt
wrote:
> On Fri, 09 Mar 2018 17:00:43 +, Stephan Hoyer wrote:
>> I'll note that we basically used GitHub for revising __array_ufunc__ NEP,
>> and I think that worked out better for everyone involved. The discussion
>> was a little too specia
On Thu, Mar 8, 2018 at 9:45 PM, Stephan Hoyer wrote:
> On Thu, Mar 8, 2018 at 5:54 PM Juan Nunez-Iglesias
> wrote:
>>
>> On Fri, Mar 9, 2018, at 5:56 AM, Stephan Hoyer wrote:
>>
>> Marten's case 1: works exactly like ndarray, but stores data differently:
>> parallel arrays (e.g., dask.array), spa
On Thu, Mar 8, 2018 at 7:06 AM, Marten van Kerkwijk
wrote:
> A larger comment: you state that you think `np.asanyarray` is a
> mistake since `np.matrix` and `np.ma.MaskedArray` would pass through
> and that those do not strictly mimic `NDArray`. Here, I agree with
> `matrix` (but since we're depre
On Thu, Mar 8, 2018 at 10:26 PM, Ralf Gommers wrote:
>
>
> On Thu, Mar 8, 2018 at 8:22 PM, Nathaniel Smith wrote:
>>
>> On Thu, Mar 8, 2018 at 7:06 AM, Marten van Kerkwijk
>> wrote:
>> > Hi Nathaniel,
>> >
>> > Overall, hugely in favour!
On Thu, Mar 8, 2018 at 7:06 AM, Marten van Kerkwijk
wrote:
> Hi Nathaniel,
>
> Overall, hugely in favour! For detailed comments, it would be good to
> have a link to a PR; could you put that up?
Well, there's a PR here: https://github.com/numpy/numpy/pull/10706
But, this raises a question :-).
On Thu, Mar 8, 2018 at 1:52 AM, Gregor Thalhammer
wrote:
>
> Hi,
>
> long time ago I wrote a wrapper to to use optimised and parallelized math
> functions from Intels vector math library
> geggo/uvml: Provide vectorized math function (MKL) for numpy
>
> I found it useful to inject (some of) the fa
Hi all,
Here's a more substantive NEP: trying to define how to define a
standard way for functions to say that they can accept any "duck
array".
Biggest open question for me: the name "asabstractarray" kinda sucks
(for reasons described in the NEP), and I'd love to have something
better. Any idea
1 - 100 of 174 matches
Mail list logo