-
-
Notifications
You must be signed in to change notification settings - Fork 7.9k
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
Conversation
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:
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. |
There was a problem hiding this 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.
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: 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. |
When I opened the issue I was obviously thinking |
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. |
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.
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. |
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? |
Let's discuss based on this version. |
0c7f227
to
f703ca3
Compare
f703ca3
to
b545f64
Compare
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.) 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. |
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: |
b545f64
to
956b244
Compare
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. |
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:
|
The above is pretty clear. If I were doing this, a) I'd have a third subplot without the inverted axes |
There was a problem hiding this 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?
956b244
to
1bb41ea
Compare
1bb41ea
to
27f8f31
Compare
Let's get this in... |
Closes #28050.