search

MakieOrg / Makie.jl

Interactive data visualizations and plotting in Julia
https://docs.makie.org/stable
MIT License
2.38k stars 302 forks source link

orientation versus direction #926

Open piever opened 3 years ago

piever commented 3 years ago

It seems there's a bit of a split in the API between orientation = :horizontal, :vertical or direction = :x, :y

https://github.com/JuliaPlots/AbstractPlotting.jl/search?q=direction

https://github.com/JuliaPlots/AbstractPlotting.jl/search?q=orientation

Happy to make a PR to fix it if we agree on which ones to change.

jkrumbiegel commented 3 years ago

I agree, should be straightened out. What do you like better? I think it's quite hard to name it so it's immediately clear what's meant. I like if the symbols :x and :y are used just because they're short. But maybe horizontal and vertical are clearer because they imply more of an orientation? A barplot that goes along the y axis is what I would call a horizontal barplot. But I would call a density that goes along the x axis horizontal 🤔

piever commented 3 years ago

I see your point... It is even worse with things like density versus violin...

I think that this attribute should determine how the vectors that the user passes are mapped to the axes, to allow for reliable labeling. I see two ways forward.

Option 1

We go with orientation = :vertical for things that respect the default, orientation = :horizontal for those who don't. In particular, density and histogram would have horizontal orientation by default (which represents how we plot them at the moment). This makes a reasonable amount of sense, in that for example a orientation = :horizontal density plot would be fully consistent with orientation = :horizontal violin.

Option 2

In this case, I would call the attribute something like flip, transpose, or permutedims. The only odd thing is that scatter(rand(10)) does not respect this criterion, so it would have to set flip = true by default. If we go for this, I suspect we should just stop the automatic conversion rand(10) -> (1:10, rand(10)).

kescobo commented 3 years ago

I like option 1, possibly with the option do do orientation = :flip, which would give you whichever of [:horizontal, :vertical] is not the default for that plot type

jtrakk commented 3 years ago

In three dimensions, there are more options than just "flipped" and "not flipped". "Permuted dims" may be right abstraction.

roland-KA commented 3 years ago

I'm not an Makie expert. But perhaps a look from the "outside" may help a bit. I did a comparison of (now four) Julia graphics packages on creating statistical plots (see: https://github.com/roland-KA/StatisticalPlotsWithJulia).

It was not quite easy for me to figure out that direction = :x is the way (using Makie/AlgebraOfGraphics) to turn a bar plot from it's vertical layout into a horizontal position (apart from the problems I had to get useful ticks and labels on the x- and y-axis).

Other packages use the following:

mkborregaard commented 3 years ago

(You can also use orientation = :horizontal with Plots)

roland-KA commented 3 years ago

(You can also use orientation = :horizontal with Plots)

So using orientation = :horizontal in Makie as well would create a consistency across three graphics packages in the Julia universe, which could be helpful in understanding and using the package.

jtrakk commented 3 years ago

Makie differs in many ways from Plots, I think it's more important to get the API right than similar to another package.

rapus95 commented 2 years ago

How about abstracting the symbols away into new type instances (with a mapping function that maps previous symbols to those new type instances and informs about the deprecatedness)? That way we have a clear decoupling from all other packages.

For extensibility towards more dimensions one could make it an interface that needs to provide a function that maps/reorders arguments to axes. Then, always plot with the first argument to the right and the 2nd upwards as the dimensions are indexed in mathematics.

But at the same time we then should move away from xtick and ytick and instead call it something different since they should also follow the plot-orientation.