-
Notifications
You must be signed in to change notification settings - Fork 7
Update viz.clustered_scenarios to allow confidence interval plot #482
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
I'm struggling to see where this is useful - I suggest Incidentally, I'm not against |
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 Pedro, I think some minor tweaks (mostly to get rid of push!()
) are needed.
- Updated functions _clusters_colors and _cluster_color to _get_colors and _get_alphas - Added return type to all functions in this file - Adapted the whole file to the style guide
7732f85
to
e7eef96
Compare
100% agree.
I know about |
Also remove option to not fill confint when it is plotted
@ConnectedSystems ready for another review. About the
|
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.
Some things to think about, but overall looks good!
for (i, cluster) in enumerate(unique(clusters)) | ||
n_scens = count(clusters .== cluster) | ||
base_alpha = 1.0 / (n_scens * 0.05) | ||
alphas[i] = max(min(base_alpha, 0.6), 0.1) | ||
end |
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.
Thinking about this now, shouldn't the weighting be based on total number of scenarios?
What we have right now could lead to a smaller cluster hiding a larger cluster (unless I'm misinterpreting the code 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.
I don't think a small cluster would hide a large one because alpha is, at the most, 0.6 (for small clusters) but in this case the cluster has only a few lines.
Considering the result (figure above) it seems to me that this works fine.
That said, if I would do this now, I would probably try something like:
base_alpha = 1 - count(clusters .== cluster)/length(clusters)
alphas[i] = max(min(base_alpha, 0.6), 0.1)
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.
But I think this change is out of the scope of this PR so if you think we should change this I suggest we open an issue, what do you think?
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 need for an issue if you're going to submit a PR directly after (but please do if your not planning to make changes immediately).
By hiding, take a look at the example figures provided here. See how the orange trajectories are blocked from view.
Maybe we plot smaller clusters last?
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.
You wrote "smaller cluster hiding a larger cluster" but in this figure what I see is a larger cluster hiding a smaller cluster, right? But yes, I think a good improvement would be to plot clusters in order from larger to smaller.
Let me open a different PR to do that and also try to change the way this alpha is computed and test some different cases.
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.
You wrote "smaller cluster hiding a larger cluster" but in this figure what I see is a larger cluster hiding a smaller cluster, right?
Yes, correct, accidentally swapped those, sorry for the miscommunication
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 the problem with the figures you sent from PR 492 wasn't the alpha weight.
If you see my last commit - and the commit message - you will see what happened:
Currently we are iterating over the cluster with a for cluster in unique(clusters)
but if clusters vector is something like [2, 1, 1, 3, 2]
, then unique(clusters)
will return [2, 1, 3]
, and then cluster number 2
, for instance, will get the weight that should be assigned to cluster 1
, because we are using the index of the cluster inside the vector as it was the number of the cluster itself.
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.
Update: I just tested here and that doesn't solve the visualization problem. I think plotting larger clusters before smaller ones will solve that though.
c1c6258
to
89c524b
Compare
Previously we were using the index of unique(clusters) array to find clusters colors, plot clusters and render the legend. But depending on the order they appear in clusters vector this could led to mistakes, like cluster number 2 being the first in this vector (meaning it has index 1). That was fixed in a previous commit but the legend wasn't.
Update version number to 0.9.0
Add .JuliaFormatter.toml to .gitignore
- Updated functions _clusters_colors and _cluster_color to _get_colors and _get_alphas - Added return type to all functions in this file - Adapted the whole file to the style guide
Also remove option to not fill confint when it is plotted
Previously we were using the index of unique(clusters) array to find clusters colors, plot clusters and render the legend. But depending on the order they appear in clusters vector this could led to mistakes, like cluster number 2 being the first in this vector (meaning it has index 1). That was fixed in a previous commit but the legend wasn't.
Hi @Zapiano , you don't need to merge in unrelated changes if they aren't relevant to the PR. |
I know... it was by accident |
There is an option to fill or not the area inside the confidence interval - the best visualization option may depend on the situation. The default value of
:fill_confint
is currently set totrue
:This is how it looks with
:fill-confint
set tofalse
:Closes #464