| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| |
|
|
|
|
|
| |
Makes the identity check `a = np.array([np.nan], dtype=object)`
`a == a`, etc. a deprecation/futurewarning instead of just
changing it.
Also fixes some smaller things.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This means that for example broadcasting errors get raised.
The array_equiv function is changed to explicitely test
if broadcasting is possible. It may be nice to do this
test differently, but I am not sure if that is possible.
Create a FutureWarning for comparisons to None, which
should result in areal elementwise (object) comparisons.
Slightly adepted a wrong test.
Poly changes: Some changes in the polycode was necessary,
the one is probably a bug fix, the other needs to be
thought over, since len check is not perfect maybe, since
it is more liekly to raise raise an error.
Closes gh-3759 and gh-1608
|
| |
|
|
|
| |
The use of polytemplate is deprecated, this fix is only for a backport
if needed.
|
| |
|
|
| |
Make the version of its removal Numpy 1.10.0.
|
| |
|
|
|
|
|
|
|
|
| |
Because neither poly1d nor the Polynomial package polynomial classes are
immutable, hence not reliably hashable, they should signal that by
setting __hash__ = None. This also fixes the warning
Overriding __eq__ blocks inheritance of __hash__ in 3.x
that is given when the command `python2.7 -3 -c"import numpy"` is run.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This bug affected the various polynomial class methods fromroots due to
the ability to specify both window and domain. In that circumstance the
roots are mapped from the domain to the window by the substitution
`x = off + scl*x`. The polynomial that was being generated was monic in
the window before substitution, but if scl was not one it was not monic
considered as a function of the variable x in the domain. The fix is to
divide the generated coefficients by `scl ** deg` so that the scaling of
the highest degree term after substitution is canceled.
It might be better to make the scaling optional in the future, but this
fix makes the result match the documentation.
Closes #3467.
|
| |
|
|
|
|
|
| |
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.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
| |
In particular for arithmetic where one could end up with a Polynomial
type with Chebyshev coefficients after an addition. It is unlikely that
that would be done on purpose.
The PolyDomain error message was also replaced by a TypeError with
an appropriate message. That seems like a better choice.
|
| |
|
|
|
|
|
|
|
|
|
| |
This works around changes in the treatment of __array_priority__ that
were part of commit 32b32c2. Previously the rop's of the right hand
object were called whenever it had the __array_priority__ attribute
and was not an ndarray or derived thereof. After the change the
object needed to have greater priority, in this case > 0. It isn't
clear that the new behavior is the correct one and if it is reverted
then setting __array_priority__ back to 0 will provide a test for that
decision.
|
| |
|
|
|
|
|
|
|
| |
The new basis method is a convenient way to return an instance of the basis
function of given degree for the class. It is intended mostly for
pedagogical purposes.
The new cast method provides an alternate way to convert an instance of one
polynomial class to another. It complements the convert instance method.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
| |
Also:
1. Note that the polynomial package is preferred over poly1d.
2. Remove deprecation of mapparms in __init__.py as it interferes with the
documention of the method of the same name. This is probably safe as it
is unlikely to be used yet.
3. Make some improvements to the documentation in polytemplate.
|
| |
|
|
|
|
| |
mappings for the Hermite and Laguerre polynomials where the domains have
infinite bounds. The window allows one to specify the interval that the
domain maps to instead of using the default domain as was done before.
|
| | |
|
| | |
|
| |
|
|
|
|
| |
Conflicts:
numpy/polynomial/chebyshev.py
numpy/polynomial/polynomial.py
|
| | |
|
| |
|
|
| |
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.
|
| |
|
|
| |
Polynomial classes to reflect the enhanced behaviour of the base functions.
|
| |
|
|
|
|
| |
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.
|
| | |
|
| | |
|
| |
|
|
| |
Polynomial classes.
|
| | |
|
| | |
|
| |
|
|
| |
Chebyshev.
|
| |
|
|
| |
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.
|
