Re: [Numpy-discussion] Convolution of NumPy arrays of arbitrary dimension
> On 11. Aug 2018, at 00:24, Foad Sojoodi Farimani > wrote: > > Hello everyone, > > My first email here, so sorry in advance if I'm violating any rules. > I'm trying to implement the convolution of NumPy arrays of arbitrary > dimension in order to get Cauchy product of multivariate power series. > However I have some issues. I was wondering maybe you can help and this might > also be of your interest. I have explained everything here in this > StackOverflow post: > > http://bit.ly/2MhJCex > > I would appreciate if you could help me figure this out. Thanks in advance. > > Best, > Foad > ___ > NumPy-Discussion mailing list > NumPy-Discussion@python.org > https://mail.python.org/mailman/listinfo/numpy-discussion Hi Foad, you can use scipy.signal.convolve. It works on N-D arrays. Best Regards Hameer Abbasi Sent from my iPhone___ 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
I’m +0 on removing it, so mostly neutral, but slightly in favour. While I see the argument for having it, I also see it as a violation of DRY... The information is already available in relevant arguments. I doubt any people implementing this protocol are going to be lazy enough not to implement a type check. So far, we’ve been good on __array_ufunc__. The part of me that says it’s good to have it is the mostly “squeeze every bit of performance out” part. Best Regards Hameer Abbasi Sent from my iPhone > On 21. Aug 2018, at 10:34, Marten van Kerkwijk > wrote: > > >> >> I don't really understand the 'types' frozenset. The NEP says "it will >> >> be used by most __array_function__ methods, which otherwise would need >> >> to extract this information themselves"... but they still need to >> >> extract the information themselves, because they still have to examine >> >> each object and figure out what type it is. And, simply creating a >> >> frozenset costs ~0.2 µs on my laptop, which is overhead that we can't >> >> possibly optimize later... >> > >> > >> > The most flexible alternative would be to just say that we provide an >> > fixed-length iterable, and return a tuple object. (In my microbenchmarks, >> > it's faster to make a tuple than a list or set.) In an early draft of the >> > NEP, I proposed exactly this, but the speed difference seemed really >> > marginal to me. >> > >> > I included 'types' in the interface because I really do think it's >> > something >> > that almost all __array_function__ implementations should use use. It >> > preserves a nice separation of concerns between dispatching logic and >> > implementations for a new type. At least as long as __array_function__ is >> > experimental, I don't think we should be encouraging people to write >> > functions that could return NotImplemented directly and to rely entirely on >> > the NumPy interface. >> > >> > Many but not all implementations will need to look at argument types. This >> > is only really essential for cases where mixed operations between NumPy >> > arrays and another type are allowed. If you only implement the NumPy >> > interface for MyArray objects, then in the usual Python style you wouldn't >> > need isinstance checks. >> > >> > It's also important from an ecosystem perspective. If we don't make it easy >> > to get type information, my guess is that many __array_function__ authors >> > wouldn't bother to return NotImplemented for unexpected types, which means >> > that __array_function__ will break in weird ways when used with objects >> > from >> > unrelated libraries. >> >> 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. (Especially >> since if we keep things really-provisional, we can change our mind >> about the argument later :-).) Mostly I'm just confused, because there >> are lots of __dunder__ functions in Python (and NumPy), and none of >> them take a special 'types' argument... so what's special about >> __array_function__ that makes it necessary/worthwhile? >> >> Any implementation of, say, concatenate-via-array_function is going to >> involve iterating through all the arguments and looking at each of >> them to figure out what kind of object it is and how to handle it, >> right? That's true whether or not they've done a "pre-check" using the >> types set, so in theory it's just as easy to return NotImplemented at >> that point. But I guess your point in the last paragraph is that this >> means there will be lots of chances to mess up the >> NotImplemented-returning code in particular, especially since it's >> less likely to be tested than the happy path, which seems plausible. >> So basically the point of the types set is to let people factor out >> that little bit of lots of functions into one common place? I guess >> some careful devs might be unhappy with paying extra so that other >> lazier devs can get away with being lazy, but maybe it's a good >> tradeoff for us (esp. since as numpy devs, we'll be getting the bug >> reports regardless :-)). >> >> If that's the goal, then it does make me wonder if there might be a >> more direct way to accomplish it -- like, should we let classes define >> an __array_function_types__ attribute that numpy would check before >> even trying to dispatch to __array_function__? >> > I quite like that idea; I've not been enchanted by the extra `types` either - > it seems like `method` in `__array_ufunc__`, it could become quite > superfluous. > > -- 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] Proposal to accept NEP-18, __array_function__ protocol
Hi everyone, > On 23. Aug 2018, at 17:35, Stephan Hoyer wrote: > >> On Tue, Aug 21, 2018 at 6:57 PM Nathaniel Smith wrote: >> I mean, the idea of the envvar is to be a temporary measure enable >> devs to experiment with a provisional feature, while being awkward >> enough that people don't build lots of stuff assuming its there. It >> doesn't have to 100% supported in every environment. > > My understanding of the idea of the envvar is to obtain informed consent from > NumPy users, e.g., "I understand that this is a unsupported experimental > feature that may be removed in the future without warning." > > It's pretty important for me personally that's it's possible to use this in a > flexible set of environments, and in particular to have something that works > in my preferred notebook environment. How else are we going to test this? > > Every limitation that we put into the experimental version of this feature > decreases the likelihood that it gets used enough to know if it's even a > viable solution. If it's too awkward, nobody's even going to bother testing > it, and this whole effort will fall flat on its face. > >> > I'm in complete agreement that only authors of end-user applications should >> > invoke this option, but just because something is technically possible >> > doesn't mean that people will actually do it or that we need to support >> > that >> > use case :). >> >> I didn't say "authors of end-user applications", I said "end-users" :-). > > These are mostly the same for NumPy, but I do disagree with you here. > Ultimately we have to trust application developers to make the right choices > for their tools. If they are willing to accept that maintenance burden of > either (1) potentially being stuck on NumPy 1.16 forever or (2) needing to > rewrite their code, that's their tradeoff to make. It's a little preposterous > to force this decision onto end-users, who may not even know a tool is > written in NumPy. > >> That said, I dunno. My intuition is that if we have a function call >> like this then libraries that define __array_function__ will merrily >> call it in their package __init__ and it accomplishes nothing, but >> maybe I'm being too cynical and untrusting. > > People can do lots of dumb things in Python (e.g., monkeypatching) -- the > language doesn't stop them. Fortunately this mostly isn't a problem. 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. > ___ > NumPy-Discussion mailing list > NumPy-Discussion@python.org > https://mail.python.org/mailman/listinfo/numpy-discussion Best Regards, Hameer Abbasi Sent from my iPhone___ 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
> I’m On 25. Aug 2018, at 00:13, Nathaniel Smith wrote: > >> 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 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... a Big Obnoxious Warning(tm) when it's enabled, or on first use, would achieve a lot of the same purpose. E.g. if this_is_the_first_array_function_usage(): sys.stderr.write( "WARNING: this program uses NumPy's experimental '__array_function__' feature.\n" "It may change or be removed without warning, which might break this program.\n" "For details see http://www.numpy.org/neps/nep-0018-array-function-protocol.html\n"; ) -n >>> >>> I was thinking of a FutureWarning... That's essentially what it's for. >>> Writing to stderr looks un-pythonic to me. >> >> >> Issuing a FutureWarning seems roughly appropriate here. The Python 3.7 docs >> write: >> "Base category for warnings about deprecated features when those warnings >> are intended for end users of applications that are written in Python." >> >> Writing to sys.stderr directly is generally considered poor practice for a >> Python libraries. >> >> In my experience FutureWarning does a good job of satisfying the goals of >> being a "Big Obnoxious Warning" while still being silence-able and testable >> with standard tools. > > 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 didn't want to make it easy to silence, so I didn't > suggest using a warning :-). I really doubt anyone is going to silence a FutureWarning and then come complaining that a feature was removed. > > Calling warnings.warn (or the C equivalent) is also very expensive, > even if the warning ultimately isn't displayed. I guess we could do > our own tracking of whether we've displayed the warning yet, and only > even attempt to issue it once, but that partially defeats the purpose > of using warnings in the first place. How about calling it at enable-time once? That’s why I suggested that in the first place. > > -n > > -- > Nathaniel J. Smith -- https://vorpus.org > ___ > NumPy-Discussion mailing list > NumPy-Discussion@python.org > https://mail.python.org/mailman/listinfo/numpy-discussion Best regards, Hameer Abbasi Sent from my iPhone___ NumPy-Discussion mailing list NumPy-Discussion@python.org https://mail.python.org/mailman/listinfo/numpy-discussion
[Numpy-discussion] Re: Behavior of round(array)
Hi Sebastian, all, I’d lean towards an error too, given that the invariants implied by the Python implementation clearly aren‘t met. No strong opinions though. Best regards, Hameer Abbasi Von meinem iPhone gesendet > Am 30.11.2022 um 18:36 schrieb Sebastian Berg : > > Hi all, > > there is a discussion about how `round(array)` should behave in: > >https://github.com/numpy/numpy/issues/6248 > > There is some discussion about object arrays which should probably be > fixed for `around()` in that ago. > > Otherwise, the is the question what to do about the fact that: > > * round(np.float64(2.**64)) -> 18446744073709551616 (a Python int) > * round(np.array([2., 3., 2.**64]) can only return float or integer > > The NumPy `np.round`/`np.around` (same function) functions always > return the same dtype. > > We can either ignore that discrepancy, or opt to raise an error, so > that: > round(np.array([2., 3.5])) >TypeError: Rounding a NumPy float array cannot return integers, >use `round(arr, ndigits=0)` or `round(arr, 0) to indicate that a >float result is desired. > > In the call today, I think we leaned a bit towards ignoring it, but if > I read Aaron correctly, he prefers the error and it may be the > conservative choice. > > We could of course do other things (i.e. return an integer `intp` > array) but that would probably require a hard error for overflows > (which is different from `np.rint(arr).astype(np.intp)`. > > Are there any small or big opinions on this? It seems useful to enable > `round()` and is a bit of a shame to get caught up on the detail, but I > am not sure what the right choice is :). > > - Sebastian > > ___ > NumPy-Discussion mailing 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 ___ NumPy-Discussion mailing 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: arch...@mail-archive.com
