Skip to content

Fix scatter singlecolor #17499

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 2 commits into from
May 23, 2020
Merged

Conversation

tacaswell
Copy link
Member

@tacaswell tacaswell commented May 23, 2020

PR Summary

Restores support of the color-favoring special case documented in the docstring and warning. Independent of if we think this was a good design initially etc we pretty clearly document that this is the expected behavior and it was the behavior in 3.1 so it should be restored.

Also tweaked the docstring to direct users to the color kwarg which does not have the "should we colormap?" ambiguity.

Closes #17423

PR Checklist

  • Has Pytest style unit tests
  • Code is Flake 8 compliant
  • Documentation is sphinx and numpydoc compliant

tacaswell added 2 commits May 23, 2020 13:00
Encourage user to use the *color* keyword in the case where they have
only one color.
@tacaswell tacaswell added the Release critical For bugs that make the library unusable (segfaults, incorrect plots, etc) and major regressions. label May 23, 2020
@tacaswell tacaswell added this to the v3.2.2 milestone May 23, 2020
@@ -4281,19 +4281,26 @@ def invalid_shape_exception(csize, xsize):
except ValueError:
pass # Failed to convert to float array; must be color specs.
else:
# handle the documented special case of a 2D array with 1
# row which as RGB(A) to broadcast.
if c.shape == (1, 4) or c.shape == (1, 3):
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

OK, but do we want a 2-d array or a list of arrays as the special case?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't understand. Would you elaborate, please? Why would there be a distinction here?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The particular value for c is something like: c = [[0.1, 0.1, 0.4]]?

Copy link
Member Author

@tacaswell tacaswell May 23, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We do c = np.asanyarray(c, dtype=float) a few lines above to normalize c. I do not think we want to get into the business of distinguishing between [[a, b, c]], [np.array([a, b, c])], and np.array([[a, b, c]]) as input.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

OK, but an unsqueezed 1x3 ndarray is a perfectly valid thing to pass for c if I have 3 data points. So how can we tell them apart?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Before it is squeezed, the dimensions are checked so that a 1x3 or 1x4 can be interpreted as a color. The (3,) or (4,) 1-d cases, when the size matches the number of points, is interpreted as a sequence of values to be mapped. This is the documented way the ambiguity is resolved, based on a decision made long ago. I just fouled it up in the last change I made to the code. Thomas is cleaning up my mess.

@efiring efiring merged commit 346f6f7 into matplotlib:master May 23, 2020
@lumberbot-app
Copy link

lumberbot-app bot commented May 23, 2020

Owee, I'm MrMeeseeks, Look at me.

There seem to be a conflict, please backport manually. Here are approximate instructions:

  1. Checkout backport branch and update it.
$ git checkout v3.2.x
$ git pull
  1. Cherry pick the first parent branch of the this PR on top of the older branch:
$ git cherry-pick -m1 346f6f77dd2ce712c1ba35fcca988630e835cb69
  1. You will likely have some merge/cherry-pick conflict here, fix them and commit:
$ git commit -am 'Backport PR #17499: Fix scatter singlecolor'
  1. Push to a named branch :
git push YOURFORK v3.2.x:auto-backport-of-pr-17499-on-v3.2.x
  1. Create a PR against branch v3.2.x, I would have named this PR:

"Backport PR #17499 on branch v3.2.x"

And apply the correct labels and milestones.

Congratulation you did some good work ! Hopefully your backport PR will be tested by the continuous integration and merged soon!

If these instruction are inaccurate, feel free to suggest an improvement.

tacaswell pushed a commit to tacaswell/matplotlib that referenced this pull request May 23, 2020
Merge pull request matplotlib#17499 from tacaswell/fix_scatter_singlecolor

Fix scatter singlecolor

Conflicts:
	lib/matplotlib/axes/_axes.py
         - implicitly backport some extra docstring changes
@tacaswell tacaswell deleted the fix_scatter_singlecolor branch May 23, 2020 21:43
tacaswell added a commit that referenced this pull request May 23, 2020
…-v3.2.x

Backport PR #17499: Fix scatter singlecolor
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Release critical For bugs that make the library unusable (segfaults, incorrect plots, etc) and major regressions.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Scatter produce multiple colors for a single RGB/RGBA input
4 participants