Return arrow collection as 2nd argument of streamplot. #803

Merged
merged 4 commits into from Sep 2, 2012

Conversation

Projects
None yet
5 participants
Contributor

tonysyu commented Mar 28, 2012

Return arrow patches so users can modify or remove them after calling streamplot. This was listed as a todo in the original implementation, but never actually done.

Maybe adding arrows to the axes should be delayed until the arrow collection is completely populated (and then the collection can be added to the axes all at once, just like the streamline collection)?

Owner

efiring commented Apr 16, 2012

I don't think this is a good idea; what is really needed is some sort of compound mappable artist. It doesn't have to be a new kind of collection, but it needs to be a single ScalarMappable so that when sci() is used and the colormap is changed, the lines and arrows change together.
Also, when a cmap kwarg is allowed, a norm kwarg should also be allowed.

Contributor

tonysyu commented Apr 16, 2012

Hmm,... I was hoping it wouldn't come to that :)

I guess I'll take a look at the ContourSet object (as you suggested in the original streamplot PR) and emulate it's behavior.

BTW, after looking back at the original PR, I realized never flagged the streamplot function as experimental, as you suggested. I'm not really sure where that should be marked. Maybe in the return value itself (assuming that's the only major part that's likely change)?

Owner

efiring commented Apr 17, 2012

The ContourSet is a model in the sense that it produces and contains more than a single primitive Artist, and in that it requires extensive computation to generate those Artists, but it may not be an ideal model. It evolved a long time ago. It is possible that the Container base class would provide a good starting point. This is just speculation, though; I haven't looked closely.

Contributor

tonysyu commented Apr 28, 2012

In the newest PR, streamplot returns a Container object with lines and arrows. This needs careful review because I had to override the __new__ constructor which didn't play well with Collections. I don't really understand the container object (e.g. why does it subclass tuple?), so I could be breaking something with this hack.

Contributor

leejjoon commented Apr 29, 2012

The original purpose of the Container object was to support legend for complex plot commands. For example, errorbar command used to return a tuple of artists, thus I ended up with a simple Container class inherited from tuple. And it never meant to be a full implementation of artist.

I'm not sure what the streamplot need to return. Maybe a single object of a class inherited from a ScallarMappable (and Artist). And I think it might not be a good idea to use the Container class for this purpose.

Contributor

tonysyu commented Apr 29, 2012

Thanks for your comments, @leejjoon. After rereading @efiring's comments, I realize that he suggested that Container would be a good starting point---not necessarily the base class for a streamplot container.

In my most recent commit, I change the base class to a simple object and give it attributes lines and arrows. As mentioned in the commit message, this is just a temporary fix since this object doesn't allow the user to set the properties of the lines and arrows from the object itself. Nevertheless, it does at least give users access to the arrows, and (I think) future changes (e.g. subclassing ScalarMappable and Artist) could be made backward-compatible with this simple object.

Owner

efiring commented Sep 2, 2012

@tonysu, sorry for the extra work, but would you rebase this against master, please? Then I will merge it. I should have done so a long time ago. It definitely needs to be done before the RC.

Owner

efiring commented Sep 2, 2012

@tonysyu, also, while you are at it, you might want to note, in docstrings, and/or comments, something about the limitations and likely evolution.

tonysyu added some commits Mar 28, 2012

Change return value of `streamplot`.
- Return object that derives from `object` since deriving from `Container` was not beneficial.
- This return value is a stopgap; the final return value should allow users to set the colormap, alpha, etc. for both lines and arrows.
Contributor

tonysyu commented Sep 2, 2012

@efiring Rebased and added note about future changes to streamplot return value.

Contributor

tonysyu commented Sep 2, 2012

Hmm, Github seems to be screwing up the order of the commits. The discussion page for this PR shows commits in order: 1, 3, 2, 4. The commit page shows them in sequential order, and the diff page looks fine so it's probably just a bug in the discussion page.

This pull request fails (merged a7248d9 into cadd152).

efiring added a commit that referenced this pull request Sep 2, 2012

Merge pull request #803 from tonysyu/streamplot-return-arrows
Return arrow collection as 2nd argument of streamplot.

@efiring efiring merged commit 7a61238 into matplotlib:master Sep 2, 2012

1 check failed

default The Travis build failed
Details

Very late, I know, but this looks like a modification to an auto generated pyplot function. Do you know if that is the case?

Contributor

tonysyu replied Feb 21, 2013

Indeed. That was definitely a mistake on my part. @mdboom has already taken care of it though.

Member

pelson replied Feb 21, 2013

Aha! Thanks - didn't see that one go by.

Cheers

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment