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. S
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
developer
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
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
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.
See e.g.
https://github.com/jupyter/governance/pull/5
As a thought experiment, what if someone’s politica
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, man
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
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 requi
OK I guess I missed that announcement.
I wouldn’t mind more than one email with a reminder to test.
On Wed, Jun 13, 2018 at 7:42 PM Charles R Harris
wrote:
> On Wed, Jun 13, 2018 at 6:28 PM, Nathan Goldbaum
> wrote:
>
>> Hi Chuck,
>>
>> Are you planning on doing
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,
>
> T
es for
the noise.
On Tue, Jun 5, 2018 at 7:39 PM, Nathan Goldbaum
wrote:
> 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
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
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 Steph
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
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.,
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
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
>>
>> Best regards,
>> Hameer Abbasi
>> Sent from Astro <https://www.helloastro.com> for Mac
>>
>> On Apr 26, 2018 at 18:45, Nathan Goldbaum wrote:
>>
>>
>> Hi all,
>>
>> I was surprised recently to discover that both np.any
her package.
>
> Best regards,
> Hameer Abbasi
> Sent from Astro <https://www.helloastro.com> for Mac
>
> On Apr 26, 2018 at 18:45, Nathan Goldbaum wrote:
>
>
> Hi all,
>
> I was surprised recently to discover that both np.any and np.all() do not
> hav
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. de
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,
> >
> > Wha
numpy.float is an alias to the python float builtin.
https://github.com/numpy/numpy/issues/3998
On Thu, Mar 22, 2018 at 2:26 PM Olivier wrote:
> Hello,
>
>
> Is it normal, expected and desired that :
>
>
> round(numpy.float64(0.0)) is a numpy.float64
>
>
> while
>
> round(numpy.flo
On Thu, Nov 2, 2017 at 5:21 PM, Stephan Hoyer wrote:
> On Thu, Nov 2, 2017 at 12:42 PM Nathan Goldbaum
> 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
On Thu, Nov 2, 2017 at 2:37 PM, Stephan Hoyer wrote:
> On Thu, Nov 2, 2017 at 9:45 AM wrote:
>
>> similar, scipy.special has ufuncs
>> what units are those?
>>
>> Most code that I know (i.e. scipy.stats and statsmodels) does not use only
>> "normal mathematical operations with ufuncs"
>> I guess
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 W
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, arra
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
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.n
The latest version of numpy is 1.13.
In this case, as described in the docs, a power function distribution is
one with a probability desnity function of the form ax^(a-1) for x between
0 and 1.
On Thu, Aug 24, 2017 at 9:41 AM, Renato Fabbri
wrote:
> Thanks for the reply.
>
> But the question re
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 amon
Just as a comment: It would be really nice if NumPy could slow down the
pace of deprecations, or at least make the warnings about deprecations more
visible. It seems like every release breaks some subset of our test suite
(we only had one or two cases of using the binary - operator on boolean
array
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&q=__array_priority__&type=Code&utf8=%E2%9C%93
On Mon, Jun 19, 2017 at 11:07 AM, Ilhan Polat wrote:
> Thank you. I didn't know that it exis
Hi Chuck,
Is there a docs build for this release somewhere? I'd like to find an
authoritative reference about __array_ufunc__, which I'd hesistated on
looking into until now for fear about the API changing.
Nathan
On Wed, May 10, 2017 at 8:49 PM Charles R Harris
wrote:
> Hi All,
>
> I'm please
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
34 matches
Mail list logo
