summaryrefslogtreecommitdiff
path: root/numpy/lib/function_base.py
Commit message (Collapse)AuthorAgeFilesLines
* MAINT: Fix some typos in a code string and commentsDongjoon Hyun2016-01-271-2/+2
|
* DOC, MAINT: Enforce np.ndarray arg for np.put and np.placegfyoung2016-01-141-1/+5
| | | | | | | np.put and np.place do something only when the first argument is an instance of np.ndarray. These changes will cause a TypeError to be thrown in either function should that requirement not be satisfied.
* DOC: Update trapz docstring.Charles Harris2016-01-091-3/+5
| | | | [ci skip]
* DOC: fix typos in trapz()François Boulogne2016-01-091-1/+1
| | | | [ci skip]
* DOC: Use print only as function when print_function is imported from __future__gfyoung2015-12-191-4/+4
| | | | Closes gh-6863.
* DOC, MAINT: Fix the numpy.ma.cov signature and documentation.jason king2015-12-181-6/+7
| | | | The rowvar and bias parameters are booleans, not integers.
* DEP: Stricter arg checking for array orderinggfyoung2015-12-181-4/+6
| | | | | | | | | | | | | The bug traces to the PyArray_OrderConverter method in conversion_utils.c, where no errors are thrown if the ORDER parameter passed in is not of the string data-type or has a string value of length greater than one. This commit causes a DeprecationWarning to be raised, which will later be turned into a TypeError or another type of error in a future release. Closes gh-6598.
* Updated typos in histogram bin estimator equationsMad Physicist2015-12-111-2/+2
| | | In all cases, it's either ...*n^(-1/3) or .../n^(1/3), not both. The actual functions are implemented correctly.
* BUG, MAINT: check that histogram range parameters are finite, add tests to ↵lzkelley2015-11-171-3/+10
| | | | assure this. Improved some error-types.
* BUG: Make median work for empty arrays (issue #6462)Ethan Kruse2015-10-211-1/+1
| | | | | np.median([]) returns NaN. Fixes bug/regression that raised an IndexError. Added tests to ensure continued support of empty arrays.
* DOC: fix var. reference in percentile docstringTobias Megies2015-10-071-1/+1
| | | | | | | The argument for the original input array is named `a` but in the docstring it was at some point referred to as `arr`. [skip ci]
* Merge pull request #6411 from larsmans/cov-memory-useCharles Harris2015-10-051-2/+2
|\ | | | | ENH: speed up cov by ~10% for large arrays
| * ENH: speed up cov by ~10% for large arraysLars Buitinck2015-10-051-2/+2
| | | | | | | | Replaces n² divisions by one division and n² multiplications.
* | Merge pull request #6396 from rudimeier/opt-corrcoefCharles Harris2015-10-051-1/+5
|\ \ | | | | | | MAINT: corrcoef, memory usage optimization
| * | MAINT: corrcoef, memory usage optimizationRuediger Meier2015-09-301-1/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We calculate sqrt on the small vector rather than on that huge product matrix and we combine the "outer" product with element-wise devision. So even though we have a slower loop over the rows now ... this code snippet runs about 3 times faster than before. However the speed improvement of the whole function is not really significant because cov() takes 80-99% of the time (dependent on blas/lapack implementation and number of CPU cores). More important is that we will safe 1/3 memory. For example corrcoef() for a [23k, m] matrix needs 8GB now instead of 12GB.
* | | Merge pull request #6403 from larsmans/cov-memory-useJaime2015-10-041-1/+3
|\ \ \ | | |/ | |/| ENH: halve the memory requirement of np.cov
| * | ENH: halve the memory requirement of np.covLars Buitinck2015-10-041-1/+3
| | | | | | | | | | | | | | | | | | | | | Prevents allocation of an n²-sized array. XXX For large arrays, multiplying by 1/fact is more than 10% faster than dividing by fact, but that doesn't pass the tests.
* | | DOC: typo: affectLars Buitinck2015-10-021-3/+3
|/ /
* | DOC: numpy.diff docstring changed as per recommendation onjason king2015-09-161-4/+5
|/ | | | | | https://github.com/numpy/numpy/issues/5900 Slight change for cumsame doco as well, to match.
* ENH: gradient takes axis keyword, added release note commentMaximilian Trescher2015-09-061-4/+6
|
* possibility to calculate gradient over specific axes instead of all axesMaximilian Trescher2015-09-031-5/+35
| | | | when given axis=None, behave the same as axis not being provided
* ENH: Adding in automatic number of bins estimation for np.histogram. Users ↵Varun Nayyar2015-08-151-1/+170
| | | | can now pass in bins='auto' (or 'scott','fd','rice','sturges') and get the corresponding rule of thumb estimator provide a decent estimate of the optimal number of bins for the given the data.
* BUG: fixed regression in np.histogram which caused input floating-point ↵Thomas Robitaille2015-07-271-1/+1
| | | | values to be modified
* ENH: Faster algorithm for computing histograms with equal-size binsThomas Robitaille2015-07-231-26/+82
|
* DOC: Fix docstring warnings in documetation generation.Charles Harris2015-07-011-6/+12
| | | | | | | | | | | | Most of these fixes involve putting blank lines around .. versionadded:: x.x.x and .. deprecated:: x.x.x Some of the examples were also fixed.
* Moving warning outside of for loop.empeeu2015-06-221-4/+4
|
* BUG: Added proper handling of median and percentile when nan's are present ↵empeeu2015-06-221-26/+92
| | | | | | in array to close issue #586. Also added unit tests.
* DOC: Update docs.Gabor Kovacs2015-06-211-4/+4
| | | | | | | Update docs for boolean array indexing and nonzero order. Add links to row-major and column-major terms where they appear. Closes #3177
* MAINT: Mark deprecation warning with a date and Numpy version.Charles Harris2015-06-211-0/+8
| | | | | | This is to make it easier to find and remove deprecated features. It would be a good idea if all deprecations were made with similar comments.
* Merge pull request #5893 from stefanv/hannNathaniel J. Smith2015-05-181-1/+1
|\ | | | | DOC: Fix spelling of Von Hann's surname
| * DOC: Fix spelling of Von Hann's surnameStefan van der Walt2015-05-181-1/+1
| |
* | MAINT: Simplify code in cov function a bit.Charles Harris2015-05-131-6/+5
| |
* | Merge pull request #4960 from tpoole/weighted_covCharles Harris2015-05-131-31/+104
|\ \ | | | | | | ENH: add a weighted covariance calculation.
| * | ENH: add 'fweights' and 'aweights' arguments to covariance calculations.tpoole2015-05-131-31/+104
| |/ | | | | | | | | 'fweights' allows integer frequencies to be specified for observation vectors, and 'aweights' provides a more general importance or probabalistic weighting.
* | Merge pull request #5605 from shoyer/stackCharles Harris2015-05-121-1/+1
|\ \ | |/ |/| ENH: add np.stack
| * ENH: add np.stackStephan Hoyer2015-05-111-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The motivation here is to present a uniform and N-dimensional interface for joining arrays along a new axis, similarly to how `concatenate` provides a uniform and N-dimensional interface for joining arrays along an existing axis. Background ~~~~~~~~~~ Currently, users can choose between `hstack`, `vstack`, `column_stack` and `dstack`, but none of these functions handle N-dimensional input. In my opinion, it's also difficult to keep track of the differences between these methods and to predict how they will handle input with different dimensions. In the past, my preferred approach has been to either construct the result array explicitly and use indexing for assignment, to or use `np.array` to stack along the first dimension and then use `transpose` (or a similar method) to reorder dimensions if necessary. This is pretty awkward. I brought this proposal up a few weeks on the numpy-discussion list: http://mail.scipy.org/pipermail/numpy-discussion/2015-February/072199.html I also received positive feedback on Twitter: https://twitter.com/shoyer/status/565937244599377920 Implementation notes ~~~~~~~~~~~~~~~~~~~~ The one line summaries for `concatenate` and `stack` have been (re)written to mirror each other, and to make clear that the distinction between these functions is whether they join over an existing or new axis. In general, I've tweaked the documentation and docstrings with an eye toward pointing users to `concatenate`/`stack`/`split` as a fundamental set of basic array manipulation routines, and away from `array_split`/`{h,v,d}split`/`{h,v,d,column_}stack` I put this implementation in `numpy.core.shape_base` alongside `hstack`/`vstack`, but it appears that there is also a `numpy.lib.shape_base` module that contains another larger set of functions, including `dstack`. I'm not really sure where this belongs (or if it even matters). Finally, it might be a good idea to write a masked array version of `stack`. But I don't use masked arrays, so I'm not well motivated to do that.
* | DOC, MAINT: fix typo in np.insert docstringFrançois Magimel2015-04-131-0/+1
| |
* | DOC: Docstring of gradient() functionHelder Oliveira2015-04-091-3/+3
| | | | | | | | Updating of docstring of gradient() function specifying the return is a `list` of `ndarray`.
* | DOC: Return of gradient() functionHelder Cesar2015-04-051-0/+4
| | | | | | This is an improve of documentation for gradient() funcion as commented in #5628
* | ENH: deprecate bias and ddof arguments to corrcoefMatthew Brett2015-03-151-17/+22
| | | | | | | | | | | | | | The bias and ddof arguments had no effect on the calculation of the correlation coefficient because the value cancels in the calculation. Deprecate these arguments to np.corrcoef and np.ma.corrcoef.
* | DOC: fix typos in corrcoef()Martin Spacek2015-02-251-2/+2
|/
* MAINT: merge _compiled_base module into multiarrayJulian Taylor2015-01-221-3/+3
| | | | Allows access to internal functions for the file.
* DOC : move shape to front to match rest of docsThomas A Caswell2014-12-121-4/+4
|
* DOC : do not abuse enumeration for return typesThomas A Caswell2014-12-121-4/+4
| | | | | change '{ndarray, float}' -> 'ndarray or float' as {} are for when the value is an enumeration
* Merge pull request #5214 from mkowoods/np.averageJulian Taylor2014-10-271-3/+2
|\ | | | | | | Update to average calculation
| * BUG: upcast weights to average result type to avoid inaccuraciesMalik Woods2014-10-271-3/+2
| | | | | | | | closes gh-5202
* | Merge pull request #5203 from njsmith/masterCharles Harris2014-10-211-1/+2
|\ \ | | | | | | BUG: copy inherited masks in MaskedArray.__array_finalize__
| * | BUG: copy inherited masks in MaskedArray.__array_finalize__Nathaniel J. Smith2014-10-211-1/+2
| |/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Previously, operations which created a new masked array from an old masked array -- e.g., np.empty_like -- would tend to result in the new and old arrays sharing the same .mask attribute. This leads to horrible brokenness in which writes to one array affect the other. In particular this was responsible for part of the brokenness that @jenshnielsen reported in gh-5184 in which np.gradient on masked arrays would modify the original array's mask. This fixes the worst part of the issues addressed in gh-3404, though there's still an argument that we ought to deprecate the mask-copying behaviour entirely so that empty_like returns an array with an empty mask. That can wait until we find someone who cares though. I also applied a small speedup to np.gradient (avoiding one copy); previously this inefficiency was masking (heh) some of the problems with masked arrays, so removing it is both an optimization and makes it easier to test that things are working now.
* | Merge branch 'master' of https://github.com/numpy/numpy into interp_with_periodsaullogiovani2014-10-171-19/+30
|\ \
| * | BUG: Fixes #5184 gradient calculation behavior at boundariesDavid M Fobes2014-10-161-19/+30
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | * Previous expected behavior was that the gradient is computed using central differences in the interior and first differences at the boundaries. * gradient was updated in v1.9.0 so that second-order accurate calculations are done at the boundaries, but this breaks expected behavior with old code, so `edge_order` keyword (Default: 1) is added to specify whether first or second order calculations at the boundaries should be used. * Since the second argument is *varargs, in order to maintain compatibility with old code and compatibility with python 2.6 & 2.7, **kwargs is used, and all kwargs that are not `edge_order` raise an error, listing the offending kwargs. * Tests and documentation updated to reflect this change. * Added `.. versionadded:: 1.9.1` to the new optional kwarg `edge_order` documentation, and specified supported `edge_order` kwarg values. * Clarified documentation for `varargs`. * Made indentation in docstring consistent with other docstring styles. * Examples corrected