Cannot convert Float64 to series data for plotting

[babaq]

Plots suddently stopped working on a Any array such as

a = Any[1.2, 2.3, 3.3, 4.7]
plot(a)

is this new behavior of Plots, or there are package conflicts.
Here is my system: Julia v1.1.1 on win10

[c52e3926] Atom v0.9.1
[fbb218c0] BSON v0.2.3
[336ed68f] CSV v0.5.11
[159f3aea] Cairo v0.6.0
[324d7699] CategoricalArrays v0.5.5
[da1fd8a2] CodeTracking v0.5.7
[c3611d14] ColorVectorSpace v0.6.2
[5ae59095] Colors v0.9.5
[861a8166] Combinatorics v0.7.0
[a81c6b42] Compose v0.7.3
[717857b8] DSP v0.6.0
[a93c6f00] DataFrames v0.19.2
[864edb3b] DataStructures v0.17.0
[39dd38d3] Dierckx v0.4.1
[31c24e10] Distributions v0.21.1
[becb17da] Feather v0.5.3
[5789e2e9] FileIO v1.0.7
[587475ba] Flux v0.8.3
[186bb1d3] Fontconfig v0.2.0
[aa1b3936] GraphIO v0.4.0
[a2cc645c] GraphPlot v0.3.1
[bd48cda9] GraphRecipes v0.4.0
[19dc6840] HCubature v1.4.0
[f67ccb44] HDF5 v0.12.0
[7073ff75] IJulia v1.19.0
[51556ac3] ImageDistances v0.2.4
[6218d12a] ImageMagick v0.7.5
[916415d5] Images v0.18.0
[c601a237] Interact v0.10.2
[a98d9a8b] Interpolations v0.12.2
[4138dd39] JLD v0.9.1
[033835bb] JLD2 v0.1.2
[e5e0dc1b] Juno v0.7.2
[093fc24a] LightGraphs v1.2.0
[2fda8390] LsqFit v0.8.1
[23992714] MAT v0.5.0
[ee78f7c6] Makie v0.9.4
[626554b9] MetaGraphs v0.6.4
[6f286f6a] MultivariateStats v0.6.0
[47be7bcc] ORCA v0.2.1
[f0f68f2c] PlotlyJS v0.12.5
[91a5bcdd] Plots v0.26.1
[92933f4c] ProgressMeter v1.0.0
[438e738f] PyCall v1.91.2
[d330b81b] PyPlot v2.8.1
[295af30f] Revise v2.1.6
[2913bbd2] StatsBase v0.32.0
[65254759] StatsMakie v0.0.6
[f3b207a7] StatsPlots v0.10.2
[bd369af6] Tables v0.2.11
[1986cc42] Unitful v0.16.0
[0f1e0344] WebIO v0.8.9
[ddb6d928] YAML v0.3.2
[37e2e46d] LinearAlgebra

[yha]

Passing Any arrays containing numbers doesn't work since #2110 .
Previously, vector inputs were generally interpreted based on the vector's type parameter, with an exception for the case where the vector's elements are all numbers, where it was interpreted as single series (as if it was of type Vector{<:Number}). I removed this exception, so now Vector{Any} is interpreted as one series per element, and then treating a number as a series fails.
One problem with the old behavior is that the special treatment of numbers was inconsistent: data point types supported by Plots at the "low-level" (after applying recipes) are Numbers, AbstractStrings, and Missings, but only numbers were special-cased. So numeric data was split to series differently from string data, or from numeric data with some missing values.

I didn't expect Any typed vectors to be a common use case (except empty []), but maybe I was wrong. What is your use case?

I think there's some trade-off here between consistency and "do-what-I-mean". Maybe we can dispatch on the union of element types (reduce(Base.typejoin, typeof.(input_array)?) rather than type parameter (basically extending the previous special case to all "data point" types)?

[babaq]

Thanks for the explanation, I see now how it was decided the way data array dispatched.

I agree it's better treat data consistently. In my use case, the data get queried, pooled and processed, and it's not possible or convenient to have a predefined or fixed type such as Vector{Float64}, so it starts as Any[], and it stays, and Plots was able to handle that.

it'll obvious better to further examine element types of Ayn[], and reduce a Any[] to the three low-level types, and if it can't, then throw an exception.

[GlenHenshaw]

Well, I can say that I was using DataFrames to store data this way and then plotting it, and that is now broken.

foo = DataFrame(t=[], x=[])
push!(foo, 5., 2.)
plot(foo[:t], foo[:x])

[mkborregaard]

That's a serious regression. Also, in general Plots tend to fall on the DWIM side of the design spectrum, I think there might be a case for reversal of some of the behaviour here, unless there's a clear and common use case for the new interpretatino of AnyVectors.

[hafez-ahmad]

a=1
T=4
l=12
t=collect(0:(((300-(-300))/10)^-1)*20:20)

x=collect(-300:10:300)
H=acos.(2pi.t ./ T-2pi.*x)
for k=1:length(t)
plot!(t[k],H[k])
end

cannot convert float64 to series data for plotting

[daschw]

@hafez-ahmad you have to pass vectors to plots:

p = plot()
for k=1:length(t)
    scatter!(p, [t[k]], [H[k]])
end
display(p)

We're discussing to maybe allow scalar values in future too, though.

[pannous]

This serious regression even breaks simple examples from the official tutorial:
https://docs.juliaplots.org/latest/tutorial/

using Distributions
plot(Normal(3, 5), lw = 3)

ERROR: Cannot convert Normal{Float64} to series data for plotting
Stacktrace:
 [1] error(::String) at ./error.jl:33
 [2] _prepare_series_data(::Normal{Float64}) at /Users/me/.julia/packages/RecipesPipeline/tkFmN/src/series.jl:8
 [3] _series_data_vector(::Normal{Float64}, ::Dict{Symbol,Any}) at /Users/me/.julia/packages/RecipesPipeline/tkFmN/src/series.jl:27
 [4] macro expansion at /Users/me/.julia/packages/RecipesPipeline/tkFmN/src/series.jl:139 [inlined]
 [5] apply_recipe(::Dict{Symbol,Any}, ::Type{RecipesPipeline.SliceIt}, ::Nothing, ::Normal{Float64}, ::Nothing) at /Users/me/.julia/packages/RecipesBase/aQmWx/src/RecipesBase.jl:281
 [6] _process_userrecipes!(::Plots.Plot{Plots.GRBackend}, ::Dict{Symbol,Any}, ::Tuple{Normal{Float64}}) at /Users/me/.julia/packages/RecipesPipeline/tkFmN/src/user_recipe.jl:35
 [7] recipe_pipeline!(::Plots.Plot{Plots.GRBackend}, ::Dict{Symbol,Any}, ::Tuple{Normal{Float64}}) at /Users/me/.julia/packages/RecipesPipeline/tkFmN/src/RecipesPipeline.jl:69
 [8] _plot!(::Plots.Plot{Plots.GRBackend}, ::Dict{Symbol,Any}, ::Tuple{Normal{Float64}}) at /Users/me/.julia/packages/Plots/D7Ica/src/plot.jl:167
 [9] plot(::Normal{Float64}; kw::Base.Iterators.Pairs{Symbol,Int64,Tuple{Symbol},NamedTuple{(:lw,),Tuple{Int64}}}) at /Users/me/.julia/packages/Plots/D7Ica/src/plot.jl:57
 [10] top-level scope at REPL[17]:1

[pannous]

please reopen this issue

[daschw]

You need StatsPlots to plot distributions.

using StatsPlots
using Distributions
plot(Normal(3, 5), lw = 3)

works. In the tutorial using StatsPlots happens two plots before. So maybe we should update the tutorial to avoid these confusions.

[Shaun-Regenbaum]

This is a serious problem for beginners who simply want to use dataframes.

[mkborregaard]

First of all, this is not the same issue, just because you get the same error message. Please always open a new issue rather than bumping a dead and closed one.
Also, I strongly doubt that it is a "serious" problem to anyone that they have to load StatsPlots to use DataFrames (note tht the discussion was about Distributions, not DataFrames). That said I think we should simply move the @df macro to Plots.