| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| |
|
|
|
| |
As numpy is Python 3 only, these import statements are now unnecessary
and don't alter runtime behavior.
|
| |
|
|
|
|
|
|
|
|
| |
Allow unsafe casting from a simple data type to a structured one with
multiple fields, but only from structured data type with a single
field (checked recursively) to a simple data type.
For now, continue to allow any structured to structured with
casting="unsafe", as the current can_cast implementation does not
match that of "astype".
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
[ci skip]
|
| |
|
|
|
| |
Fixes #10409
Closes #11530
|
| |
|
|
|
|
| |
Adds helper functions for the copy->view transition for multi-field
indexes. Adds `structured_to_unstructured`, `apply_along_fields`,
`assign_fields_by_name`, `require_fields`.
|
| | |
|
| | |
|
| |
|
| |
Found via `codespell -q 3 -I ../numpy-whitelist.txt`
|
| | |
|
| |
|
|
| |
[ci skip]
|
| |
|
|
| |
[ci skip]
|
| |
|
|
| |
The strings in error messages were left untouched
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Viewing an ndarray as a np.recarray now automatically converts
the dtype to np.record.
This commit also fixes assignment to MaskedArray's dtype attribute,
fixes the repr of recarrays with non-structured dtype, and removes
recarray.view so that viewing a recarray as a non-structured dtype
no longer converts to ndarray type.
Fixes #3581
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In https://github.com/numpy/numpy/pull/5483, I solved the problem that a
"recarray" and a "record array" (nomenclature defined in
https://github.com/numpy/numpy/pull/5482) looked identical by making
sure that a type's subclass was listed in the repr. However, recarrays
are still represented using the function 'rec.array' even though this
function technically creates record arrays, not recarrays.
So I have updated recarray.__repr__.
Setup:
>>> a = np.array([(1,'ABC'), (2, "DEF")], dtype=[('foo', int), ('bar', 'S4')])
>>> recordarr = np.rec.array(a)
>>> recarr = a.view(np.recarray)
Behavior after https://github.com/numpy/numpy/pull/5483:
>>> recordarr
rec.array([(1, 'ABC'), (2, 'DEF')],
dtype=(numpy.record, [('foo', '<i8'), ('bar', 'S4')]))
>>> recarr
rec.array([(1, 'ABC'), (2, 'DEF')],
dtype=[('foo', '<i8'), ('bar', 'S4')])
New Behavior:
>>> recordarr
rec.array([(1, 'ABC'), (2, 'DEF')],
dtype=[('foo', '<i8'), ('bar', '|S4')])
>>> recarr
array([(1, 'ABC'), (2, 'DEF')],
dtype=[('foo', '<i8'), ('bar', 'S4')]).view(numpy.recarray)
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This commit makes changes to `__getitem__` and `__getattr__` of recarrays:
1. recarrays no longer convert string ndarrays to chararrays, and
instead simply return ndarrays of string type.
2. attribute access and index access of fields now behaves identically
3. dtype.type is now inherited when fields of structured type are accessed
Demonstration:
>>> rec = np.rec.array([('abc ', (1,1), 1), ('abc', (2,3), 1)],
... dtype=[('foo', 'S4'), ('bar', [('A', int), ('B', int)]), ('baz', int)])
Old Behavior:
>>> type(rec.foo), type(rec['foo'])
(numpy.core.defchararray.chararray, numpy.recarray)
>>> type(rec.bar), type(rec['bar']), rec.bar.dtype.type
(numpy.recarray, numpy.recarray, numpy.void)
>>> type(rec.baz), type(rec['baz'])
(numpy.ndarray, numpy.ndarray)
New behavior:
>>> type(rec.foo), type(rec['foo'])
(numpy.ndarray, numpy.ndarray)
>>> type(rec.bar), type(rec['bar']), rec.bar.dtype.type
(numpy.recarray, numpy.recarray, numpy.record)
>>> type(rec.baz), type(rec['baz'])
(numpy.ndarray, numpy.ndarray)
|
| |
|
|
|
|
|
|
|
|
|
| |
This update adds a section better describing record arrays in the user
guide (numpy/doc/structured_arrays.py).
It also corrects nomenclature, such that "structured array" refers to
ndarrays with structured dtype, "record array" refers to modified
ndarrays as created by np.rec.array, and "recarray" refers to ndarrays
viewed as np.recarray. See the note at the end of the structured
array user guide.
|
| |
|
|
| |
Now is as good a time as any with open PR's at a low.
|
| |
|
| |
The behaviour documented did not match the actual behaviour of numpy. Explanation changed and the code example updated.
|
| |
|
|
|
|
|
| |
Add `print_function` to all `from __future__ import ...` statements
and use the python3 print function syntax everywhere.
Closes #3078.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The new import `absolute_import` is added the `from __future__ import`
statement and The 2to3 `import` fixer is run to make the imports
compatible. There are several things that need to be dealt with to make
this work.
1) Files meant to be run as scripts run in a different environment than
files imported as part of a package, and so changes to those files need
to be skipped. The affected script files are:
* all setup.py files
* numpy/core/code_generators/generate_umath.py
* numpy/core/code_generators/generate_numpy_api.py
* numpy/core/code_generators/generate_ufunc_api.py
2) Some imported modules are not available as they are created during
the build process and consequently 2to3 is unable to handle them
correctly. Files that import those modules need a bit of extra work.
The affected files are:
* core/__init__.py,
* core/numeric.py,
* core/_internal.py,
* core/arrayprint.py,
* core/fromnumeric.py,
* numpy/__init__.py,
* lib/npyio.py,
* lib/function_base.py,
* fft/fftpack.py,
* random/__init__.py
Closes #3172
|
| |
|
|
|
|
|
|
| |
This should be harmless, as we already are division clean. However,
placement of this import takes some care. In the future a script
can be used to append new features without worry, at least until
such time as it exceeds a single line. Having that ability will
make it easier to deal with absolute imports and printing updates.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
