Inconsistent behavior among backends for x and y of different length

[juliohm]

I spent almost an hour trying to debug an algorithm thinking that it had a bug when actually the plot function was doing some magic behind the scenes:

x = collect(1:200)
y = collect(1:100)

plot(x,y)

As you can see, the plot is cycled whenever the input vectors have different length. Is there a good rationale for doing this instead of throwing an error or warning the user?

[lnacquaroli]

I can reproduce it with pyplot() backend.
However, with gr() I am getting the following:

using Plots
gr()
x = collect(1:200)
y = collect(1:100)
plot(x,y)
Error showing value of type Plots.Plot{Plots.GRBackend}: ERROR: BoundsError: attempt to access 100-element Array{Int64,1} at index [1:200] Stacktrace: [1] throw_boundserror(::Array{Int64,1}, ::Tuple{UnitRange{Int64}}) at ./abstractarray.jl:433 [2] checkbounds at ./abstractarray.jl:362 [inlined] [3] getindex(::Array{Int64,1}, ::UnitRange{Int64}) at ./array.jl:526 [4] gr_display(::Plots.Subplot{Plots.GRBackend}, ::Measures.Length{:mm,Float64}, ::Measures.Length{:mm,Float64}, ::Array{Float64,1}) at /home/leniac/.julia/v0.6/Plots/src/backends/gr.jl:973 [5] gr_display(::Plots.Plot{Plots.GRBackend}) at /home/leniac/.julia/v0.6/Plots/src/backends/gr.jl:551 [6] _display(::Plots.Plot{Plots.GRBackend}) at /home/leniac/.julia/v0.6/Plots/src/backends/gr.jl:1326 [7] display(::Base.REPL.REPLDisplay{Base.REPL.LineEditREPL}, ::MIME{Symbol("text/plain")}, ::Plots.Plot{Plots.GRBackend}) at /home/leniac/.julia/v0.6/Plots/src/output.jl:149 [8] display(::Base.REPL.REPLDisplay{Base.REPL.LineEditREPL}, ::Plots.Plot{Plots.GRBackend}) at ./REPL.jl:125 [9] display(::Plots.Plot{Plots.GRBackend}) at ./multimedia.jl:194 [10] eval(::Module, ::Any) at ./boot.jl:235 [11] print_response(::Base.Terminals.TTYTerminal, ::Any, ::Void, ::Bool, ::Bool, ::Void) at ./REPL.jl:144 [12] print_response(::Base.REPL.LineEditREPL, ::Any, ::Void, ::Bool, ::Bool) at ./REPL.jl:129 [13] (::Base.REPL.#do_respond#16{Bool,Base.REPL.##26#36{Base.REPL.LineEditREPL,Base.REPL.REPLHistoryProvider},Base.REPL.LineEditREPL,Base.LineEdit.Prompt})(::Base.LineEdit.MIState, ::Base.AbstractIOBuffer{Array{UInt8,1}}, ::Bool) at ./REPL.jl:646

[juliohm]

Thank you @lnacquaroli , it seems that this issue is PyPlot specific then.

[lnacquaroli]

So it seems, although when using PyPlot (outside Plots) I get an empty plot with the following error:

plot(x,y)
ERROR: PyError (ccall(@pysym(:PyObject_Call), PyPtr, (PyPtr, PyPtr, PyPtr), o, arg, C_NULL)) <type 'exceptions.ValueError'> ValueError(u'x and y must have same first dimension, but have shapes (200,) and (100,)',) File "/usr/lib/python2.7/dist-packages/matplotlib/pyplot.py", line 3318, in plot ret = ax.plot(*args, **kwargs) File "/usr/lib/python2.7/dist-packages/matplotlib/__init__.py", line 1894, in inner return func(ax, *args, **kwargs) File "/usr/lib/python2.7/dist-packages/matplotlib/axes/_axes.py", line 1406, in plot for line in self._get_lines(*args, **kwargs): File "/usr/lib/python2.7/dist-packages/matplotlib/axes/_base.py", line 407, in _grab_next_args for seg in self._plot_args(remaining, kwargs): File "/usr/lib/python2.7/dist-packages/matplotlib/axes/_base.py", line 385, in _plot_args x, y = self._xy_from_xy(x, y) File "/usr/lib/python2.7/dist-packages/matplotlib/axes/_base.py", line 244, in _xy_from_xy "have shapes {} and {}".format(x.shape, y.shape)) ...

[juliohm]

Yes, this is definitely some Plots.jl magic, not something from Matplotlib.

[mkborregaard]

Plots is intended to cycle input arguments, this allows you to do things like scatter(1:4, [1]). But it's a good question why the backends are inconsistent! Plotlyjs has a third behaviour - it plots (1:100, 1:100). I hope you're OK with my renaming of the issue.

[lnacquaroli]

I think plotlyjs behavior might be the most tolerable world if one wants to prevent error messages without falling into misunderstanding like pyplot cycling. Cycling the data explicitly is preferred overall, IMO.

[juliohm]

There are so many inconsistencies across backends, I think we can focus the work and efforts in the Makie ecosystem with new recipes and so on. Closing this for now.

[mkborregaard]

@juliohm you've closed a number of issues without posting reasons. Is that because the issues no longer exist, or do you just want to (like above) signal that they are low priority for you?

[juliohm]

Most of them were too old and I could hardly reproduce given how much the projects evolved. So if something shows up after the refactoring in vizcon people can open more recent issues. They were just polluting the issue tracker.

…

On Wed, Mar 4, 2020, 07:56 Michael Krabbe Borregaard < ***@***.***> wrote: @juliohm <https://github.com/juliohm> you've closed a number of issues without posting reasons. Is that because the issues no longer exist, or do you just want to (like above) signal that they are low priority for you? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#1151?email_source=notifications&email_token=AAZQW3IIMAOQPHNUNEGWUVLRFYXVBA5CNFSM4D6HZCTKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOENXKJSA#issuecomment-594453704>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAZQW3JZ3U3NOQZGQOVQT4DRFYXVBANCNFSM4D6HZCTA> .

[mkborregaard]

ok cool