-
Notifications
You must be signed in to change notification settings - Fork 22
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
**BREAKING** change of sampleplot
behaviour and defaults
#213
Conversation
Codecov Report
@@ Coverage Diff @@
## master #213 +/- ##
==========================================
- Coverage 98.05% 98.02% -0.03%
==========================================
Files 10 10
Lines 359 355 -4
==========================================
- Hits 352 348 -4
Misses 7 7
Continue to review full report at Codecov.
|
I noticed that they show up in the example (which I thought was confusing...).
If you specify |
I would argue that even in the samples=layout=n case it might be cleaner to have just one legend. But if you do want multiple labels, it's as easy as passing |
@devmotion I've added an explanation to the docstring, hopefully that makes things sufficiently clear for users who do want the original behaviour:) Just I found the previous behaviour of |
I've now also added a use-case in the regression 1d example: ) |
examples/regression-1d/script.jl
Outdated
plt = plot(; xlim=(0, 1), xlabel="x", ylabel="y", title="posterior (AdvancedHMC)") | ||
for (i, p) in enumerate(samples[(end - 100):end]) | ||
sampleplot!( | ||
plt, | ||
0:0.02:1, | ||
gp_posterior(x_train, y_train, p); | ||
samples=5, | ||
label=(i == 1 ? "samples" : nothing), | ||
) | ||
end | ||
scatter!(plt, x_test, y_test; label="Test Data") | ||
scatter!(plt, x_train, y_train; label="Train Data", markercolor=1) | ||
scatter!(plt, x_test, y_test; label="Test Data", markercolor=2) | ||
plt |
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.
NB- is the explicit passing around of plt
actually needed (/ recommended)? It would seem to me it should work exactly the same without it (the last scatter!
also returns the plot object).
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.
Not sure 🤷 I know that I had to use it sometimes since the plot was not returned from scatter!
(or some other inplace function) but maybe it was fixed.
examples/regression-1d/script.jl
Outdated
for (i, p) in enumerate(samples[(end - 100):end]) | ||
sampleplot!( | ||
plt, | ||
0:0.02:1, | ||
gp_posterior(x_train, y_train, p); | ||
samples=5, | ||
label=(i == 1 ? "samples" : nothing), | ||
) | ||
end | ||
scatter!(plt, x_test, y_test; label="Test Data") | ||
scatter!(plt, x_train, y_train; label="Train Data", markercolor=1) | ||
scatter!(plt, x_test, y_test; label="Test Data", markercolor=2) |
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.
It seems like the only way of getting the scatter markers of train/test data on top of the lines for the samples is by having the call later. That then also affects the order of legend entries. I wish there was something straightforward like the z-order in matplotlib! If any of you has any ideas for how to get that behaviour, I'd love to find out (google didn't really help me here)..
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.
No, I think you just have to plot in whatever order you want them to appear and then you have to live with the legend. At least I don't know of any other way.
Related: https://discourse.julialang.org/t/plots-only-one-series-as-primary-plot/24616/8 Apparently, the plots maintainers think it would be more natural to concatenate all data in a single vector separated with |
It's not impossible: does the explanation I added to the docstring, using |
What I meant more precisely: it is not possible anymore if you pass a string as label even though in the Plots ecosystem usually that would give you the same label for each series. And I think |
Yes and that's what I'd expect if I pass in a series of |
My opinion is just:
I am leaning more and more towards the second option. |
Sounds good 👍 I think that makes most sense conceptually as well. I'll have a go at that:) |
src/util/plotting.jl
Outdated
flat_x = vcat(Iterators.flatten(zip(Iterators.repeated(sp.x), fill(NaN, nsamples)))...) | ||
flat_f = vcat(Iterators.flatten(zip(eachcol(samples), Iterators.repeated([NaN])))...) |
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.
@devmotion happy for you to suggest a better way - this is what I could come up with so far ;)
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.
Apparently the splatting is bad? but I can't figure out a way to get around it
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.
My suggestion would be
flat_x = vcat(Iterators.flatten(zip(Iterators.repeated(sp.x), fill(NaN, nsamples)))...) | |
flat_f = vcat(Iterators.flatten(zip(eachcol(samples), Iterators.repeated([NaN])))...) | |
flat_x = repeat(vcat(sp.x, NaN), nsamples) | |
flat_f = vec(vcat(samples, fill(NaN, 1, nsamples))) |
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.
ah, I literally just came upon the same solution myself right before looking at your comment 🎉
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.
Except the "interleave with NaN" doesn't actually seem to work, as seriestype = :line
makes it sort by x :(
So we could remove the seriestype --> :line
below, but then you must pass in an ordered x
for the sampleplot
to make any sense. Would you be happy with that?
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.
We could also just sort x
, couldn't we?
Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
…ses/AbstractGPs.jl into st/sampleplot_update
I think it makes more sense to treat the multiple samples as a single series, but I also don't think it needs to be |
I'm happy if the tests are improved. I think in the tests we should check the plotting attributes that |
Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
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.
Looks good, I just had some minor questions 🙂
0:0.02:1, | ||
gp_posterior(x_train, y_train, p); | ||
samples=5, | ||
label=(i == 1 ? "samples" : nothing), |
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.
Maybe just
label=(i == 1 ? "samples" : nothing), | |
label=(i == 1 ? "samples" : ""), |
? I did not know that label=nothing
is a thing 😄
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.
Yeah, one of the complaints about Plots.jl is that there are plenty of different ways of saying the same thing!
I find label = nothing
to be a bit more self-explanatory, but feel free to add&commit your suggestion if you feel moderately strongly about it:)
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.
No, I don't feel strongly about it. The main reason would be to avoid having two different types here but I'm fine with nothing
as well.
src/util/plotting.jl
Outdated
seriescolor --> "red" | ||
label --> "" |
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.
Do we need/want these defaults?
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.
Yeah, I really like this default for label
and would keep it. Otherwise it says y1
which is worse. If you want to get rid of the red for seriescolor
, we can remove it here as well, but I'm also happy to leave it as is for now.
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.
Yes, the default labels aren't great. Maybe let's just remove the series color? I don't think red is a particularly great choice and we could just let Plots pick one, according to whatever theme is used.
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.
ok, done. anything else before you're willing to hit approve?:)
…ses/AbstractGPs.jl into st/sampleplot_update
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.
Looks good to me, I think these changes are reasonable!
Edit: Should this be a breaking release?
Good point. Technically, yes (you might have relied on |
And in fact I did have to edit the examples to account for removing the |
IMO it's reasonable that we have to set the seriescolor explicitly in this case - we call |
I'd prefer to release this now - which comes at the cost of users having to bump their compat one additional time, but that's offset by smaller changes also being easier to adapt to. Otherwise we take the cost of more and more changes sticking around in un-merged PRs until it's "enough" to make a breaking release - and then a big breaking release actually becomes much more effort for users to adapt to. What's crucial to minimise user pain is to make it easy for users to understand WHAT breaks in a breaking release (and how they might have to adjust their code to account for it). I'll update the PR description accordingly. Do we (want to) have guidelines around how to document breaking changes & make that clear in release notes? "[breaking]" in the PR title for example? that would make it easier to go to the release summary and focus on the breaking changes one by one. |
sampleplot
behaviour and defaults
sampleplot
behaviour and defaultssampleplot
behaviour and defaults
This PR makes two breaking changes to the
sampleplot
plotting utility:sampleplot
no longer imposes a default seriescolor.How to obtain the previous color: manually pass
seriescolor = "red"
.linealpha
default has been increased to 0.35 to keep visual appearance the same.How to obtain the previous markers: If you actually liked the tiny markers, check the diff for the previous default settings that you now need to pass manually.
samples
kwarg > 1) are now plotted as a single series. This means, for example, that passing a string aslabel
only adds one legend entry for all samples, not one per sample.How to obtain previous behaviour: If you actually want each sample to be a different series (for example, to give them different colors), you now need to call
sampleplot
multiple times instead.Additionally, this PR contains the following non-breaking minor changes:
ribbon_scale
inplot
recipepop!
for custom-defined kwarg)