Hi,
I'm trying to get a view on a sliced array without copy but I'm not able to do it as illustrated below:
dtype = np.dtype( [('color', 'f4', 4)] )
Z = np.zeros(100, dtype=dtype)
print Z.view('f4').base is Z # True
print Z[:50].base is Z # True
print (Z.view('f4'))[:50].base is Z # False
print Z[:50].view('f4').base is Z # False
Did I do something wrong or is it expected behavior ?
Nicolas
Hello all,
I was able to successfully embed python code into C code. The basic
skeleton is something like this :
In C code :
PyObject *pName, *pModule, *pFunc,*pArgs,*pReturn;
PyArrayObject *cusForce;
Py_Initialize();
import_array(); // required while using numpy arrays in C
// Call some python code
// Py_Decref all the used values
Py_Finalize()
Py_Finalize caused segmentation faults when numpy was one of import modules
[node1:05762] Failing at address: 0x1
[node1:05762] [ 0] /lib64/libc.so.6 [0x3afa630280]
[node1:05762] [ 1]
/usr/lib64/python2.4/site-packages/numpy/core/multiarray.so [0x2b4e950aaf37]
[node1:05762] [ 2]
/usr/lib64/python2.4/site-packages/numpy/core/multiarray.so [0x2b4e950dd1d0]
[node1:05762] [ 3]
/usr/lib64/python2.4/site-packages/numpy/core/multiarray.so [0x2b4e950e22fa]
[node1:05762] [ 4] /usr/lib64/libpython2.4.so.1.0(PyObject_IsTrue+0x37)
[0x2b4e8a683c77]
Which could be avoided by not calling Py_Finalize. But without calling
Py_Finalize(), I am having huge memory leaks
as the process keeps on increasing its memory usage as I see in top.
Is there any clean way of calling Py_Finalize() when using numpy.
Thanks
santhosh
Apologies if this is the wrong mailing list.
I have installed bumpy using the excellent script here: http://fonnesbeck.github.com/ScipySuperpack/
I ran numpy.test('full') and got several errors. Should I be worried?
Thanks, Dominic.
PS I can send the full errors if that would be helpful.
>>> np.test('full')
Running unit tests for numpy
NumPy version 1.8.0.dev-4600b2f
NumPy is installed in /Library/Python/2.7/site-packages/numpy-1.8.0.dev_4600b2f_20130131-py2.7-macosx-10.8-intel.egg/numpy
Python version 2.7.3 (v2.7.3:70274d53c1dd, Apr 9 2012, 20:52:43) [GCC 4.2.1 (Apple Inc. build 5666) (dot 3)]
nose version 1.2.1
…
Ran 4471 tests in 13.065s
FAILED (KNOWNFAIL=5, SKIP=26, errors=2, failures=3)
<nose.result.TextTestResult run=4471 errors=2 failures=3>
I compiled numpy 1.6.2 (right before 1.7 came out) with the intel
compiler and MKL library. I'm trying to assess
whether or not everything has been build fine. Since my machine is
actually a cluster, I'm running the tests in different configurations
(login node and batch script). However, I'm confused by the number of
tests which ran.
On the login nodes (either interactively or without tty) I get:
Ran 3587 tests in 22.211s
FAILED (KNOWNFAIL=5, SKIP=11, failures=2)
Whereas in a remote batch node (with a script) I get:
Ran 3229 tests in 15.642s
OK (KNOWNFAIL=5, SKIP=19)
Where did the 358 "missing" tests go in the batch run?
The handful difference in SKIPped and FAILed (which I am
investigating) cannot be the reason.
What is it happening?
PS: a similar thing happened with scipy, which I'm asking on the
scipy mailing list.
Thanks and Regards,
Davide
I have just upgraded numpy with pip on Linux 64 bits with Python 2.7,
and I got *a lot* of output, so much it doesn't fit in the terminal.
Most of it are gcc commands, but there are many different errors
thrown by the compiler. Is this expected?
I am not too worried as the test suite passes, but pip is supposed to
give only meaningful output (or at least, this is what the creators
intended).
David.
I have two NxMx3 arrays and I want to reduce over the last dimension of the
first array by selecting those elements corresponding to the index of the
maximum value of each 3-vector of the second array to give an NxM result.
Hopefully that makes sense? If not hopefully the example below will shed some
light.
Can anyone think of a more efficient way to do this than my 1st attempt? I
thought that nditer might be the solution; I got it to work (mostly by trial &
error) but found that it's ~50x slower for this task! Is this not a good usecase
for nditer or am I doing something wrong?
In [42]: value_array = np.outer(ones(1000), arange(3)).reshape(20,50,3)
...: index_array = randn(*value_array.shape)
In [43]: indices = index_array.reshape(-1,3).argmax(axis=1)
...: result = value_array.reshape(-1,3)[np.arange(indices.size), indices]
...: result = result.reshape(value_array.shape[0:-1])
In [44]: it = np.nditer([value_array, index_array, None],
...: flags=['reduce_ok', 'external_loop','buffered', 'delay_bufalloc'],
...: op_flags=[['readonly'],['readonly'],['readwrite', 'allocate']],
...: op_axes=[[0,1,2], [0,1,2], [0,1,-1]])
...: it.reset()
...: for values, index_values, out in it:
...: out[...] = values[index_values.argmax()]
...: #
In [45]: allclose(result, it.operands[2])
Out[45]: True
In [46]: %%timeit
...: indices = index_array.reshape(-1,3).argmax(axis=1)
...: result = value_array.reshape(-1,3)[np.arange(indices.size), indices]
...: result = result.reshape(value_array.shape[0:-1])
...:
10000 loops, best of 3: 113 µs per loop
In [47]: %%timeit
...: it = np.nditer([value_array, index_array, None],
...: flags=['reduce_ok', 'external_loop','buffered', 'delay_bufalloc'],
...: op_flags=[['readonly'],['readonly'],['readwrite', 'allocate']],
...: op_axes=[[0,1,2], [0,1,2], [0,1,-1]])
...: it.reset()
...: for values, index_values, out in it:
...: out[...] = values[index_values.argmax()]
...: #
...:
100 loops, best of 3: 5.26 ms per loop
In [48]:
Thanks,
Dave
Hi,
I'm pleased to announce the availability of the final release of
NumPy 1.7.0.
Sources and binary installers can be found at
https://sourceforge.net/projects/numpy/files/NumPy/1.7.0/
This release is equivalent to the 1.7.0rc2 release, since no more problems
were found. For release notes see below.
I would like to thank everybody who contributed to this release.
Cheers,
Ondrej
=========================
NumPy 1.7.0 Release Notes
=========================
This release includes several new features as well as numerous bug fixes and
refactorings. It supports Python 2.4 - 2.7 and 3.1 - 3.3 and is the last
release that supports Python 2.4 - 2.5.
Highlights
==========
* ``where=`` parameter to ufuncs (allows the use of boolean arrays to choose
where a computation should be done)
* ``vectorize`` improvements (added 'excluded' and 'cache' keyword, general
cleanup and bug fixes)
* ``numpy.random.choice`` (random sample generating function)
Compatibility notes
===================
In a future version of numpy, the functions np.diag, np.diagonal, and the
diagonal method of ndarrays will return a view onto the original array,
instead of producing a copy as they do now. This makes a difference if you
write to the array returned by any of these functions. To facilitate this
transition, numpy 1.7 produces a FutureWarning if it detects that you may
be attempting to write to such an array. See the documentation for
np.diagonal for details.
Similar to np.diagonal above, in a future version of numpy, indexing a
record array by a list of field names will return a view onto the original
array, instead of producing a copy as they do now. As with np.diagonal,
numpy 1.7 produces a FutureWarning if it detects that you may be attempting
to write to such an array. See the documentation for array indexing for
details.
In a future version of numpy, the default casting rule for UFunc out=
parameters will be changed from 'unsafe' to 'same_kind'. (This also applies
to in-place operations like a += b, which is equivalent to np.add(a, b,
out=a).) Most usages which violate the 'same_kind' rule are likely bugs, so
this change may expose previously undetected errors in projects that depend
on NumPy. In this version of numpy, such usages will continue to succeed,
but will raise a DeprecationWarning.
Full-array boolean indexing has been optimized to use a different,
optimized code path. This code path should produce the same results,
but any feedback about changes to your code would be appreciated.
Attempting to write to a read-only array (one with ``arr.flags.writeable``
set to ``False``) used to raise either a RuntimeError, ValueError, or
TypeError inconsistently, depending on which code path was taken. It now
consistently raises a ValueError.
The <ufunc>.reduce functions evaluate some reductions in a different order
than in previous versions of NumPy, generally providing higher performance.
Because of the nature of floating-point arithmetic, this may subtly change
some results, just as linking NumPy to a different BLAS implementations
such as MKL can.
If upgrading from 1.5, then generally in 1.6 and 1.7 there have been
substantial code added and some code paths altered, particularly in the
areas of type resolution and buffered iteration over universal functions.
This might have an impact on your code particularly if you relied on
accidental behavior in the past.
New features
============
Reduction UFuncs Generalize axis= Parameter
-------------------------------------------
Any ufunc.reduce function call, as well as other reductions like sum, prod,
any, all, max and min support the ability to choose a subset of the axes to
reduce over. Previously, one could say axis=None to mean all the axes or
axis=# to pick a single axis. Now, one can also say axis=(#,#) to pick a
list of axes for reduction.
Reduction UFuncs New keepdims= Parameter
----------------------------------------
There is a new keepdims= parameter, which if set to True, doesn't throw
away the reduction axes but instead sets them to have size one. When this
option is set, the reduction result will broadcast correctly to the
original operand which was reduced.
Datetime support
----------------
.. note:: The datetime API is *experimental* in 1.7.0, and may undergo changes
in future versions of NumPy.
There have been a lot of fixes and enhancements to datetime64 compared
to NumPy 1.6:
* the parser is quite strict about only accepting ISO 8601 dates, with a few
convenience extensions
* converts between units correctly
* datetime arithmetic works correctly
* business day functionality (allows the datetime to be used in contexts where
only certain days of the week are valid)
The notes in `doc/source/reference/arrays.datetime.rst
<https://github.com/numpy/numpy/blob/maintenance/1.7.x/doc/source/reference/…>`_
(also available in the online docs at `arrays.datetime.html
<http://docs.scipy.org/doc/numpy/reference/arrays.datetime.html>`_) should be
consulted for more details.
Custom formatter for printing arrays
------------------------------------
See the new ``formatter`` parameter of the ``numpy.set_printoptions``
function.
New function numpy.random.choice
---------------------------------
A generic sampling function has been added which will generate samples from
a given array-like. The samples can be with or without replacement, and
with uniform or given non-uniform probabilities.
New function isclose
--------------------
Returns a boolean array where two arrays are element-wise equal within a
tolerance. Both relative and absolute tolerance can be specified.
Preliminary multi-dimensional support in the polynomial package
---------------------------------------------------------------
Axis keywords have been added to the integration and differentiation
functions and a tensor keyword was added to the evaluation functions.
These additions allow multi-dimensional coefficient arrays to be used in
those functions. New functions for evaluating 2-D and 3-D coefficient
arrays on grids or sets of points were added together with 2-D and 3-D
pseudo-Vandermonde matrices that can be used for fitting.
Ability to pad rank-n arrays
----------------------------
A pad module containing functions for padding n-dimensional arrays has been
added. The various private padding functions are exposed as options to a
public 'pad' function. Example::
pad(a, 5, mode='mean')
Current modes are ``constant``, ``edge``, ``linear_ramp``, ``maximum``,
``mean``, ``median``, ``minimum``, ``reflect``, ``symmetric``, ``wrap``, and
``<function>``.
New argument to searchsorted
----------------------------
The function searchsorted now accepts a 'sorter' argument that is a
permutation array that sorts the array to search.
Build system
------------
Added experimental support for the AArch64 architecture.
C API
-----
New function ``PyArray_RequireWriteable`` provides a consistent interface
for checking array writeability -- any C code which works with arrays whose
WRITEABLE flag is not known to be True a priori, should make sure to call
this function before writing.
NumPy C Style Guide added (``doc/C_STYLE_GUIDE.rst.txt``).
Changes
=======
General
-------
The function np.concatenate tries to match the layout of its input arrays.
Previously, the layout did not follow any particular reason, and depended
in an undesirable way on the particular axis chosen for concatenation. A
bug was also fixed which silently allowed out of bounds axis arguments.
The ufuncs logical_or, logical_and, and logical_not now follow Python's
behavior with object arrays, instead of trying to call methods on the
objects. For example the expression (3 and 'test') produces the string
'test', and now np.logical_and(np.array(3, 'O'), np.array('test', 'O'))
produces 'test' as well.
The ``.base`` attribute on ndarrays, which is used on views to ensure that the
underlying array owning the memory is not deallocated prematurely, now
collapses out references when you have a view-of-a-view. For example::
a = np.arange(10)
b = a[1:]
c = b[1:]
In numpy 1.6, ``c.base`` is ``b``, and ``c.base.base`` is ``a``. In numpy 1.7,
``c.base`` is ``a``.
To increase backwards compatibility for software which relies on the old
behaviour of ``.base``, we only 'skip over' objects which have exactly the same
type as the newly created view. This makes a difference if you use ``ndarray``
subclasses. For example, if we have a mix of ``ndarray`` and ``matrix`` objects
which are all views on the same original ``ndarray``::
a = np.arange(10)
b = np.asmatrix(a)
c = b[0, 1:]
d = c[0, 1:]
then ``d.base`` will be ``b``. This is because ``d`` is a ``matrix`` object,
and so the collapsing process only continues so long as it encounters other
``matrix`` objects. It considers ``c``, ``b``, and ``a`` in that order, and
``b`` is the last entry in that list which is a ``matrix`` object.
Casting Rules
-------------
Casting rules have undergone some changes in corner cases, due to the
NA-related work. In particular for combinations of scalar+scalar:
* the `longlong` type (`q`) now stays `longlong` for operations with any other
number (`? b h i l q p B H I`), previously it was cast as `int_` (`l`). The
`ulonglong` type (`Q`) now stays as `ulonglong` instead of `uint` (`L`).
* the `timedelta64` type (`m`) can now be mixed with any integer type (`b h i l
q p B H I L Q P`), previously it raised `TypeError`.
For array + scalar, the above rules just broadcast except the case when
the array and scalars are unsigned/signed integers, then the result gets
converted to the array type (of possibly larger size) as illustrated by the
following examples::
>>> (np.zeros((2,), dtype=np.uint8) + np.int16(257)).dtype
dtype('uint16')
>>> (np.zeros((2,), dtype=np.int8) + np.uint16(257)).dtype
dtype('int16')
>>> (np.zeros((2,), dtype=np.int16) + np.uint32(2**17)).dtype
dtype('int32')
Whether the size gets increased depends on the size of the scalar, for
example::
>>> (np.zeros((2,), dtype=np.uint8) + np.int16(255)).dtype
dtype('uint8')
>>> (np.zeros((2,), dtype=np.uint8) + np.int16(256)).dtype
dtype('uint16')
Also a ``complex128`` scalar + ``float32`` array is cast to ``complex64``.
In NumPy 1.7 the `datetime64` type (`M`) must be constructed by explicitly
specifying the type as the second argument (e.g. ``np.datetime64(2000, 'Y')``).
Deprecations
============
General
-------
Specifying a custom string formatter with a `_format` array attribute is
deprecated. The new `formatter` keyword in ``numpy.set_printoptions`` or
``numpy.array2string`` can be used instead.
The deprecated imports in the polynomial package have been removed.
``concatenate`` now raises DepractionWarning for 1D arrays if ``axis != 0``.
Versions of numpy < 1.7.0 ignored axis argument value for 1D arrays. We
allow this for now, but in due course we will raise an error.
C-API
-----
Direct access to the fields of PyArrayObject* has been deprecated. Direct
access has been recommended against for many releases. Expect similar
deprecations for PyArray_Descr* and other core objects in the future as
preparation for NumPy 2.0.
The macros in old_defines.h are deprecated and will be removed in the next
major release (>= 2.0). The sed script tools/replace_old_macros.sed can be
used to replace these macros with the newer versions.
You can test your code against the deprecated C API by #defining
NPY_NO_DEPRECATED_API to the target version number, for example
NPY_1_7_API_VERSION, before including any NumPy headers.
The ``NPY_CHAR`` member of the ``NPY_TYPES`` enum is deprecated and will be
removed in NumPy 1.8. See the discussion at
`gh-2801 <https://github.com/numpy/numpy/issues/2801>`_ for more details.
Checksums
=========
7b72cc17b6a9043f6d46af4e71cd3dbe
release/installers/numpy-1.7.0-win32-superpack-python3.3.exe
4fa54e40b6a243416f0248123b6ec332 release/installers/numpy-1.7.0.tar.gz
9ef1688bb9f8deb058a8022b4788686c
release/installers/numpy-1.7.0-win32-superpack-python2.7.exe
909fe47da05d2a35edd6909ba0152213
release/installers/numpy-1.7.0-win32-superpack-python3.2.exe
5d4318b722d0098f78b49c0030d47026
release/installers/numpy-1.7.0-win32-superpack-python2.6.exe
92b61d6f278a81cf9a5033b0c8e7b53e
release/installers/numpy-1.7.0-win32-superpack-python3.1.exe
51d6f4f854cdca224fa56a327ad7c620
release/installers/numpy-1.7.0-win32-superpack-python2.5.exe
ca27913c59393940e880fab420f985b4 release/installers/numpy-1.7.0.zip
3f20becbb80da09412d94815ad3b586b
release/installers/numpy-1.7.0-py2.5-python.org-macosx10.3.dmg
600dfa4dab31db5dc2ed9655521cfa9e
release/installers/numpy-1.7.0-py2.6-python.org-macosx10.3.dmg
a907a37416163b3245a30cfd160506ab
release/installers/numpy-1.7.0-py2.7-python.org-macosx10.3.dmg
Hi,
I have recently setup a page about modern Fortran:
http://fortran90.org/
and in particular, it has a long section with side by side syntax
examples of Python/NumPy vs Fortran:
http://fortran90.org/src/rosetta.html
I would be very interested if some NumPy gurus would provide me
feedback. I personally knew
NumPy long before I learned Fortran, and I was amazed that the modern
Fortran pretty much
allows 1:1 syntax with NumPy, including most of all the fancy indexing etc.
Is there some NumPy feature that is not covered there? I would like it
to be a nice resource
for people who know NumPy to feel like at home with Fortran, and vice
versa. I personally
use both every day (Fortran a bit more than NumPy).
Or of you have any other comments or tips for the site, please let me
know. Eventually I'd like
to also put there C++ way of doing the same things, but at the moment
I want to get Fortran
and Python/NumPy done first.
Ondrej
Hi,
I'm pleased to announce the availability of the second release candidate of
NumPy 1.7.0rc2.
Sources and binary installers can be found at
https://sourceforge.net/projects/numpy/files/NumPy/1.7.0rc2/
We have fixed all issues known to us since the 1.7.0rc1 release.
Please test this release and report any issues on the numpy-discussion
mailing list. If there are no further problems, I plan to release the final
version in a few days.
I would like to thank Sandro Tosi, Sebastian Berg, Charles Harris,
Marcin Juszkiewicz, Mark Wiebe, Ralf Gommers and Nathaniel J. Smith
for sending patches, fixes and helping with reviews for this release since
1.7.0rc1, and Vincent Davis for providing the Mac build machine.
Cheers,
Ondrej
=========================
NumPy 1.7.0 Release Notes
=========================
This release includes several new features as well as numerous bug fixes and
refactorings. It supports Python 2.4 - 2.7 and 3.1 - 3.3 and is the last
release that supports Python 2.4 - 2.5.
Highlights
==========
* ``where=`` parameter to ufuncs (allows the use of boolean arrays to choose
where a computation should be done)
* ``vectorize`` improvements (added 'excluded' and 'cache' keyword, general
cleanup and bug fixes)
* ``numpy.random.choice`` (random sample generating function)
Compatibility notes
===================
In a future version of numpy, the functions np.diag, np.diagonal, and the
diagonal method of ndarrays will return a view onto the original array,
instead of producing a copy as they do now. This makes a difference if you
write to the array returned by any of these functions. To facilitate this
transition, numpy 1.7 produces a FutureWarning if it detects that you may
be attempting to write to such an array. See the documentation for
np.diagonal for details.
Similar to np.diagonal above, in a future version of numpy, indexing a
record array by a list of field names will return a view onto the original
array, instead of producing a copy as they do now. As with np.diagonal,
numpy 1.7 produces a FutureWarning if it detects that you may be attempting
to write to such an array. See the documentation for array indexing for
details.
In a future version of numpy, the default casting rule for UFunc out=
parameters will be changed from 'unsafe' to 'same_kind'. (This also applies
to in-place operations like a += b, which is equivalent to np.add(a, b,
out=a).) Most usages which violate the 'same_kind' rule are likely bugs, so
this change may expose previously undetected errors in projects that depend
on NumPy. In this version of numpy, such usages will continue to succeed,
but will raise a DeprecationWarning.
Full-array boolean indexing has been optimized to use a different,
optimized code path. This code path should produce the same results,
but any feedback about changes to your code would be appreciated.
Attempting to write to a read-only array (one with ``arr.flags.writeable``
set to ``False``) used to raise either a RuntimeError, ValueError, or
TypeError inconsistently, depending on which code path was taken. It now
consistently raises a ValueError.
The <ufunc>.reduce functions evaluate some reductions in a different order
than in previous versions of NumPy, generally providing higher performance.
Because of the nature of floating-point arithmetic, this may subtly change
some results, just as linking NumPy to a different BLAS implementations
such as MKL can.
If upgrading from 1.5, then generally in 1.6 and 1.7 there have been
substantial code added and some code paths altered, particularly in the
areas of type resolution and buffered iteration over universal functions.
This might have an impact on your code particularly if you relied on
accidental behavior in the past.
New features
============
Reduction UFuncs Generalize axis= Parameter
-------------------------------------------
Any ufunc.reduce function call, as well as other reductions like sum, prod,
any, all, max and min support the ability to choose a subset of the axes to
reduce over. Previously, one could say axis=None to mean all the axes or
axis=# to pick a single axis. Now, one can also say axis=(#,#) to pick a
list of axes for reduction.
Reduction UFuncs New keepdims= Parameter
----------------------------------------
There is a new keepdims= parameter, which if set to True, doesn't throw
away the reduction axes but instead sets them to have size one. When this
option is set, the reduction result will broadcast correctly to the
original operand which was reduced.
Datetime support
----------------
.. note:: The datetime API is *experimental* in 1.7.0, and may undergo changes
in future versions of NumPy.
There have been a lot of fixes and enhancements to datetime64 compared
to NumPy 1.6:
* the parser is quite strict about only accepting ISO 8601 dates, with a few
convenience extensions
* converts between units correctly
* datetime arithmetic works correctly
* business day functionality (allows the datetime to be used in contexts where
only certain days of the week are valid)
The notes in `doc/source/reference/arrays.datetime.rst
<https://github.com/numpy/numpy/blob/maintenance/1.7.x/doc/source/reference/…>`_
(also available in the online docs at `arrays.datetime.html
<http://docs.scipy.org/doc/numpy/reference/arrays.datetime.html>`_) should be
consulted for more details.
Custom formatter for printing arrays
------------------------------------
See the new ``formatter`` parameter of the ``numpy.set_printoptions``
function.
New function numpy.random.choice
---------------------------------
A generic sampling function has been added which will generate samples from
a given array-like. The samples can be with or without replacement, and
with uniform or given non-uniform probabilities.
New function isclose
--------------------
Returns a boolean array where two arrays are element-wise equal within a
tolerance. Both relative and absolute tolerance can be specified.
Preliminary multi-dimensional support in the polynomial package
---------------------------------------------------------------
Axis keywords have been added to the integration and differentiation
functions and a tensor keyword was added to the evaluation functions.
These additions allow multi-dimensional coefficient arrays to be used in
those functions. New functions for evaluating 2-D and 3-D coefficient
arrays on grids or sets of points were added together with 2-D and 3-D
pseudo-Vandermonde matrices that can be used for fitting.
Ability to pad rank-n arrays
----------------------------
A pad module containing functions for padding n-dimensional arrays has been
added. The various private padding functions are exposed as options to a
public 'pad' function. Example::
pad(a, 5, mode='mean')
Current modes are ``constant``, ``edge``, ``linear_ramp``, ``maximum``,
``mean``, ``median``, ``minimum``, ``reflect``, ``symmetric``, ``wrap``, and
``<function>``.
New argument to searchsorted
----------------------------
The function searchsorted now accepts a 'sorter' argument that is a
permutation array that sorts the array to search.
Build system
------------
Added experimental support for the AArch64 architecture.
C API
-----
New function ``PyArray_RequireWriteable`` provides a consistent interface
for checking array writeability -- any C code which works with arrays whose
WRITEABLE flag is not known to be True a priori, should make sure to call
this function before writing.
NumPy C Style Guide added (``doc/C_STYLE_GUIDE.rst.txt``).
Changes
=======
General
-------
The function np.concatenate tries to match the layout of its input arrays.
Previously, the layout did not follow any particular reason, and depended
in an undesirable way on the particular axis chosen for concatenation. A
bug was also fixed which silently allowed out of bounds axis arguments.
The ufuncs logical_or, logical_and, and logical_not now follow Python's
behavior with object arrays, instead of trying to call methods on the
objects. For example the expression (3 and 'test') produces the string
'test', and now np.logical_and(np.array(3, 'O'), np.array('test', 'O'))
produces 'test' as well.
The ``.base`` attribute on ndarrays, which is used on views to ensure that the
underlying array owning the memory is not deallocated prematurely, now
collapses out references when you have a view-of-a-view. For example::
a = np.arange(10)
b = a[1:]
c = b[1:]
In numpy 1.6, ``c.base`` is ``b``, and ``c.base.base`` is ``a``. In numpy 1.7,
``c.base`` is ``a``.
To increase backwards compatibility for software which relies on the old
behaviour of ``.base``, we only 'skip over' objects which have exactly the same
type as the newly created view. This makes a difference if you use ``ndarray``
subclasses. For example, if we have a mix of ``ndarray`` and ``matrix`` objects
which are all views on the same original ``ndarray``::
a = np.arange(10)
b = np.asmatrix(a)
c = b[0, 1:]
d = c[0, 1:]
then ``d.base`` will be ``b``. This is because ``d`` is a ``matrix`` object,
and so the collapsing process only continues so long as it encounters other
``matrix`` objects. It considers ``c``, ``b``, and ``a`` in that order, and
``b`` is the last entry in that list which is a ``matrix`` object.
Casting Rules
-------------
Casting rules have undergone some changes in corner cases, due to the
NA-related work. In particular for combinations of scalar+scalar:
* the `longlong` type (`q`) now stays `longlong` for operations with any other
number (`? b h i l q p B H I`), previously it was cast as `int_` (`l`). The
`ulonglong` type (`Q`) now stays as `ulonglong` instead of `uint` (`L`).
* the `timedelta64` type (`m`) can now be mixed with any integer type (`b h i l
q p B H I L Q P`), previously it raised `TypeError`.
For array + scalar, the above rules just broadcast except the case when
the array and scalars are unsigned/signed integers, then the result gets
converted to the array type (of possibly larger size) as illustrated by the
following examples::
>>> (np.zeros((2,), dtype=np.uint8) + np.int16(257)).dtype
dtype('uint16')
>>> (np.zeros((2,), dtype=np.int8) + np.uint16(257)).dtype
dtype('int16')
>>> (np.zeros((2,), dtype=np.int16) + np.uint32(2**17)).dtype
dtype('int32')
Whether the size gets increased depends on the size of the scalar, for
example::
>>> (np.zeros((2,), dtype=np.uint8) + np.int16(255)).dtype
dtype('uint8')
>>> (np.zeros((2,), dtype=np.uint8) + np.int16(256)).dtype
dtype('uint16')
Also a ``complex128`` scalar + ``float32`` array is cast to ``complex64``.
In NumPy 1.7 the `datetime64` type (`M`) must be constructed by explicitly
specifying the type as the second argument (e.g. ``np.datetime64(2000, 'Y')``).
Deprecations
============
General
-------
Specifying a custom string formatter with a `_format` array attribute is
deprecated. The new `formatter` keyword in ``numpy.set_printoptions`` or
``numpy.array2string`` can be used instead.
The deprecated imports in the polynomial package have been removed.
``concatenate`` now raises DepractionWarning for 1D arrays if ``axis != 0``.
Versions of numpy < 1.7.0 ignored axis argument value for 1D arrays. We
allow this for now, but in due course we will raise an error.
C-API
-----
Direct access to the fields of PyArrayObject* has been deprecated. Direct
access has been recommended against for many releases. Expect similar
deprecations for PyArray_Descr* and other core objects in the future as
preparation for NumPy 2.0.
The macros in old_defines.h are deprecated and will be removed in the next
major release (>= 2.0). The sed script tools/replace_old_macros.sed can be
used to replace these macros with the newer versions.
You can test your code against the deprecated C API by #defining
NPY_NO_DEPRECATED_API to the target version number, for example
NPY_1_7_API_VERSION, before including any NumPy headers.
The ``NPY_CHAR`` member of the ``NPY_TYPES`` enum is deprecated and will be
removed in NumPy 1.8. See the discussion at
`gh-2801 <https://github.com/numpy/numpy/issues/2801>`_ for more details.
Hi,
I see there is a lot of ongoing discussion on casting rules, but I couldn't
find any reference to the following issue I am facing. I am trying to
'take' from an array of uint8's, using an array of uint16's as indices.
Even though the return dtype would be uint8, I want to direct the output
back into the array of uint16's:
>>> lut = np.random.randint(256, size=(65536,)).astype('uint8')
>>> arr = np.random.randint(65536, size=(1000, 1000)).astype('uint16')
>>> np.take(lut, arr, out=arr)
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "C:\Python27\lib\site-packages\numpy\core\fromnumeric.py", line 103,
in take
return take(indices, axis, out, mode)
TypeError: array cannot be safely cast to required type
This is puzzling, since the only casting that should be happening is from
uint8's to uint16's, which is as safe as it gets:
>>> np.can_cast('uint8', 'uint16')
True
To make things even weirder, I can get the above code to work if the type
of lut is uint16, uint32, uint64, int32 or int 64, but not if it is uint8,
int8 or int16. Without looking at the source, it almost looks as if the
type checking in numpy.take was reversed... Am I missing something, or is
this broken?
My numpy's version is:
>>> np.__version__
'1.6.2'
which is the one packaged in Python xy 2.7.3.1, running on a 64 bit Windows
7 system.
Thanks,
Jaime
P.S. I have posted the same question in StackExchange:
http://stackoverflow.com/questions/14782135/type-casting-error-with-numpy-t…
--
(\__/)
( O.o)
( > <) Este es Conejo. Copia a Conejo en tu firma y ayúdale en sus planes
de dominación mundial.
