Thanks to visit codestin.com
Credit goes to github.com

Skip to content

DOC: Improve inverted axis example #28055

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 1 commit into from
Apr 12, 2024

Conversation

timhoffm
Copy link
Member

Closes #28050.

@github-actions github-actions bot added the Documentation: examples files in galleries/examples label Apr 10, 2024
@story645
Copy link
Member

story645 commented Apr 10, 2024

Since this looks like two ways to do the same thing, while I'm not a fan of multiple images in examples think this is a great use case for it since one thumbnail covers both methods. I'm thinking linkable subsections for:

  1. Recommended method

  2. Other method where we can write the caveats for when to use this method.

I'm hoping that subsection headings will prime folks to more easily find the one line of code that does the thing that way in each section.

Copy link
Member

@rcomer rcomer left a comment

Choose a reason for hiding this comment

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

Thanks for picking this up! I had been going back and forth on whether and how to still include the set_xlim version, but this solves it very neatly.

I had been thinking along similar lines to @story645 to put two figures in with some explanation in between, but all I could come up with for when to use set_xlim was "if this is a context where you would have fixed the limits regardless of direction". That doesn’t really warrant a whole paragraph and the new axes titles cover this I think.

I’m approving as definitely better than it was but will also leave open for a bit in case others want to discuss further.

@rcomer rcomer added this to the v3.8-doc milestone Apr 11, 2024
@story645
Copy link
Member

story645 commented Apr 11, 2024

That doesn’t really warrant a whole paragraph and the new axes titles cover this I think.

I think a sentence is fine for a new subsection, doesn't need to be a paragraph. My reasoning for splitting it into two sections is that:
1).the code kinda gets lost/harder to follow the more there is of it. Like here you've gotta match the axes to the method and then find the line so it's a two hops instead of 1
2) provides a way to more clearly identify a preferred/recommended method. I feel like putting em both in the same figure denotes that they're at the same level.

Which like clearly I've got stronger than I thought feelings about this & like I can put in a follow up advocating for this. Not gonna block but also not approving b/c while I agree it's better in that it documents something not documented, I'm worried that adding the second version in this manner makes it a little harder to figure out the "what should I do" from this example.

@rcomer
Copy link
Member

rcomer commented Apr 11, 2024

  1. provides a way to more clearly identify a preferred/recommended method. I feel like putting em both in the same figure denotes that they're at the same level.

When I opened the issue I was obviously thinking set_inverted is the "right" way to do this but actually if you want fixed limits then using set_xlim would be the right way. So I'm not sure I'd say one should be preferred in general, but that it depends on your use-case.

@timhoffm timhoffm marked this pull request as draft April 11, 2024 18:03
@timhoffm
Copy link
Member Author

I still believe one figure is better, because you have the two code variants right next to each other, which my ales it easier to compare.

we can however make the “two variants” situation more visible in the description.

Will update later.

@story645
Copy link
Member

story645 commented Apr 11, 2024

I still believe one figure is better, because you have the two code variants right next to each other, which my ales it easier to compare.

But here the image is identical, so I'm not sure that helps. And there's a balance in that while visually it may be easier to compare, I think the code can be harder to scan for which piece of code does the exact thing.

So I'm not sure I'd say one should be preferred in general, but that it depends on your use-case.

Sure, but like I think if we're not communicating when to use what, then it leaves the user super confused on why we have two ways to do the same thing.

@rcomer
Copy link
Member

rcomer commented Apr 11, 2024

But here the image is identical

They are not identical, as the fixed limit version has narrower limits. Perhaps that would be more obvious if they were one above each other instead of side-by-side?

@timhoffm timhoffm marked this pull request as ready for review April 11, 2024 19:23
@timhoffm
Copy link
Member Author

Let's discuss based on this version.

@timhoffm timhoffm force-pushed the example-invert-axes branch from 0c7f227 to f703ca3 Compare April 11, 2024 19:24
@github-actions github-actions bot added the Documentation: API files in lib/ and doc/api label Apr 11, 2024
@timhoffm timhoffm force-pushed the example-invert-axes branch from f703ca3 to b545f64 Compare April 11, 2024 19:26
@story645
Copy link
Member

story645 commented Apr 11, 2024

But here the image is identical

They are not identical, as the fixed limit version has narrower limits. Perhaps that would be more obvious if they were one above each other instead of side-by-side?

Um these look pretty much identical to me ( realizing cause I had first thought that y was being inverted, even with the title 🙁, so yeah maybe stacked would help - but even then I think it's a bit of a you have to know what you're looking for problem, ie you have to know that auto scaling has margins to really see it in the image.)

Screenshot_20240411-163113.png

I'm less hung up on them being in one figure now cause yeah code that's short enough to fit on one phone screen is probably easily scannable, but I'm still not convinced that there's a benefit either...

Like I think if you're going w/ one figure, then you may as well invert x using one method and y using the other and label accordingly on each axis.

@timhoffm
Copy link
Member Author

Sort of the point here is that both methods yield similar results: Both have inverted x-axis. The difference fixed vs. autoscaled axes is not immediately visible. We could use a larger range for the fixed-limits case, so that one clearly sees these are not autoscaled, but do we want to draw attention to this?

On one or two plots:
With two separate plots, the code blocks and figures are further apart and thus harder to compare. IMHO this is a disadvantage no matter whether we want to emphasize both variants result in similar plots, or whether we want to emphasize the difference in limits from auto-scaling vs. fixed limits.

@timhoffm timhoffm force-pushed the example-invert-axes branch from b545f64 to 956b244 Compare April 11, 2024 22:21
@timhoffm
Copy link
Member Author

timhoffm commented Apr 11, 2024

Used x, y as variables and "decreasing x ⟶" as xlabel to draw more attention to the x axis.

To put even more emphasis, we could color xticks/xlabel e.g. orange, but I'm hesitant that the additional commands add too much clutter.

Edit: It would also help to be able to highlight important code lines. -> Create a feature request at sphinx-gallery/sphinx-gallery#1283.

@story645
Copy link
Member

story645 commented Apr 12, 2024

the code blocks and figures are further apart and thus harder to compare.

Hmm a point I think I maybe am making badly is that I don't think the goal should be to set up a comparison of results - between the similarity of image and similarity of code, like the visible difference is super nuanced.

The reason I'm advocating instead for the separate sections is precisely to emphasize the differentiation/comparison on use case:

  1. invert axes with fixed limits
  2. invert axes with auto limits

@jklymak
Copy link
Member

jklymak commented Apr 12, 2024

The above is pretty clear.

If I were doing this,

a) I'd have a third subplot without the inverted axes
b) It sometimes happen that you want to invert the x axis, but it often happens that you want to invert the y axis, at least in oceanography.

@timhoffm
Copy link
Member Author

@story645 @jklymak I yield here. My motivation and scope was a reasonable quick fix for #28050, which I believe is fulfilled. Feel free to bikeshed further without me.

Copy link
Member

@story645 story645 left a comment

Choose a reason for hiding this comment

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

:/ I think "what will the user take away from this example" is more than bikeshedding, but I guess I'm ok w/ self merging and then me and Jody can hash things out on a follow up.

The request changes that you can dismiss is what's up with the changes to the API index in this PR?

@timhoffm timhoffm force-pushed the example-invert-axes branch from 956b244 to 1bb41ea Compare April 12, 2024 08:44
@github-actions github-actions bot removed the Documentation: API files in lib/ and doc/api label Apr 12, 2024
@timhoffm timhoffm force-pushed the example-invert-axes branch from 1bb41ea to 27f8f31 Compare April 12, 2024 08:46
@rcomer rcomer dismissed story645’s stale review April 12, 2024 09:48

index changes gone

@rcomer
Copy link
Member

rcomer commented Apr 12, 2024

Let's get this in...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Documentation: examples files in galleries/examples
Projects
None yet
Development

Successfully merging this pull request may close these issues.

[Doc]: Invert Axes example sets x-lims directly
4 participants