| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
| |
Add missing closing brackets, script to generate the list in the PR gh-16051.
|
|
|
| |
* DOC: Refactor polynomial docs using automodule.
|
| |
|
|
|
|
|
| |
As numpy is Python 3 only, these import statements are now unnecessary
and don't alter runtime behavior.
|
|
|
|
|
|
|
|
| |
the vander2d and vander3d functions
The generalization is not exposed in the public API yet, but it could be if the need arises.
The shape / dtype conversion logic is left as is for now, even if it might be broken.
|
| |
|
|
|
|
| |
These ones just generated warnings, not build failures
|
| |
|
| |
|
|
|
|
|
|
| |
These power functions are all the same - the algorithm used does not care about the basis.
`polypow` and `chebpow` have some optimizations in their versions, which this maintains
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This changes the behavior for:
* The `deg` and `axis` arguments of `<type>der`
* The `deg` and `axis` arguments of `<type>int`
* The `deg` argument of `<type>gauss`
* The `deg` argument of `<type>vander2d`
* The `deg` argument of `<type>vander3d`
The old behavior was:
* Raise `ValueError` if the argument is a float, but not an integral one
* Allow a float like `1.0` to mean `1`.
This is inconsistent with most other integer-accepting APIs in numpy, which require these to be actual integers, and raise TypeError when they are not.
The new behavior is:
* Raise `TypeError` if the argument is a float, but not an integral one
* Emit a `DeprecationWarning` if a float like `1.0` is passed, continuing to allow it its old meaning.
|
|
|
|
|
|
|
|
|
|
| |
These fitting functions are all the same - the algorithm used does not care about the basis.
This was done using:
* A regex find / replace on all but poly and cheb
* A manual diff showing that cheb differed only by whitespace
* A manual diff showing that poly differed in `deg.ndim == 1` vs `deg.ndim > 0`.
Given that this function only allows `deg.ndim <= 1`, and `ndim >= 0`, these two comparison are equivalent.
|
|
|
|
| |
These functions are all the same - the algorithm used does not care about the basis.
|
|
|
|
|
|
| |
These division functions are all the same - the algorithm used does not care about the basis.
Note that while chebdiv and polydiv could be implemented in terms of this function, their current implementations are more optimal and exploit the properties of a multiplication by a basis polynomial.
|
|
|
|
| |
No point writing the same function 12 times, when you can write it once
|
|
|
|
|
|
| |
Every implementation is the same right now, other than calling different line / mul functions.
Found by LGTM.
|
|
|
|
|
|
|
| |
Every implementation is the same right now, other than calling a different `*vander` function.
Merging these into a single private function taking a callback results in significant deduplication.
Found by LGTM.
|
|
|
|
|
|
|
|
| |
* ported the refguide_check module from SciPy for usage
in NumPy docstring execution/ verification; added the
refguide_check run to Azure Mac OS CI
* adjusted NumPy docstrings such that refguide_check passes
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Choices made, and the alternatives rejected (for no particularly strong reason):
1. Show terms in ascending order, to match their internal representation
* alternative: descending, to match convention
2. Shows 0 terms in gray
* alternative: omit entirely
* alternative: show normally to aid comparison
3. Write each term as `basis(ax + b)
* alternative: write as `basis(u) ... where u = ax + b`
* alternative: show the normalized polynomial
In future it would perhaps make sense to expose these options to the end user
|
| |
|
|
|
|
|
|
|
| |
It was not being checked that the `lbnd` and `scl` parameters were
scalars as required.
Closes #9901.
|
| |
|
| |
|
|
|
|
|
|
| |
so it actually displays in the docs
[skip ci]
|
|
|
|
|
| |
Also add a hint to the documentation advising the use of moveaxis over rollaxis.
Tests for rollaxis are left alone.
|
|
|
|
| |
Bare except is very rarely the right thing
|
|
|
|
|
|
|
| |
As a result, some exceptions change from ValueError to IndexError
This also changes the exception types raised in places where
normalize_axis_index is not quite appropriate
|
|
|
|
|
|
| |
- Fixes documentation of polynomial types `*vander2d()` methods to give the
correct last index of the pseudo-Vandermonde matrix returned expressed in
terms of x and y.
|
|
|
|
|
|
|
| |
In Python 3.6 a number of escape sequences that were previously accepted
-- for instance "\(" that was translated to "\\(" -- are deprecated. To
retain the previous behavior either raw strings must be used or the
backslash must be properly escaped itself.
|
| |
|
|
|
|
| |
The strings in error messages were left untouched
|
| |
|
|
|
|
|
|
|
| |
* Rewrite the documentation for `deg`.
* Check that the passed degrees are int and raise if not.
* Do not accept `deg` arguments that do not convert as 0-D or 1-D.
* Sort passed degree terms for repeatability.
|
|
|
|
|
|
|
|
|
|
| |
The argument `deg` is enhanced to allow an
array_like argument to past which specifies
which terms to include in the fit.
The returned coef array is exapnded to have
entries of 0 for all coefficients which were
not included in the fit.
|
| |
|
|
|
|
| |
Detected by pyflakes.
|
|
|
|
|
| |
The rather lax standards used in scipy were used to identify the
needed style fixups.
|
|\
| |
| | |
DOC: remove obsolete NA reference from polyfit docs
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Move the class documentation to the place of definition in the
appropriate module. This allow for documenting the specific series kind
along with the series specific default domains and windows
Remove template placeholders from the ABCPolyBase class documention.
General fixup of documentation that rendered poorly.
|
|/
|
|
|
|
|
|
| |
The new base is ABCPolyBase and is intended to replace the use of the
polytemplate string. In this way the need to compile the polynomial
classes on import is avoided.
Closes #634. Closes #3639.
|
|
|
|
|
|
|
| |
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.
|
|\
| |
| | |
DOC: Formatting fixes using regex
|
| |
| |
| |
| | |
also other spacing or formatting mistakes
|
|/
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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 changes the `exec` command to the `exec` function.
|
|
|
|
|
|
|
|
|
|
| |
Instead of
if lhs.dtype.char in np.typecodes['Complex']:
use
if issubclass(lhs.dtype.type, np.complexfloating):
|