Hello,
I want to bring up Issue #2522 'numpy.diff fails on unsigned integers
(Trac #1929)' [1], as it was resonsible for an error in one of our
programs. Short explanation of the bug: np.diff performs a subtraction
on the input array. If this is of type uint and the data contains
falling data, it results in an artihmetic underflow.
>>> np.diff(np.array([0,1,0], dtype=np.uint8))
array([ 1, 255], dtype=uint8)
@charris proposed either
- a note to the doc string and maybe an example to clarify things
- or raise a warning
but with a discussion on the list.
I would like to start it now, as it is an error which is not easily
detectable (no errors or warnings are thrown). In our case the type of a
data sequence, with only zeros and ones, had type f8 as also every other
one, has been changed to u4. As the programs looked for values ==1 and
==-1, it broke silently.
In my opinion, a note in the docs is not enough and does not help if the
type changed or set after the program has been written.
I'd go for automatic upcasting of uints by default and an option to turn
it off, if this behavior is explicitly wanted. This wouldn't be correct
from the point of view of a programmer, but as most of the users have a
scientific background who excpect it 'to work', instead of sth is
theoretically correct but not convenient. (I count myself to the first
group)
When a consens has been achieved I could implement it for a PR.
[1]: https://github.com/numpy/numpy/issues/2522
--
gpg --keyserver keys.gnupg.net --recv-key DC9B463B
Hi everyone, I'm a third year undergraduate student in Computer Science. I
have worked in Python libraries for past two years and am interested in
getting some open source experience in Numpy and it would be great if
anyone could suggest some bugs or issues that are suitable for a beginner
to try working on ?
Hello,
We am pleased to announce the release of NumPy 1.9.1, a
bugfix only release for the 1.9.x series.
https://sourceforge.net/projects/numpy/files/NumPy/1.9.1/
The upgrade is recommended for all users of the 1.9.x series.
Following issues have been fixed:
* gh-5184: restore linear edge behaviour of gradient to as it was in < 1.9.
The second order behaviour is available via the `edge_order` keyword
* gh-4007: workaround Accelerate sgemv crash on OSX 10.9
* gh-5100: restore object dtype inference from iterable objects without
`len()`
* gh-5163: avoid gcc-4.1.2 (red hat 5) miscompilation causing a crash
* gh-5138: fix nanmedian on arrays containing inf
* gh-5240: fix not returning out array from ufuncs with subok=False set
* gh-5203: copy inherited masks in MaskedArray.__array_finalize__
* gh-2317: genfromtxt did not handle filling_values=0 correctly
* gh-5067: restore api of npy_PyFile_DupClose in python2
* gh-5063: cannot convert invalid sequence index to tuple
* gh-5082: Segmentation fault with argmin() on unicode arrays
* gh-5095: don't propagate subtypes from np.where
* gh-5104: np.inner segfaults with SciPy's sparse matrices
* gh-5251: Issue with fromarrays not using correct format for unicode arrays
* gh-5136: Import dummy_threading if importing threading fails
* gh-5148: Make numpy import when run with Python flag '-OO'
* gh-5147: Einsum double contraction in particular order causes ValueError
* gh-479: Make f2py work with intent(in out)
* gh-5170: Make python2 .npy files readable in python3
* gh-5027: Use 'll' as the default length specifier for long long
* gh-4896: fix build error with MSVC 2013 caused by C99 complex support
* gh-4465: Make PyArray_PutTo respect writeable flag
* gh-5225: fix crash when using arange on datetime without dtype set
* gh-5231: fix build in c99 mode
The source distributions have been uploaded to PyPI. The Windows
installers, documentation and release notes can be found at:
https://sourceforge.net/projects/numpy/files/NumPy/1.9.1/
Cheers,
Julian Taylor
There is a PR in github that adds a new keyword to the genfromtxt function,
to limit the number of rows that actually get read in:
https://github.com/numpy/numpy/pull/5103
It is mostly ready to go, and several devs have looked at it without
complaining. Since it is an API change, I wanted to check here: if no one
has any strong opposition, I will be merging it sometime tomorrow.
You have been warned... ;-)
Jaime
--
(\__/)
( O.o)
( > <) Este es Conejo. Copia a Conejo en tu firma y ayúdale en sus planes
de dominación mundial.
Hi group,
I just answered a question on Stackoverflow from some new user, who was
bitten by some unexpected behavior when using a list instead of a np.array,
see here:
http://stackoverflow.com/q/26690480/2647279
The unexpected thing that triggered the error is that multiplying a list
with a Numpy scalar behaves like standard integer multiplication of a list
as in Python without raising an error, while addition in the same way works
as expected:
In [1]: import numpy as np
In [2]: np.version.version
Out[2]: '1.8.2'
In [3]: 2 * [1, 2, 3]
Out[3]: [1, 2, 3, 1, 2, 3]
In [4]: 2.5 * [1, 2, 3]
[...]
TypeError: can't multiply sequence by non-int of type 'float'
In [5]: np.float64(2.5) * [1, 2, 3] # like standard Python list tiling
Out[5]: [1, 2, 3, 1, 2, 3]
In [6]: np.float64(2.5) + [1, 2, 3] # element-wise addition
Out[6]: array([ 3.5, 4.5, 5.5])
I would have expected that the multiplication would have either raised an
exception, or would have given the element-wise result np.array([2.5, 5.0,
7.5]). Is there any good reason why multiplication and addition behave so
different? I am using standard, up-to-date python2.7/numpy under 64-bit
Ubuntu 14.04.
Cheers,
Bas
