Skip to content
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

Fix plotting in Plots > v.1.11 #165

Draft
wants to merge 4 commits into
base: master
Choose a base branch
from
Draft

Fix plotting in Plots > v.1.11 #165

wants to merge 4 commits into from

Conversation

AlexRobson
Copy link
Member

Fixes ##159

Plots changes the way it handles line segments. Instead of NaN separated, it uses a vector of points (see issue).

Should we keep support for Plots < v1.11

@LilithHafner
Copy link

Should we keep support for Plots < v1.11

On April 20, when @AlexRobson created this PR I would have said yes.

Now I'd say no. Plots v1.11 has been out since March 2021 and plots is now on v1.29.1. I think it is okay to drop support for 15 month old Plots. If a project has Plots pinned to before 1.11, then they will end up having Intervals pinned to 1.7.1 (or whenever this merges) which seems perfectly acceptable to me.

Copy link
Member

@oxinabox oxinabox left a comment

Choose a reason for hiding this comment

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

Lets not worry about supporting Plots pre-1.11
we can't directly restrict that.
we can restrict to RecipeBase 1.0, or even 1.2, which is the minimum for Plots v1.24
We should drop support for RecipesBase 0.8 and 0.9

so lets make the changes to the Project.toml, including bumping the version number
and release this yes?

I assume this is manually tested, and i think automatically testing this more than we currently are isn't work the effort.
Though perhaps the current automtic tests needs updating?
I am not sure what is up with them since they expired

@AlexRobson
Copy link
Member Author

I'm pikcing this back up. Just working through it now. I should have an update shortly.

@AlexRobson
Copy link
Member Author

AlexRobson commented Aug 23, 2022

Looking at this again, I recall the reason I hit a block on it, and why it shouldn't go in as-is. There are two reasons for this, one major and one minor. The major reason is that this seems to break with DateTime Intervals. As-is, this will throw an error in one of the tests that include datetime intervals:

ERROR: Cannot convert DateTime to series data for plotting
Stacktrace:
  [1] error(s::String)
    @ Base ./error.jl:33
  [2] _prepare_series_data(x::DateTime)
    @ RecipesPipeline ~/.julia/packages/RecipesPipeline/OXGmH/src/series.jl:8
  [3] _series_data_vector(x::DateTime, plotattributes::Dict{Symbol, Any})
    @ RecipesPipeline ~/.julia/packages/RecipesPipeline/OXGmH/src/series.jl:35
  [4] (::RecipesPipeline.var"#27#30"{Dict{Symbol, Any}})(vi::DateTime)
    @ RecipesPipeline ./none:0
  [5] iterate
    @ ./generator.jl:47 [inlined]
  [6] _series_data_vector(v::Vector{DateTime}, plotattributes::Dict{Symbol, Any})
    @ RecipesPipeline ~/.julia/packages/RecipesPipeline/OXGmH/src/series.jl:50
  [7] #27
    @ ./none:0 [inlined]
  [8] iterate(::Base.Generator{Vector{Vector{DateTime}}, RecipesPipeline.var"#27#30"{Dict{Symbol, Any}}})
    @ Base ./generator.jl:47
  [9] _series_data_vector(v::Vector{Vector{DateTime}}, plotattributes::Dict{Symbol, Any})
    @ RecipesPipeline ~/.julia/packages/RecipesPipeline/OXGmH/src/series.jl:50
 [10] macro expansion
    @ ~/.julia/packages/RecipesPipeline/OXGmH/src/series.jl:134 [inlined]
 [11] apply_recipe(plotattributes::AbstractDict{Symbol, Any}, #unused#::Type{RecipesPipeline.SliceIt}, x::Any, y::Any, z::Any)
    @ RecipesPipeline ~/.julia/packages/RecipesBase/qpxEX/src/RecipesBase.jl:289
 [12] _process_userrecipes!(plt::Any, plotattributes::Any, args::Any)
    @ RecipesPipeline ~/.julia/packages/RecipesPipeline/OXGmH/src/user_recipe.jl:36
 [13] recipe_pipeline!(plt::Any, plotattributes::Any, args::Any)
    @ RecipesPipeline ~/.julia/packages/RecipesPipeline/OXGmH/src/RecipesPipeline.jl:70
 [14] _plot!(plt::Plots.Plot, plotattributes::Any, args::Any)
    @ Plots ~/.julia/packages/Plots/lW9ll/src/plot.jl:209
 [15] plot(::Any, ::Vararg{Any, N} where N; kw::Any)
    @ Plots ~/.julia/packages/Plots/lW9ll/src/plot.jl:91
 [16] plot(::Any, ::Any)
    @ Plots ~/.julia/packages/Plots/lW9ll/src/plot.jl:85
 [17] top-level scope
    @ REPL[41]:1

However, I suspect that this may need to be handled in a different package, I'm playing around with the other packages in the stacktrace to track it down (e.g. RecipesPipelines).

The minor reason is the change in behaviour means that the intervals all get marked as a different series. For non-datetime intervals:

intervals = [Interval{Closed, Closed}(float(x), float(x + 0.5)) for x in 1:11]
plot(intervals, 1:11)

image

@oxinabox
Copy link
Member

The minor reason is the change in behaviour means that the intervals all get marked as a different series. For non-datetime intervals:

This is also signficiant since if we had multiple series (like we often do) we won't be able to tell them apparent and the legend will be useless

@BioTurboNick
Copy link

This may be helpful: if you set primary = false, a new series will take the color of the previous series. And if label = "", it's excluded from the legend.

@AlexRobson
Copy link
Member Author

This may be helpful: if you set primary = false, a new series will take the color of the previous series. And if label = "", it's excluded from the legend.

Thanks - this fixed that one :) - the last thing for me in this MR then is tracking down why DateTime isn't working.

@BioTurboNick
Copy link

One thing that may be worth keeping in mind is that until more recent versions of Plots (improved in 1.23.x, fully fixed by 1.30.2), adding many series could get extremely slow because there were several O(n^2) operations over series. I discovered and fixed them, but depending on how many intervals you expect people to be plotting, and if people are on an older version, they could have a negative experience there. >100 or >1000 is where it might get really annoying.

@codecov
Copy link

codecov bot commented Sep 3, 2022

Codecov Report

Merging #165 (bb6d24e) into master (a785b56) will decrease coverage by 0.42%.
The diff coverage is 100.00%.

@@            Coverage Diff             @@
##           master     #165      +/-   ##
==========================================
- Coverage   84.16%   83.74%   -0.43%     
==========================================
  Files          12       12              
  Lines         840      818      -22     
==========================================
- Hits          707      685      -22     
  Misses        133      133              
Impacted Files Coverage Δ
src/plotting.jl 94.73% <100.00%> (+0.61%) ⬆️
src/interval_sets.jl 91.66% <0.00%> (-0.25%) ⬇️
src/interval.jl 95.89% <0.00%> (-0.13%) ⬇️
src/endpoint.jl 98.03% <0.00%> (-0.08%) ⬇️
src/anchoredinterval.jl 99.10% <0.00%> (-0.02%) ⬇️
src/description.jl 100.00% <0.00%> (ø)
src/inclusivity.jl 100.00% <0.00%> (ø)

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants