| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
| |
These ones just generated warnings, not build failures
|
| |
|
| |
|
| |
|
|\
| |
| | |
MAINT: Unify polynomial power functions
|
| |
| |
| |
| |
| |
| | |
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
|
|\ \
| |/
|/| |
|
| |\
| | |
| | | |
MAINT: Unify polynomial fitting functions
|
| |\ \
| | | |
| | | | |
MAINT: Unify polynomial addition and subtraction functions
|
| |\ \ \
| | | | |
| | | | | |
MAINT: Unify polydiv
|
| |\ \ \ \
| | | | | |
| | | | | | |
MAINT: Unify polynomial valnd functions
|
| |\ \ \ \ \
| | | | | | |
| | | | | | | |
MAINT: deduplicate fromroots in np.polynomial
|
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
functions
One was missing from gh-13079
|
| |_|_|_|_|/
|/| | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
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.
|
| |_|/
|/| |
| | |
| | |
| | | |
This makes the variable names in polydiv and chebdiv match polyutils._div.
It also brings the order of the special-casing in line to match.
|
| |/
|/|
| |
| | |
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.
|
|
|
|
|
|
|
|
|
|
|
| |
This previously:
* Did not indicate the arguments in the abstract methods
* Did not actually use the `abc` mechanism at all on python 3 (`__metaclass__` does not work any more)
* Used the now-deprecated `@abstractproperty`
This didn't cause any runtime problems, but does confuse LGTM, and was using the `abc` module incorrectly.
This uses python3-only features of the abc module, so can't be backported.
|
|\
| |
| | |
BUG: polyval returned non-masked arrays for masked input.
|
| |
| |
| |
| |
| |
| |
| |
| | |
This fix will preserve subtypes of ndarray when given as input (x)
to the polyval function. In particular, the results for masked
values of a masked array will be masked.
Fixes #2477.
|
| |
| |
| |
| |
| |
| |
| |
| | |
* 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
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
(#12448)
* Review F401,F841,F842 flake8 errors (unused variables, imports)
* Review comments
* More tests in test_installed_npymath_ini
* Review comments
|
|/ |
|
| |
|
|
|
|
|
|
| |
This variable is never used, and shows signs of being leftover from a previous implementation.
Introduced in gh-11528. Closes gh-11842
|
|\
| |
| | |
DOC: add comment to remove fn after python 2 support is dropped
|
| | |
|
|\ \
| | |
| | | |
MAINT, DOC: Replace 'an' by 'a' in some docstrings.
|
| | |
| | |
| | |
| | |
| | |
| | | |
[ci skip]
Small fixes in the polynomial package.
|
|\ \ \
| |/ /
|/| | |
TST: add missing tests for all polynomial subclass pow fns.
|
| | | |
|
| |/ |
|
|\ \
| | |
| | | |
DOC: add examples and extend existing dos for polynomial subclasses
|
| |/ |
|
|/
|
|
|
|
|
|
|
|
|
|
|
|
| |
* Add augmented assignment for supported operations
Add augmented assignments for `+=`, `-=`, `*=`, `/=`, `%=`, and `**=`.
* correct idiv and imod
* remove augomented operationa. add notes.
Explicitly state the intention that all instances of a polynomial baseclass are immutable.
* fix typo, remove Note from _polybase
|
|
|
|
|
| |
* Remove misleading reference to numpy/polynomial/polynomial/polyfit.
* Add missing period in numpy/polynomial/_polybase.py
|
|
|
|
|
|
|
|
|
|
| |
* DOC: reccomend polynomail.Polynomial over np.polyfit
* update from review
* update from review, fix links
* fix from review
|
|\
| |
| | |
ENH: Add support for ipython latex printing to polynomial
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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
|
|/ |
|
|
|
|
|
|
|
|
| |
unnecessary import dependencies
pytesttester is used by every single subpackage, so making it depend on np.testing just creates cyclic dependencies that can lead to circular imports
Relates to #11457
|
| |
|
| |
|
| |
|
|
|
|
|
| |
That function is nose specific and has not worked since `__init__` files
were added to the tests directories.
|
|
|
|
|
|
|
|
| |
Numpy can now be tested using the standard
`python -c"import numpy; numpy.test()"`
construct.
|