On Tue, Feb 23, 2016 at 3:20 PM, Joseph Fox-Rabinovitz
wrote:
> P.S. I would like to turn `sinc` into a `ufunc` at some point if the
> community approves. It would make the computation much cleaner (e.g.,
> in-place `where`) and faster. It would also complement the existing
> trig functions nicely
I have created PR #7322 (https://github.com/numpy/numpy/pull/7322) to
add a scale parameter to `sinc`. What this allows is to compute `sinc`
as `sin(x)/x` or really `sin(n*x)/(n*x)` for arbitrary `n` instead of
just `sin(pi*x)/(pi*x)` as is being done now. The parameter accepts
two string arguments
Christoph, any chance you can test https://github.com/numpy/numpy/pull/7324
before it gets merged (or not).
Chuck
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion
On 2/23/2016 1:05 PM, Pauli Virtanen wrote:
23.02.2016, 22:40, Charles R Harris kirjoitti:
[clip]
On all 32-bit platforms:
ERROR: test_zeros_big (test_multiarray.TestCreation)
--
On Tue, Feb 23, 2016 at 1:58 PM, Julian Taylor <
jtaylor.deb...@googlemail.com> wrote:
> that test needs about 500Mb of memory on windows as it doesn't have
> sparse allocations like most *nixes.
> It used to fail for me during release testing when I only gave the
> windows VM 1GB of ram.
> If its
On Di, 2016-02-23 at 12:36 -0700, Charles R Harris wrote:
> Hi All,
>
> I'm suspecting a possible memory leak in 1.11.x, what is the best way
> to check for that?
>
Would like to learn better methods, but I tried valgrind with trace
origins and full leak check, just thinking maybe it shows somet
23.02.2016, 22:40, Charles R Harris kirjoitti:
[clip]
> On all 32-bit platforms:
>
>
> ERROR: test_zeros_big (test_multiarray.TestCreation)
>
> Traceback (most recent call last
that test needs about 500Mb of memory on windows as it doesn't have
sparse allocations like most *nixes.
It used to fail for me during release testing when I only gave the
windows VM 1GB of ram.
If its a problem for CI we could disable it on windows, or at least skip
the complex double case.
On 23
On Tue, Feb 23, 2016 at 3:30 PM, Nathaniel Smith wrote:
> What should this do?
>
> np.zeros((12, 0)).reshape((10, -1, 2))
>
It should error out, I already covered that. 12 != 20.
Ben Root
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
h
Christoph reports the following problem that I am unable to reproduce on
appveyor or find reported elsewhere.
On all 32-bit platforms:
ERROR: test_zeros_big (test_multiarray.TestCreation)
On Tue, Feb 23, 2016 at 12:23 PM, Benjamin Root wrote:
>
> On Tue, Feb 23, 2016 at 3:14 PM, Nathaniel Smith wrote:
>>
>> Sure, it's totally ambiguous. These are all legal:
>
>
>
> I would argue that except for the first reshape, all of those should be an
> error, and that the current algorithm is
On Tue, Feb 23, 2016 at 3:14 PM, Nathaniel Smith wrote:
> Sure, it's totally ambiguous. These are all legal:
I would argue that except for the first reshape, all of those should be an
error, and that the current algorithm is buggy.
This isn't a heuristic. It isn't guessing. It is making the s
On Tue, Feb 23, 2016 at 8:45 AM, Benjamin Root wrote:
> but, it isn't really ambiguous, is it? The -1 can only refer to a single
> dimension, and if you ignore the zeros in the original and new shape, the -1
> is easily solvable, right?
Sure, it's totally ambiguous. These are all legal:
In [1]:
On Di, 2016-02-23 at 21:06 +0100, Sebastian Berg wrote:
> On Di, 2016-02-23 at 14:57 -0500, Benjamin Root wrote:
> > I'd be more than happy to write up the patch. I don't think it
> > would
> > be quite like make zeros be ones, but it would be along those
> > lines.
> > One case I need to wrap my h
On Di, 2016-02-23 at 14:57 -0500, Benjamin Root wrote:
> I'd be more than happy to write up the patch. I don't think it would
> be quite like make zeros be ones, but it would be along those lines.
> One case I need to wrap my head around is to make sure that a 0 would
> happen if the following was
I'd be more than happy to write up the patch. I don't think it would be
quite like make zeros be ones, but it would be along those lines. One case
I need to wrap my head around is to make sure that a 0 would happen if the
following was true:
>>> a = np.ones((0, 5*64))
>>> a.shape = (-1, 5, 64)
ED
On Tue, 23 Feb 2016 12:36:00 -0700
Charles R Harris wrote:
> Hi All,
>
> I'm suspecting a possible memory leak in 1.11.x, what is the best way to
> check for that?
If that is due to a reference leak, you can use sys.getrefcount() or
weakref.ref().
Otherwise you may want to change Numpy to go th
Hi All,
I'm suspecting a possible memory leak in 1.11.x, what is the best way to
check for that?
Chuck
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion
On Di, 2016-02-23 at 11:45 -0500, Benjamin Root wrote:
> but, it isn't really ambiguous, is it? The -1 can only refer to a
> single dimension, and if you ignore the zeros in the original and new
> shape, the -1 is easily solvable, right?
I think if there is a simple logic (like using 1 for all zer
but, it isn't really ambiguous, is it? The -1 can only refer to a single
dimension, and if you ignore the zeros in the original and new shape, the
-1 is easily solvable, right?
Ben Root
On Tue, Feb 23, 2016 at 11:41 AM, Warren Weckesser <
warren.weckes...@gmail.com> wrote:
>
>
> On Tue, Feb 23,
On Tue, Feb 23, 2016 at 11:32 AM, Benjamin Root
wrote:
> Not exactly sure if this should be a bug or not. This came up in a fairly
> general function of mine to process satellite data. Unexpectedly, one of
> the satellite files had no scans in it, triggering an exception when I
> tried to reshape
Not exactly sure if this should be a bug or not. This came up in a fairly
general function of mine to process satellite data. Unexpectedly, one of
the satellite files had no scans in it, triggering an exception when I
tried to reshape the data from it.
>>> import numpy as np
>>> a = np.zeros((0, 5
23.02.2016, 03:47, Charles R Harris kirjoitti:
> I'm delighted to announce the release of Numpy 1.11.0rc1. Hopefully the
> issues discovered in 1.11.0b3 have been dealt with and this release can go
> on to become the official release. Source files and documentation can be
> found on Sourceforge
> <
On Mon, Feb 22, 2016 at 6:47 PM, Charles R Harris wrote:
> Hi All,
>
> I'm delighted to announce the release of Numpy 1.11.0rc1. Hopefully the
> issues discovered in 1.11.0b3 have been dealt with and this release can go
> on to become the official release. Source files and documentation can be
>
24 matches
Mail list logo