DOC: Add note about linear colorbar scale option for TwoSlopeNorm #30639
Conversation
Addresses matplotlib#22197 by documenting the cb.ax.set_yscale('linear') workaround for users who prefer linear colorbar spacing instead of the default scaled spacing introduced in matplotlib 3.5.
github-actions
bot
added
the
Documentation: user guide
…opeNorm
Replace note with side-by-side example showing:
- Left: Default scaled colorbar (centered at midpoint)
- Right: Linear colorbar using cb.ax.set_yscale('linear')
Addresses maintainer feedback from @jklymak to make the difference
more clear with a visual demonstration.
- Change title from 'norms with a scale' to TwoSlopeNorm-specific - Clarify that colorbar is divided into two equal parts - Explain screen-space vs data range difference - Note that color-to-value mapping remains unchanged - Address review comments from @timhoffm
- Add backticks around .TwoSlopeNorm class reference
- Use double backticks for cb.ax.set_yscale('linear') code snippet
- Fixes documentation build errors
| # `~.colors.FuncNorm` to define your own. Note that this example is the same | ||
| # as `~.colors.PowerNorm` with a power of 0.5: | ||
|
|
||
|
|
There was a problem hiding this comment.
Unrelated change.
|
|
||
| fig, (ax1, ax2) = plt.subplots(1, 2, figsize=(10, 4)) | ||
|
|
||
| # Left plot: Default scaled colorbar (centered at midpoint) |
There was a problem hiding this comment.
Most of this is repeated. I'd just put in a loop, and act on the last colorbar created.
There was a problem hiding this comment.
If you are going to resolve a suggestion without taking it, it helps to explain why you ignored it.
Co-authored-by: Tim Hoffmann <2836374+timhoffm@users.noreply.github.com>
- Rewrite explanation to avoid 'screen space' term per jklymak - Clarify that colorbars adopt their norm's scaling by default - Better explain TwoSlopeNorm splits colormap evenly between halves - Change tick specification to use np.arange for clarity - Update both cb1 and cb2 to use np.arange(-500, 4001, 500) Addresses @jklymak review comments
- Fix E501: Break long line (line 289) to stay under 88 character limit - Fix E302: Add missing blank line before function definition All ruff checks now pass.
|
Thank you both @timhoffm and @jklymak for your thorough reviews and excellent suggestions! 🙏 I've addressed all the feedback: @timhoffm's suggestions: @jklymak's suggestions: The documentation now provides clear, specific guidance with better examples. All CI checks should pass now. Thank you for helping improve this! 🎉 |
The set_ticks() method expects a 1D array with shape (N,), but wrapping np.arange() in square brackets creates a list containing an array with shape (1, N). This fixes the ValueError by passing the array directly.
Co-authored-by: Jody Klymak <jklymak@gmail.com>
Precommit linter expects only one blank line before # %% markers.
The end-of-file-fixer precommit hook requires files to end with exactly one newline, not multiple.
| # `~.colors.FuncNorm` to define your own. Note that this example is the same | ||
| # as `~.colors.PowerNorm` with a power of 0.5: | ||
|
|
||
|
|
|
|
||
| fig, (ax1, ax2) = plt.subplots(1, 2, figsize=(10, 4)) | ||
|
|
||
| # Left plot: Default scaled colorbar (centered at midpoint) |
There was a problem hiding this comment.
If you are going to resolve a suggestion without taking it, it helps to explain why you ignored it.
Co-authored-by: Jody Klymak <jklymak@gmail.com>
- Replace repeated code blocks with a loop as suggested by jklymak - Iterate over both axes with corresponding titles - Act on the last colorbar (cb) to set linear scale for right plot - Reduces code duplication and improves maintainability
|
Hi @jklymak, You're absolutely right, and I apologize for the confusion. I initially marked the conversation as resolved after addressing the grammar suggestion without implementing the loop refactoring you requested. I've now refactored the code to use a loop as you suggested in commit c8a0930. The changes include:
The refactored code is much cleaner and more maintainable. Thank you for pushing me to make this improvement—it's definitely better this way! Changes:
Thank you for your patience and detailed feedback! |
- Wrap long comment lines to stay within 88 character limit - Split zip() arguments across lines for better readability - Add blank line before section marker - All ruff checks now pass
Appreciate your thorough review and for merging this in, @jklymak. I’ll make sure to avoid those extra carriage returns next time. |
|
Hi! I really enjoyed contributing to this repo and plan to do more in the future. If you could add the hacktoberfest-accepted label to this PR, it’d help me a lot. Thank you! 🙏 |
timhoffm
added
the
hacktoberfest-accepted
|
Are we participating in hacktoberfest? |
|
We’re not actively advertising, or formally taking part but I think there is no harm in putting the label on reasonable PRs on request. It is my understanding that this is enough for the PR to count - but maybe I’m wrong there. |
|
Fair enough. Hacktoberfest is not always net plus for the project, so I wasnt sure we wanted to encourage. |
3 participants
Fixes #22197
Summary
This PR adds a documentation note to the Colormap Normalization tutorial explaining how users can restore the pre-3.5 linear colorbar spacing for
TwoSlopeNormand other norms with a scale.Changes Made
TwoSlopeNormexample ingalleries/users_explain/colors/colormapnorms.pyscaleuse that scale by default (behavior introduced in matplotlib 3.5)cb.ax.set_yscale('linear')workaround for users who prefer linear spacingContext
Since matplotlib 3.5, colorbars for norms with a scale (like
TwoSlopeNorm) display the scale in the colorbar itself, which can appear non-linear. While this is consistent with other scaled norms likeLogNorm, many users expect or prefer the linear spacing behavior from versions before 3.5.This note provides clear guidance on how to achieve linear colorbar spacing when desired, addressing a common user question documented in issue #22197.
Testing
TwoSlopeNormexample is appropriate