Fillbetween

[rmlopes]

As discussed in issue #6543. Added the interpolate argument just before the **kwargs.

I think I made a mistake, I wanted to target the 1.5.x. I'll be waiting for some input. :)

Should I edit the changelog as well?

[tacaswell]

You targeted the right branch. If merged, this will ship with 2.1 at the earliest.

[tacaswell]

can you also add interpolate here?

[tacaswell]

Can you add an entry in docs/user/whats_new (the README in that folder has instructions).

[rmlopes]

What is the problem here? I can't see the indicated errors.

AssertionError: 2 != 0 : Found code syntax errors (and warnings):
/home/travis/build/matplotlib/matplotlib/lib/matplotlib/axes/_axes.py:4806:80: E501 line too long (88 > 79 characters)
/home/travis/build/matplotlib/matplotlib/lib/matplotlib/axes/_axes.py:4907:60: W291 trailing whitespace

[tacaswell]

That is odd that it is reporting lines outside of where you touched. This may be due to a bad merge somewhere else?

[QuLogic]

master probably has some deleted lines so the merge commit that's being tested has different line numbers. However, it's pretty obvious that line 4856 is too long. As for the trailing whitespace, it will be easier if you configure your editor to strip them on save.

[rmlopes]

There is once again a flake failure, in a line that is not part of the diff - 4908 (and I have already configured the editor to remove trailing spaces on write).

There is an unrelated test failing as well at the image comparison:
FAIL: matplotlib.tests.test_mathtext.test_mathfont_dejavusans_03.test

What should I do?

[QuLogic]

The :: indicates there will be a code block following; it should be removed (or an example added.)

[QuLogic]

The trailing space is here.

[QuLogic]

There is an unrelated test failing as well at the image comparison:
FAIL: matplotlib.tests.test_mathtext.test_mathfont_dejavusans_03.test

That comes and goes; you can ignore it.

[rmlopes]

I will implement the tests for fill_betweenx with and without interpolate because it is missing. I have had some issues with the figures in other libraries (small differences in the fonts to the generated by travis). Is there some kind of procedure (like run the test in travis first, then go to the error message to pick the expected image) in place?

[rmlopes]

@tacaswell I was just wondering, since this is such a trivial change, why not merge this before 2.1? Would it make a difference if the test coverage increased?

[tacaswell]

This is a new feature and 2.1 is the next release with planned new features. The 1.5.x series is only getting critical (as in fixing regressions / does not compile / show stopper) bug fixes, and the 2.x series is only getting changes needed to get the style updates out the door.

This seems to need a rebase.

[tacaswell]

ping @rmlopes can you rebase this?

[rmlopes]

@tacaswell I rebased by squashing every commit into the first, then forced the push as the history is incompatible. Looks like this may not have been the correct approach though.

[tacaswell]

You now need to rebase that single commit onto current master and force-push again.

[rmlopes]

Should be ok now.

[tacaswell]

Something went wrong here, htere should not be this many commits. See http://matplotlib.org/devdocs/devel/gitwash/development_workflow.html?highlight=rebase#rebasing-a-pull-request-pr

[NelleV]

Overall, this looks good.
I've added a comment, but I think this PR has been going on for so long that we should merge it and do the maintenance in another PR.

[NelleV]

Is this the exact same function as in fill_between?
If so, I think it should be factored out and moved to the cbook module as a private function.

[rmlopes]

I think so. I thought about that but also about using some interpolation function maintained and alerady available in scipy (would this be a bad idea perhaps?). I'll have a look at it as soon as I can.

[NelleV]

scipy isn't a dependency, so using their functions isn't an option unless you copy paste them in a module of ours.

[rmlopes]

The two methods differ on the axes of interpolation only. Could be a single function indeed. I can make this in a new branch but I need to know where to add the interpolate function.
This solution is actually very slow for my use case since I am displaying a few thousand seismic traces, so I would like to keep working on this.

[QuLogic]

Can you amend the commit and edit the commit message to remove the duplicate information and the comments from git?

[rmlopes]

I did a rebase squashing 2 commits but somehow ended up with three commits.

[NelleV]

Thanks @rmlopes ! I'll merge this as soon as the tests have passed.

[QuLogic]

It's a method on a class, not a function, so will this cross-reference work?

[QuLogic]

Please don't add the call signature back; it is redundant.

[efiring]

On 2016/11/01 10:10 AM, Rui Lopes wrote:

This solution is actually very slow for my use case since I am
displaying a few thousand seismic traces, so I would like to keep
working on this.

Yes, there should be some scope for vectorization here. At the very
least, all necessary interpolation can be done in a single call to
interp for the whole array. I suspect the entire operation can be
vectorized; I don't see any inherent need for loops.

[NelleV]

I'll merge this, but @rmlopes feel free to continue working on this and open a new PR!