| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
| |
A 'symbol' argument was added in ABCPolyBase in 1.24 and documented there, but
the docstrings for derived classes (e.g., Polynomial) were not updated.
|
|
|
|
|
|
|
|
|
| |
The meaning of the second argument in the mathematical notation
N(mu, b) for the normal distribution is not consistent. In some
references it is the variance while in others it is the standard
deviation. Let's avoid the ambiguity by not using the notation.
Fixes #21296
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
* limit the number of decimals in Polynomial representation
* tests pass
* parenthesize exponential notation in polynomials
* fixed a long line warning
* added polynomial printoptions tests
* polynomial printoptions typo fixed
* made switch to exp notation in polynomial display more natural
* added a test on switching polynomials to exp notation
* fixed linter errors/warnings
* support for nanstr and infstr printoptions in polynomials
* 10^8 threshold for switching to exp notation when displaying polynomials
* merged in PR #21696 fixing issue #21695
* made linter happy
* made some docstring tests pass
* fixed the docs
Co-authored-by: Lev Maximov <lev.maximov@gmail.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
From my regular expression foo, those are the only 9 case whereas there
are about ~2000 usage that do not have spaces.
While this is ok with docutils/sphinx, it does not seem to be
documented, and that means that other parsers will see that as comments,
leading to for example improper syntax highlighting.
This make it also a tiny bit harder to develop alternative rst parsers.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Fixes #19897
The 2nd return value of the following methods/functions were badly
formatted and the list was all appearing in a single line. Changed them
to separate points which are rendered nicely.
- numpy.polyfit
- numpy.ma.polyfit
- numpy.polynomial.polynomial.polyfit
- numpy.polynomial.polynomial.Polynomial.fit
- numpy.polynomial.chebyshev.chebfit
- numpy.polynomial.chebyshev.Chebyshev.fit
- numpy.polynomial.hermite.hermfit
- numpy.polynomial.hermite.Hermite.fit
- numpy.polynomial.hermite_e.hermefit
- numpy.polynomial.hermite_e.HermiteE.fit
- numpy.polynomial.laguerre.lagfit
- numpy.polynomial.laguerre.Laguerre.fit
- numpy.polynomial.legendre.legfit
- numpy.polynomial.legendre.Legendre.fit
Also fixed erroneous links to `numpy.full` which were actually referring
to the `full` argument. Changed those to code strings (double backticks)
from single backticks.
Also fixed formatting issues in the 3rd return value of numpy.polyfit
(and hence also numpy.ma.polyfit).
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
* DOC: Adjust polyfit doc to clarify the meaning of w
cov='unscaled', in particular, had inconsistently referred to a weight
of 1/sigma**2, while the doc for w says it should be equal to 1/sigma.
This change clarifies w to comport with more typical meanings of
weights in weighted least squares, and makes clear that cov='unscaled'
is appropriate when the weight w**2 = 1/sigma**2.
See Issue #5261 for more discussion of the errors/confusion in
the previous doc string.
* Update doc text for w in all polynomial module fit functions
Co-authored-by: Stefan van der Walt <sjvdwalt@gmail.com>
Co-authored-by: Ross Barnowski <rossbar@berkeley.edu>
|
|
|
|
|
| |
Single backticks default role is reference, while here it seem to be for
verbatim. Fix it in a couple of places.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This update a coupe of references (single backticks) that actually are not to
verbatim/code (double backticks); and a couple of verbatim to reference
when they do actually exists and can be resolved in context.
I probably missed other; and stayed simple but spoted a few other
inconsistencies that I did not fix:
- some ``...`` could actually be :math:`...` but not always clear if
it would be better.
- some intervals are [``...``], other are ``[...]``
I guess they could be discussed individually; it was mostly the failing
references that bothered me.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
* MAINT: Remove nickname from polynomial classes.
The convenience classes derived from ABCPolyBase had a nickname
attribute that was only used internally in the previous
implementation of __str__. After the overhaul of __str__ in #15666,
this attr is no longer used.
* DOC: Add release note.
Add release note to notify users of removal of the abstract
property, and highlight users that may be affected by the
change.
* DOC: fixed rST in release note
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Changes the printing style of instances of the convenience classes in
the polynomial package to a more "human-readable" format.
__str__ has been modified and __format__ added to ABCPolyBase, modifying
the string representation of polynomial instances, e.g. when printed.
__repr__ and the _repr_latex method (which is used in the Jupyter
environment are unchanged.
Two print formats have been added: 'unicode' and 'ascii'. 'unicode' is
the default mode on *nix systems, and uses unicode values for numeric
subscripts and superscripts in the polynomial expression. The 'ascii'
format is the default on Windows (due to font considerations) and uses
Python-style syntax to represent powers, e.g. x**2. The default
printing style can be controlled at the package-level with the
set_default_printstyle function.
The ABCPolyBase.__str__ has also been made to respect the linewidth
printoption. Other parameters from the printoptions dictionary are not
used.
Co-Authored-By: Warren Weckesser <warren.weckesser@gmail.com>
Co-authored-by: Eric Wieser <wieser.eric@gmail.com>
|
|
|
| |
* 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 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.
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
| |
* 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
|
|
|
|
|
|
| |
[ci skip]
Small fixes in the polynomial package.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
| |
Found via `codespell`
|
|
|
|
|
|
|
| |
It was not being checked that the `lbnd` and `scl` parameters were
scalars as required.
Closes #9901.
|
| |
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
|
| |
Simplify the logic a bit and make behavior consistent with polyval.
Note that this adds a check that the number of dimensions of the
array of the evaluation points is less than the number of dimensions of
the array of roots when tensor=False. That check is missing from polyval
and needs to be added.
|
|
|
|
|
|
|
|
|
|
|
| |
As one can easily encounter when working with high-order signal processing
filters, converting a high-order polynomial from its roots to its polynomial
coefficients can be quite lossy, leading to inaccuracies in the filter's
properties.
This PR adds a new function, `polyrootval` - based on `polyval` - that
evaluates a polynomial given a list of its roots. The benefit of calculating it
this way can be seen at scipy/scipy:6059. Some tests are included, as well.
|
|
|
|
|
|
|
| |
* 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.
|
|\
| |
| | |
Pep8 numpy polynomial
|