BUG: Fixes #5184 gradient calculation behavior at boundaries #5186
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| @@ -899,6 +899,9 @@ def gradient(f, *varargs): | |||
| `*varargs` : scalars | |||
| 0, 1, or N scalars specifying the sample distances in each direction, | |||
| that is: `dx`, `dy`, `dz`, ... The default distance is 1. | |||
| edge_order : int, optional | |||
| Default: 1. If 2, gradient is calculated using second order | |||
| accurate one-sides (forward or backwards) differences at the boundaries. | |||
There was a problem hiding this comment.
needs .. versionadded:: 1.9.1 see e.g. np.outer for an example of the formatting
possible also add keyword-only to the type area
|
Just a couple of nitpicks. @juliantaylor Do you want to make specific mention of this in the 1.9.1 release notes? |
* 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
|
I went back and checked all the examples to be sure |
charris
added a commit
that referenced
this pull request
Oct 16, 2014
…word BUG: Fixes #5184 gradient calculation behavior at boundaries
|
Merged, thanks. Looking at the documentation, ISTM that more explanation of which axis correspond to |
|
no rebase? |
|
I made sure that I rebased against master before the last change was pushed |
|
Oops, I think Julian means Which makes it better for backporting. My bad. |
Merged
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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_orderkeyword (Default: 1) is added to specify whether first or second order calculations at the boundaries should be used.Tests and documentation updated to reflect this change.