[Numpy-discussion] Runtime Warning by numpy.divide(0.0, 0.0) can't be ignored
Hello,
numpy.divide(0.0,0.0) raises a warning which doesn't appear to get caught
by numpy.seterr(divide='ignore')
This example:
import numpy
numpy.divide(0.0,0.0)
numpy.divide(1.0,0.0)
numpy.seterr(divide='ignore')
numpy.divide(1.0,0.0)
numpy.divide(0.0,0.0)
produces this output:
Warning (from warnings module):
File C:\Users\ldigrego\Desktop\tst.py, line 2
numpy.divide(0.0,0.0)
RuntimeWarning: invalid value encountered in divide
Warning (from warnings module):
File C:\Users\ldigrego\Desktop\tst.py, line 3
numpy.divide(1.0,0.0)
RuntimeWarning: divide by zero encountered in divide
Warning (from warnings module):
File C:\Users\ldigrego\Desktop\tst.py, line 6
numpy.divide(0.0,0.0)
RuntimeWarning: invalid value encountered in divide
Strangely, on Ipython the numpy.seterr(divide='ignore') seems to catch the
warning:
import numpy
numpy.divide(0.0,0.0)
Out[1]: nan
C:\eclipse\plugins\org.python.pydev_2.8.1.2013072611\pysrc\pydevconsole.py:1:
RuntimeWarning: invalid value encountered in divide
from __future__ import nested_scopes #Jython 2.1 support
numpy.divide(1.0,0.0)
Out[1]: inf
C:\eclipse\plugins\org.python.pydev_2.8.1.2013072611\pysrc\pydevconsole.py:1:
RuntimeWarning: divide by zero encountered in divide
from __future__ import nested_scopes #Jython 2.1 support
numpy.seterr(divide='ignore')
Out[1]: {'divide': 'warn', 'invalid': 'warn', 'over': 'warn', 'under':
'ignore'}
numpy.divide(1.0,0.0)
Out[1]: inf
numpy.divide(0.0,0.0)
Out[1]: nan
I could not find information on Google: is this a known problem? Is there
a way to suppress this warning?
I'm working on a 64b Win7 machine employing
numpy-MKL-1.7.0.win-amd64-py2.7.exe.
Best Regards,
Lorenzo
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Runtime Warning by numpy.divide(0.0, 0.0) can't be ignored
On Monday, September 23, 2013, Lorenzo Di Gregorio wrote:
Hello,
numpy.divide(0.0,0.0) raises a warning which doesn't appear to get caught
by numpy.seterr(divide='ignore')
This example:
import numpy
numpy.divide(0.0,0.0)
numpy.divide(1.0,0.0)
numpy.seterr(divide='ignore')
numpy.divide(1.0,0.0)
numpy.divide(0.0,0.0)
produces this output:
Warning (from warnings module):
File C:\Users\ldigrego\Desktop\tst.py, line 2
numpy.divide(0.0,0.0)
RuntimeWarning: invalid value encountered in divide
Warning (from warnings module):
File C:\Users\ldigrego\Desktop\tst.py, line 3
numpy.divide(1.0,0.0)
RuntimeWarning: divide by zero encountered in divide
Warning (from warnings module):
File C:\Users\ldigrego\Desktop\tst.py, line 6
numpy.divide(0.0,0.0)
RuntimeWarning: invalid value encountered in divide
Strangely, on Ipython the numpy.seterr(divide='ignore') seems to catch the
warning:
import numpy
numpy.divide(0.0,0.0)
Out[1]: nan
C:\eclipse\plugins\org.python.pydev_2.8.1.2013072611\pysrc\pydevconsole.py:1:
RuntimeWarning: invalid value encountered in divide
from __future__ import nested_scopes #Jython 2.1 support
numpy.divide(1.0,0.0)
Out[1]: inf
C:\eclipse\plugins\org.python.pydev_2.8.1.2013072611\pysrc\pydevconsole.py:1:
RuntimeWarning: divide by zero encountered in divide
from __future__ import nested_scopes #Jython 2.1 support
numpy.seterr(divide='ignore')
Out[1]: {'divide': 'warn', 'invalid': 'warn', 'over': 'warn', 'under':
'ignore'}
numpy.divide(1.0,0.0)
Out[1]: inf
numpy.divide(0.0,0.0)
Out[1]: nan
I could not find information on Google: is this a known problem? Is there
a way to suppress this warning
This is not a division warning. It is warning you that a NaN (an invalid
value) was generated. It can be controlled using invalid='ignore'. The
reason that it looks like you suppressed it in the IPython example is that
you triggered the warning earlier. The behavior of warnings is that they
only get issued once for each code location. So the second time you
attempted it after setting divide='ignore' it wasn't going to show up
anyways.
I'm working on a 64b Win7 machine employing
numpy-MKL-1.7.0.win-amd64-py2.7.exe.
Best Regards,
Lorenzo
--
Robert Kern
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
[Numpy-discussion] openblas?
Does numpy/scipy support building with openblas for blas,lapack instead of atlas? ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] openblas?
On 09/23/2013 02:27 PM, Neal Becker wrote: Does numpy/scipy support building with openblas for blas,lapack instead of atlas? I have that working myself. I think it was simply a matter of using the configuration below; NumPy will think it is ATLAS, but that doesn't matter. Once NumPy is built with that configuration, just rebuild SciPy and it will use information from NumPy to link with the same... $ cat site.cfg [atlas] atlas_libs = openblas library_dirs = /mn/stornext/u2/dagss/opt/OpenBLAS.mt Dag Sverre ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Removal of numarray and oldnumeric packages.
On Mon, Sep 23, 2013 at 11:21 AM, Derek Homeier de...@astro.physik.uni-goettingen.de wrote: On 23.09.2013, at 7:03PM, Charles R Harris charlesr.har...@gmail.com wrote: I have gotten no feedback on the removal of the numarray and oldnumeric packages. Consequently the removal will take place on 9/28. Scream now or never... The only thing I'd care about is the nd_image subpackage, but as far as I can see, that's already just a wrapper to import scipy.ndimage. I take it there are no pure numpy implementations for the likes of map_coordinates, right? As far as I know, that is correct. Chuck ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Removal of numarray and oldnumeric packages.
On 23.09.2013, at 7:03PM, Charles R Harris charlesr.har...@gmail.com wrote: I have gotten no feedback on the removal of the numarray and oldnumeric packages. Consequently the removal will take place on 9/28. Scream now or never... The only thing I'd care about is the nd_image subpackage, but as far as I can see, that's already just a wrapper to import scipy.ndimage. I take it there are no pure numpy implementations for the likes of map_coordinates, right? Cheers, Derek ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
[Numpy-discussion] Removal of numarray and oldnumeric packages.
Hi All, I have gotten no feedback on the removal of the numarray and oldnumeric packages. Consequently the removal will take place on 9/28. Scream now or never... Chuck ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
[Numpy-discussion] Generating a (uniformly distributed) random bit list of length N
Thanks, St?fan, speed: N ~ 1e9. Thanks again. DG -- Message: 1 Date: Sun, 22 Sep 2013 14:04:09 -0700 From: David Goldsmith d.l.goldsm...@gmail.com Subject: [Numpy-discussion] Generating a (uniformly distributed) random bit list of length N To: numpy-discussion@scipy.org Message-ID: caftpszqg7upjy8s04npwkn8gjvdvgoru3rpjcvln6zkrwnp...@mail.gmail.com Content-Type: text/plain; charset=iso-8859-1 Is np.random.randint(2, size=N) the fastest way to do this? Thanks! DG -- next part -- An HTML attachment was scrubbed... URL: http://mail.scipy.org/pipermail/numpy-discussion/attachments/20130922/b3cebeaa/attachment-0001.html -- Message: 2 Date: Mon, 23 Sep 2013 03:22:06 +0200 From: St?fan van der Walt ste...@sun.ac.za Subject: Re: [Numpy-discussion] Generating a (uniformly distributed) random bit list of length N To: Discussion of Numerical Python numpy-discussion@scipy.org Message-ID: cabdkgqkq829a_nj7xxcs5xauz-ptwcyf_zbslt+0gufnzwy...@mail.gmail.com Content-Type: text/plain; charset=iso-8859-1 On 22 Sep 2013 23:04, David Goldsmith d.l.goldsm...@gmail.com wrote: Is np.random.randint(2, size=N) the fastest way to do this? Thanks! Are you concerned about speed or memory use? The operation you show should already be quite fast. A more memory efficient approach would be to generate integers and use their binary representation. St?fan -- next part -- An HTML attachment was scrubbed... URL: http://mail.scipy.org/pipermail/numpy-discussion/attachments/20130923/e4f56af4/attachment-0001.html ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Removal of numarray and oldnumeric packages.
We at STScI have no objection. If we have any residual dependencies, we'll then find out and fix them. Perry On Sep 23, 2013, at 1:03 PM, Charles R Harris wrote: Hi All, I have gotten no feedback on the removal of the numarray and oldnumeric packages. Consequently the removal will take place on 9/28. Scream now or never... Chuck ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Pull request review #3770: Trapezoidal distribution
On Sun, Sep 22, 2013 at 9:47 AM, Mark Szepieniec mszep...@gmail.com wrote: On Sun, Sep 22, 2013 at 1:24 PM, josef.p...@gmail.com wrote: I don't see a reason that numpy.random shouldn't get new distributions. It would also be useful to add the corresponding distribution to scipy.stats. I have the pdf, cdf, and inverse cdf for the generalized trapezoidal. I've looked through the other distributions at scipy.stats and adding this one should not be difficult. I'll work on it next. naming: n, m would indicate to me that they are integers, but it they can be floats (0) alpha, beta ? The three additional parameters for growth rate, decay rate, and boundary ratio are floats 0. I renamed them from `m`, `n`, and `alpha` (which is how they're parameterized in the published probability density function) to simply `growth`, `decay`, and `ratio`. Does that fit into the NumPy style? It feels intuitive to me. Is there a standard version, e.g. left=0, right=1, mode1=?, ... ? In scipy.stats.distribution we are required to use a location, scale parameterization, where loc shifts the distribution and scale stretches it. Is there a standard parameterization for that?, for example left = loc = 0 (default) or left = loc / scale = 0 right = scale = 1 (default) mode1_relative = mode1 / scale mode2_relative = mode2 / scale n, m unchanged no defaults just checked: your naming corresponds to triangular, and triang in scipy has the corresponding loc-scale parameterization. Thanks. There is no standard version of the distribution that I'm aware of, but for the purposes of scipy.stats, left=0, right=1 and mode1, mode2 being either 0.25, 0.75 or 1/3, 2/3, seem reasonable. I'll give more thought to the location and scale and send an email to scipy-dev if I need guidance. Looking at scipy.stats.triang, my initial thought is: left_relative = loc mode1_relative = loc + mode1*scale mode2_relative = loc + mode2*scale right_relative = loc + scale growth, decay, and ratio are unchanged. I think you need to s/first/second in the description of the mode2 parameter? Thanks for catching that. Fixed in a recent commit. mode2 should be the second peak of the distribution. Jeremy ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Removal of numarray and oldnumeric packages.
On Mon, Sep 23, 2013 at 6:03 PM, Charles R Harris charlesr.har...@gmail.com wrote: Hi All, I have gotten no feedback on the removal of the numarray and oldnumeric packages. Consequently the removal will take place on 9/28. Scream now or never... Chuck Hi Chuck, Could you clarify how we'd know if this is a problem in a large package? i.e. Is it just Python imports I need to double check, or also C level? Thanks! Peter ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Removal of numarray and oldnumeric packages.
On Mon, Sep 23, 2013 at 2:42 PM, Peter Cock p.j.a.c...@googlemail.comwrote: On Mon, Sep 23, 2013 at 6:03 PM, Charles R Harris charlesr.har...@gmail.com wrote: Hi All, I have gotten no feedback on the removal of the numarray and oldnumeric packages. Consequently the removal will take place on 9/28. Scream now or never... Chuck Hi Chuck, Could you clarify how we'd know if this is a problem in a large package? i.e. Is it just Python imports I need to double check, or also C level? Just Python level unless you are calling python from C. The packages are not normally imported, so you should be able to just grep through. You could also apply the patch https://github.com/numpy/numpy/pull/3638 and see what happens. That might be the best test. Chuck ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Removal of numarray and oldnumeric packages.
On Mon, Sep 23, 2013 at 3:18 PM, Charles R Harris charlesr.har...@gmail.com wrote: On Mon, Sep 23, 2013 at 2:42 PM, Peter Cock p.j.a.c...@googlemail.comwrote: On Mon, Sep 23, 2013 at 6:03 PM, Charles R Harris charlesr.har...@gmail.com wrote: Hi All, I have gotten no feedback on the removal of the numarray and oldnumeric packages. Consequently the removal will take place on 9/28. Scream now or never... Chuck Hi Chuck, Could you clarify how we'd know if this is a problem in a large package? i.e. Is it just Python imports I need to double check, or also C level? Just Python level unless you are calling python from C. The packages are not normally imported, so you should be able to just grep through. You could also apply the patch https://github.com/numpy/numpy/pull/3638 and see what happens. That might be the best test. Also, the 1.8 release, when it comes, should issue a ModuleDeprecationWarning warning when the packages are imported. Chuck ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Removal of numarray and oldnumeric packages.
On Mon, Sep 23, 2013 at 3:18 PM, Charles R Harris charlesr.har...@gmail.com wrote: On Mon, Sep 23, 2013 at 2:42 PM, Peter Cock p.j.a.c...@googlemail.comwrote: On Mon, Sep 23, 2013 at 6:03 PM, Charles R Harris charlesr.har...@gmail.com wrote: Hi All, I have gotten no feedback on the removal of the numarray and oldnumeric packages. Consequently the removal will take place on 9/28. Scream now or never... Chuck Hi Chuck, Could you clarify how we'd know if this is a problem in a large package? i.e. Is it just Python imports I need to double check, or also C level? Just Python level unless you are calling python from C. The packages are not normally imported, so you should be able to just grep through. You could also apply the patch https://github.com/numpy/numpy/pull/3638 and see what happens. That might be the best test. I take that back. There is a _capi.c and include files for numarray. Chuck ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Binary releases
Ok, so I've looked a bit into it tonight: - used mingw-w64 4.8.1 (32 bits host) - openblas binaries available on the official website (seem to be built with mingw w64) - used -static-libgcc, -static-libstdc++ and -static-libgfortran - building numpy went ok, test suite almost passes, nothing too alarming. - scipy is still a bit trouble some, I need to look more into it. It definitely looks better than last time I've tried (where it crashed right away). David On Tue, Sep 17, 2013 at 9:20 PM, Ralf Gommers ralf.gomm...@gmail.comwrote: On Mon, Sep 16, 2013 at 10:05 PM, Nathaniel Smith n...@pobox.com wrote: On Mon, Sep 16, 2013 at 8:15 PM, Peter Cock p.j.a.c...@googlemail.com wrote: On Mon, Sep 16, 2013 at 8:05 PM, Nathaniel Smith n...@pobox.com wrote: Why not just release numpy 1.8 with the old and terrible system? As you know I'm 110% in favor of getting rid of it, but 1.8 is ready to go and 1.9 is coming soon enough, and the old and terrible system does work right now, today. None of the other options have this property. The above makes a lot of sense, so I decided to check that it actually does work. Unsurprisingly, it needs fixing: https://github.com/numpy/numpy/issues/3760 Ralf On the down side, the old and terrible system does not cover providing pre-built binaries for 64 bit Windows. Doing that right is important not just for SciPy but for any other downstream package including C code compiled against the NumPy C API (and the people doing this probably will only have access to free compilers). That's not a downside -- that's the situation right now and will continue to be the situation for the immediate future, if we cut a 1.8rc1 tomorrow and also if we don't cut a 1.8rc1 tomorrow. Again, I'm absolutely behind getting this sorted out, but holding up the release on all platforms is not going to make win64 standalone binaries appear any faster, and in the mean time everyone seems to be getting along OK, either because they're using a distribution, are on another platform, or taking advantage of Cristoph's generosity (thank you Cristoph!). Worst case, if it all gets sorted out next week we could release an 1.8.1 to celebrate... -n ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Binary releases
On Mon, Sep 23, 2013 at 8:22 PM, David Cournapeau courn...@gmail.com wrote: Ok, so I've looked a bit into it tonight: - used mingw-w64 4.8.1 (32 bits host) - openblas binaries available on the official website (seem to be built with mingw w64) - used -static-libgcc, -static-libstdc++ and -static-libgfortran - building numpy went ok, test suite almost passes, nothing too alarming. - scipy is still a bit trouble some, I need to look more into it. It definitely looks better than last time I've tried (where it crashed right away). Sounds encouraging Thank you, Josef Back to the future --- or at least to gfortran and 64 David On Tue, Sep 17, 2013 at 9:20 PM, Ralf Gommers ralf.gomm...@gmail.com wrote: On Mon, Sep 16, 2013 at 10:05 PM, Nathaniel Smith n...@pobox.com wrote: On Mon, Sep 16, 2013 at 8:15 PM, Peter Cock p.j.a.c...@googlemail.com wrote: On Mon, Sep 16, 2013 at 8:05 PM, Nathaniel Smith n...@pobox.com wrote: Why not just release numpy 1.8 with the old and terrible system? As you know I'm 110% in favor of getting rid of it, but 1.8 is ready to go and 1.9 is coming soon enough, and the old and terrible system does work right now, today. None of the other options have this property. The above makes a lot of sense, so I decided to check that it actually does work. Unsurprisingly, it needs fixing: https://github.com/numpy/numpy/issues/3760 Ralf On the down side, the old and terrible system does not cover providing pre-built binaries for 64 bit Windows. Doing that right is important not just for SciPy but for any other downstream package including C code compiled against the NumPy C API (and the people doing this probably will only have access to free compilers). That's not a downside -- that's the situation right now and will continue to be the situation for the immediate future, if we cut a 1.8rc1 tomorrow and also if we don't cut a 1.8rc1 tomorrow. Again, I'm absolutely behind getting this sorted out, but holding up the release on all platforms is not going to make win64 standalone binaries appear any faster, and in the mean time everyone seems to be getting along OK, either because they're using a distribution, are on another platform, or taking advantage of Cristoph's generosity (thank you Cristoph!). Worst case, if it all gets sorted out next week we could release an 1.8.1 to celebrate... -n ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Binary releases
On Mon, Sep 23, 2013 at 6:22 PM, David Cournapeau courn...@gmail.comwrote: Ok, so I've looked a bit into it tonight: - used mingw-w64 4.8.1 (32 bits host) - openblas binaries available on the official website (seem to be built with mingw w64) - used -static-libgcc, -static-libstdc++ and -static-libgfortran - building numpy went ok, test suite almost passes, nothing too alarming. - scipy is still a bit trouble some, I need to look more into it. It definitely looks better than last time I've tried (where it crashed right away). Sounds promising. What sort of test failures did you see for numpy? snip Chuck ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
