| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| |
|
|
| |
Made conformant with the standards of scipy.
|
| |
|
|
| |
Run autopep8 on the tests and fixup the results.
|
| |
|
|
|
|
|
| |
Run the 2to3 ws_comma fixer on *.py files. Some lines are now too long
and will need to be broken at some point. OTOH, some lines were already
too long and need to be broken at some point. Now seems as good a time
as any to do this with open PRs at a minimum.
|
| |
|
|
|
|
|
|
| |
The companion matrices returned by the various polynomial types was
a scalar in the degree one case instead of a 2-D array. Fix that and
add a test to check for that result.
Closes #3459.
|
| |
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In python3 range is an iterator and `xrange` has been removed. This has
two consequence for code:
1) Where a list is needed `list(range(...))` must be used.
2) `xrange` must be replaced by `range`
Both of these changes also work in python2 and this patch makes both.
There are three places fixed that do not need it, but I left them in
so that the result would be `xrange` clean.
Closes #3092
|
| |
|
|
|
|
| |
The test uses the complex set of sample points [1, 1j, -1, -1j] whose
squared sum is exactly zero. This would fail before the column scaling
was fixed.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The original masked-NA-NEP branch contained a large number of changes
in addition to the core NA support. For example:
- ufunc.__call__ support for where= argument
- nditer support for arbitrary masks (in support of where=)
- ufunc.reduce support for simultaneous reduction over multiple axes
- a new "array assignment API"
- ndarray.diagonal() returning a view in all cases
- bug-fixes in __array_priority__ handling
- datetime test changes
etc. There's no consensus yet on what should be done with the
maskna-related part of this branch, but the rest is generally useful
and uncontroversial, so the goal of this branch is to identify exactly
which code changes are involved in maskna support.
The basic strategy used to create this patch was:
- Remove the new masking-related fields from ndarray, so no arrays
are masked
- Go through and remove all the code that this makes
dead/inaccessible/irrelevant, in a largely mechanical fashion. So
for example, if I saw 'if (PyArray_HASMASK(a)) { ... }' then that
whole block was obviously just dead code if no arrays have masks,
and I removed it. Likewise for function arguments like skipna that
are useless if there aren't any NAs to skip.
This changed the signature of a number of functions that were newly
exposed in the numpy public API. I've removed all such functions from
the public API, since releasing them with the NA-less signature in 1.7
would create pointless compatibility hassles later if and when we add
back the NA-related functionality. Most such functions are removed by
this commit; the exception is PyArray_ReduceWrapper, which requires
more extensive surgery, and will be handled in followup commits.
I also removed the new ndarray.setasflat method. Reason: a comment
noted that the only reason this was added was to allow easier testing
of one branch of PyArray_CopyAsFlat. That branch is now the main
branch, so that isn't an issue. Nonetheless this function is arguably
useful, so perhaps it should have remained, but I judged that since
numpy's API is already hairier than we would like, it's not a good
idea to add extra hair "just in case". (Also AFAICT the test for this
method in test_maskna was actually incorrect, as noted here:
https://github.com/njsmith/numpyNEP/blob/master/numpyNEP.py
so I'm not confident that it ever worked in master, though I haven't
had a chance to follow-up on this.)
I also removed numpy.count_reduce_items, since without skipna it
became trivial.
I believe that these are the only exceptions to the "remove dead code"
strategy.
|
| | |
|
| |
|
|
|
|
|
| |
There are currently errors that will be fixed if pull #178 goes in.
The tests were also changed to use generators, which makes them
run noticeably slower but give better error messages and makes the
tests a bit cleaner.
|
| | |
|
| |
|
|
|
|
|
| |
A new test file, test_classes, has been added so that conversions
between all the class types can be tested. Several tests common to
all the classes were also moved to this file. Ideally all the common
tests will be moved, but that isn't done yet.
|
| |
|
|
|
| |
Test the multi-dimensional coefficient array functionality.
Reorganize and cleanup some previous tests.
|
| |
|
|
| |
The coefficients used were [1] + [0]*i instead of [0]*i + [1].
|
| |
|
|
| |
run as script.
|
| |
|
|
| |
Fix some documentation.
|
| |
|
|
|
|
| |
Remove checks that prevent use of foreign scalar types for lower
bounds and integration constants.
Cleanup code a bit.
|
| | |
|
| |
|
|
| |
much like a ufunc and a bit vague.
|
| |
|
|
| |
Chebyshev.fit and Polynomial.fit. Document the change from numpy 1.4.x.
|
| |
|
|
|
|
| |
polynomial.Polynomial. This method behaves like truncate except
it takes the degree of the result instead of the number of
coefficients.
|
| |
|
|
|
| |
On second thought it was a bad idea to make such a radical change to existing
behaviour. It was also hard to document the variations ;)
|
| |
|
|
|
|
|
|
|
| |
Chebyshev and Polynomial classes to None. Add 'default' as a possible
value of the domain argument to specify the default domain. This change
fits better with my experience with this method. I feel it is safe to
make this change at this late date because the functions seem little
used as yet and I would like to get them 'right' before folks catch on
to their presence.
|
| |
|
|
|
|
| |
to take degree instead of length. This seems to fit better with normal
usage. I feel this change is safe at this time because these new classes
seem to be little used as yet.
|
| | |
|
| |
|
|
|
|
|
| |
1) Let {poly,cheb}int accept 0 for the number of integrations.
2) Let {poly,cheb}(int,der} accept floating integers for number
of integrations or derivations, raise ValueError otherwise.
3) Add tests for same.
|
| |
|
|
| |
Polynomial classes.
|
| | |
|
| | |
|
|
|
New modules chebyshev and polynomial are added. The new polynomial module
is not compatible with the current polynomial support in numpy, but is much
like the new chebyshev module. The most noticeable difference to most will
be that coefficients are specified from low to high power, that the low
level functions do *not* accept the Chebyshev and Polynomial classes as
arguements, and that the Chebyshev and Polynomial classes include a domain.
Mapping between domains is a linear substitution and the two classes can be
converted one to the other, allowing, for instance, a Chebyshev series in
one domain to be expanded as a polynomial in another domain.
The new modules are not automatically imported into the numpy namespace,
they must be explicitly brought in with a "import numpy.polynomial"
statement.
|
