How to plot histogram based on bin width and bin height?

plotting

#1

e.g:
given:
Bins: [0,1), [1,2)
Height: [3,5]


#2

What plotting packages have you tried using?


#3

Plots.jl and Gadfly.jl


#4

In VegaLite.jl it would look like this:

using DataFrames, VegaLite

df = DataFrame(bin_start=[0., 1.], bin_end=[1,2.], count=[3,5])

df |>
  @vlplot(:bar, x={:bin_start, bin=:binned, axis={tickStep=1}}, x2=:bin_end, y=:count)

That right now returns:
example

Unfortunately the x axis labels are not looking great… I think that is a bug in vega-lite 2.x (the underlying JavaScript library that produces the actual plot). If I run the same spec through vega-lite 3.0.0-rc8 I get something that looks right:
visualization%20(3)

So I guess the story is that once vega-lite 3.0.0 is released, I will update VegaLite.jl to use it, and then it should look good out of the box. For now, one thing you can do is to plot the thing then click the button to open the spec in the “Vega Editor”. That will open up the online vega-lite editor, and that is based on vega-lite 3.0.0-rc8, and things look good there. You can then download the plot from there. Certainly not good, but the best option right now until the new version is released.

Oh, and the docs for pre-binned histograms is here.


#5

Thx for the reply, currently trying to use some native Julia libs.


#6

Isn’t Plots.jl using a non native Julia backend in the same way that VegaLite.jl does? I think the only pure Julia story is Gadfly.jl.


#7

Good point, it’s deceiving since Plots.jl sounds like a native name.


#8

Actually, I think Winston.jl might also be pure Julia? But not sure whether it is still maintained.

In general, I think you’ll find more options if you include Julia wrappers of non-Julia packages. Some of them work really well.


#9

Gadfly has Geom.bar (and Geom.histogram). See the gallery examples here: http://gadflyjl.org/stable/gallery/geometries.html
or more info in the library:
http://gadflyjl.org/stable/lib/geometries.html.


#10

AFAIU Makie is using OpenGL at the end of the pipeline to physically “draw” primitives but the logic converting a custom julia type (or a combination of those) to a set of primitives to be drawn is in Julia. This is Plots logic taken to the extreme (Plots has a bit of a hybrid approach and sometimes out-sources “non-primitive” drawings to the backend). The trade-off in my mind is that “one-to-one” wrappers to a mature library in another language (and there are many excellent examples, PlotlyJS, PyPlot, VegaLite…) can refer user to the library documentation and are generally more “time-tested” (especially to plot objects that can be easily translated across languages, say vectors or tables of strings or numbers) whereas the Plots / Makie “recipe” approach shines when plotting custom Julia types.


#11

@piever, good point!

I guess the question is why one wants a pure julia solution. If it is mainly to avoid dependencies that might go wrong, then probably Gadfly.jl and Winston.jl are the best (and maybe only?) option. If it is because one wants all the logic in pure julia, but less about dependency management, then Plots.jl and Makie.jl probably also fit the bill.

I think we still don’t have a good handle on the binary dependency story in the plotting area… I think as long as Cairo.jl and Rsvg.jl depend on things like winrpm and homebrew, we won’t really see a super stable situation that “just works”. It has gotten much better, but I’m still getting a lot of errors reports that VegaLite.jl doesn’t install properly, and they all turn out to be Cairo.jl deployment issues. Whoever gets the whole Gtk.jl/Cairo.jl/Rsvg.jl stack moved over to BinaryBuilder.jl will be my hero forever!!