| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |\
| |
| | |
DOC: Create 1.11.2 release notes.
|
| | |
| |
| |
| | |
[ci skip]
|
| | |
| |
| |
| | |
[skip ci]
|
| |/
|
|
| |
[ci skip]
|
| | |
|
| | |
|
| |
|
|
|
| |
This is useful for things like passing ``--pdb`` to make nose drop into
a pdb post-mortem on exception.
|
| | |
|
| |
|
|
| |
Mentioned here: http://stackoverflow.com/questions/37625478/why-is-ones-like-listed-as-a-ufunc
|
| |
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
| |
Changed/corrected Time span - relative and absolute - for second, millisecond and microsecond.
There were slight differences and was noted duly in the issue. See #6711 (https://github.com/numpy/numpy/issues/6711)
|
| |
|
|
| |
[ci skip]
|
| |
|
|
| |
[ci skip]
|
| |
|
|
|
|
|
| |
I do not think that these two function are ufuncs since they do not
have an optional [, out] argument. From the doc:
- All ufuncs can also take output arguments.
|
| | |
|
| |\
| |
| | |
ENH: adds np.nancumsum and np.nancumprod
|
| | |
| |
| |
| |
| |
| |
| |
| | |
This PR adds an implementation of `nancumsum` and `nancumprod`.
The actual function is a two-liner adapted from `nansum`.
Its structure is adapted from PR: https://github.com/numpy/numpy/pull/5418/
|
| |/
|
|
| |
Space added to resolve misrendering of monospace (``) delimiters.
|
| | |
|
| |
|
|
| |
[ci skip]
|
| |\
| |
| | |
Generalized flip
|
| | | |
|
| |\ \
| | |
| | | |
DOC: add nanprod to the list of math routines
|
| | | |
| | |
| | | |
This was otherwise undocumented, so the nanprod.rst page wasn't being generated.
|
| | |/
|/| |
|
| |\ \
| | |
| | | |
DOC: understanding code and getting started section to dev doc
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | | |
development_environment.rst
Updated understanding code section in dev doc
wrapped lines, corrected grammar.
|
| |/ / |
|
| | |
| |
| | |
Docs looked funny at that point.
|
| | |
| |
| |
| |
| |
| | |
Use the simpler `git fetch; ... upstream/master` approach instead of
updating the local master branch. Keeping the local master branch
in sync with upstream is usually not necessary.
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| | |
* Drop testing of Python 2.6, 3.2, and 3.3
* Create 1.12.0-notes.rst and add to source/documentation.
* Update pavement.py to use 1.10.x as LOG_START
* Update version numpy in setup.py
|
| |\ \
| | |
| | | |
API: Make datetime64 timezone naive
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Fixes GH3290
With apologies to mwiebe, this rips out most of the time zone parsing from
the datetime64 type.
I think we mostly sorted out the API design in discussions last year, but
I'll be posting this to the mailing list shortly to get feedback.
Old behavior:
# string parsing and printing defaults to your local timezone :(
>>> np.datetime64('2000-01-01T00')
numpy.datetime64('2000-01-01T00:00-0800','h')
New behavior:
# datetime64 is parsed and printed as timezone naive
>>> np.datetime64('2000-01-01T00')
numpy.datetime64('2000-01-01T00','h')
# you can still supply a timezone, but you get a deprecation warning
>>> np.datetime64('2000-01-01T00Z')
DeprecationWarning: parsing timezone aware datetimes is deprecated; this
will raise an error in the future
numpy.datetime64('2000-01-01T00','h')
|
| | | |
| | |
| | |
| | | |
Address comments of @charris on gh-6895.
|
| | | | |
|
| | | | |
|
| | | | |
|
| |/ /
| |
| |
| | |
Also remove all mentions of setupegg.py from the documentation.
|
| | |
| |
| |
| | |
Fixes gh-7010
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Fixes GH2039
This function provides a much more intuitive interface than `np.rollaxis`,
which has a confusing behavior with the position of the `start` argument:
http://stackoverflow.com/questions/29891583/reason-why-numpy-rollaxis-is-so-confusing
It was independently suggested several times over the years after discussions
on the mailing list and GitHub (GH2039), but never made it into a pull request:
https://mail.scipy.org/pipermail/numpy-discussion/2010-September/052882.html
My version adds support for a sequence of axis arguments. I find this behavior
to be very useful. It is often more intuitive than supplying a list of
arguments to `transpose` and also nicely generalizes NumPy's existing axis
manipulation routines, e.g.,
def transpose(a, order=None):
if order is None:
order = reversed(range(a.ndim))
return moveaxes(a, order, range(a.ndim))
def swapaxes(a, axis1, axis2):
return moveaxes(a, [axis1, axis2], [axis2, axis1])
def rollaxis(a, axis, start=0):
if axis < start:
start -= 1
return moveaxes(a, axis, start)
|
| | | |
|
| | |
| |
| |
| | |
[ci skip]
|
| | |
| |
| |
| | |
[ci skip]
|
| | |
| |
| | |
This looks more conventionnal
|
| |\ \
| | |
| | | |
DOC: fix method signatures in "array subclasses"
|
| | | |
| | |
| | |
| | |
| | |
| | | |
* Change ".. function::" -> ".. method::"
* Remove "self" argument
* Change "self" to "obj" in __array_finalize__
|
| | | | |
|
| |/ /
| |
| |
| |
| |
| |
| | |
We used to use ``rank`` to mean the number of axes in an array, but no
more. Change these uses of rank to refer to dimensions.
Closes gh-6839
|
| |\ \
| | |
| | | |
[doc] Fix title of governance section in docs
|
