Menu
▾
▴
gnuplot-beta
|
From: Dima K. <gn...@di...> - 2020-08-06 06:46:16
|
A question. I'm looking at the violin plot demo page: http://gnuplot.sourceforge.net/demo/violinplot.html It shows how to make a horizontal density plot using 'smooth kdensity'. Then it shows to to make a vertical density plot by plotting horizontally into a table, and then plotting the table, with "using" directives used to swap the axes. This works clearly, but is there a way to do this (vertical density plots) with a single plot command? That would make my life much easier. Thanks! |
|
From: Juhász P. <pet...@gm...> - 2020-08-14 17:35:01
|
On Wed, 2020-08-05 at 23:46 -0700, Dima Kogan wrote: > A question. I'm looking at the violin plot demo page: > > http://gnuplot.sourceforge.net/demo/violinplot.html > > It shows how to make a horizontal density plot using 'smooth > kdensity'. > > Then it shows to to make a vertical density plot by plotting > horizontally into a table, and then plotting the table, with "using" > directives used to swap the axes. This works clearly, but is there a > way > to do this (vertical density plots) with a single plot command? That > would make my life much easier. > > Thanks! > > > Well, recently at $work I used gnuplot to produce a sideways histogram. Because it had to be sideways, I had to resort to manually assembling the plot with the boxxyerror style, with an awkward preprocessing step. This, and your question, gives me the idea that it might be worth adding a general 'transpose' option to some of the "clever" plot styles that produce non-trivial vertical plots (histograms and boxplots, mostly). best regards, Peter Juhasz |
|
From: Ethan A M. <me...@uw...> - 2020-08-15 20:20:18
|
On Friday, 14 August 2020 10:34:52 PDT Juhász Péter wrote: > On Wed, 2020-08-05 at 23:46 -0700, Dima Kogan wrote: > > A question. I'm looking at the violin plot demo page: > > > > http://gnuplot.sourceforge.net/demo/violinplot.html > > > > It shows how to make a horizontal density plot using 'smooth > > kdensity'. > > > > Then it shows to to make a vertical density plot by plotting > > horizontally into a table, and then plotting the table, with "using" > > directives used to swap the axes. This works clearly, but is there a > > way > > to do this (vertical density plots) with a single plot command? That > > would make my life much easier. > > > > Thanks! > > > > > > > > Well, recently at $work I used gnuplot to produce a sideways histogram. > Because it had to be sideways, I had to resort to manually assembling > the plot with the boxxyerror style, with an awkward preprocessing step. > > This, and your question, gives me the idea that it might be worth > adding a general 'transpose' option to some of the "clever" plot styles > that produce non-trivial vertical plots (histograms and boxplots, > mostly). > > best regards, > Peter Juhasz "How to make a sideways plot" does seem to be a very frequently asked question. There may be some clever way to select an x/y axis transposition in the general case, but if so I have not been able to find it. The program was designed from the start to have a single 2D plot mode with x always horizontal, and a single 3D plot mode with z always perpendicular to to horizontal axis. It would be possible to introduce a third plot mode with x vertical and y horizontal, but that would have to essentially duplicate all the existing code in plot2d.c and graphics.c, which I think is far too much effort and code for only a little gain. It is easier to relax the restrictions on the 3D plot mode. Over time the program has gained the options - "set view map" reproduces the x-horizontal y-vertical 2D layout. This allow use of 3D plot styles but does not address the current request. - "set view azimuth" relaxes the requirement that the z axis of a 3D plot must be perpendicular to the horizontal. This allows 3D view conventions such as altitude-azimuth that were not previously possible. - "set view projection [xz|yz]". These are new in version 5.4 They do allow a "sideways" plot layout, with two drawbacks: 1) it only supports the subset of styles in "splot" rather than "plot" 2) the horizontal axis is z (not y), which is a bit confusing I think there is room to build on this last idea in a couple of ways. The 1st drawback could be addressed by extending more of the 2D plot styles to work with "splot". Currently these styles work in projection: points lines vectors impulses filledcurves/polygons (2D and 3D not quite the same) boxes boxerrorbars (just added, conditional on #ifdef BOXERROR3D) Smoothing is currently limited to csplines. Adding kdensity smoothing to the 3D code would be easy, which might address Peter's current request. But we will undoubtedly continue to see requests for sideways histograms, boxplots, etc. Those would not be so easy to extend to 3D. The 2nd drawback may have a clever solution, although I do not see immediately how it would work. Would it be possible to hide the x-is-now-y, z-is-now-x coordinate replacement at the input stage so that the user doesn't have to worry about it? How? I have been thinking about adding a new demo to show that "set view projection xz" can produce many "sideways" plot styles, but haven't done much about it yet. It needs to use some class of data that legitimately benefits from the horizontal rather than vertical layout. Just turning an existing plot sideways is not IMHO particularly useful. Peter - would the plot you constructed by hand be a good example to adapt? If the combination set view projection xz splot ... with boxerror doesn't handle it adequately, that would highlight where it would be worth some additional work on the code. Ethan |
|
From: Dima K. <gn...@di...> - 2020-08-15 20:51:45
|
If we add better support for these, I think supporting more general transformations than just a simple x/y transpose would be useful. While thinking of violin plots I had a workaround idea: instead of a set of horizontally-spaced vertical density plots, I'd be fine with a set of vertically-spaced horizontal density plots. But I think gnuplot currently can't do that either: the density plots must be horizontal AND they must start at y=0. Right? So being able to support translations would be nice. |
|
From: Juhász P. <pet...@gm...> - 2020-08-16 18:52:15
|
On Sat, 2020-08-15 at 13:17 -0700, Ethan A Merritt wrote: > On Friday, 14 August 2020 10:34:52 PDT Juhász Péter wrote: > > On Wed, 2020-08-05 at 23:46 -0700, Dima Kogan wrote: > > > A question. I'm looking at the violin plot demo page: > > > > > > http://gnuplot.sourceforge.net/demo/violinplot.html > > > > > > It shows how to make a horizontal density plot using 'smooth > > > kdensity'. > > > > > > Then it shows to to make a vertical density plot by plotting > > > horizontally into a table, and then plotting the table, with > > > "using" > > > directives used to swap the axes. This works clearly, but is > > > there a > > > way > > > to do this (vertical density plots) with a single plot command? > > > That > > > would make my life much easier. > > > > > > Thanks! > > > > > > > > > > > > > Well, recently at $work I used gnuplot to produce a sideways > > histogram. > > Because it had to be sideways, I had to resort to manually > > assembling > > the plot with the boxxyerror style, with an awkward preprocessing > > step. > > > > This, and your question, gives me the idea that it might be worth > > adding a general 'transpose' option to some of the "clever" plot > > styles > > that produce non-trivial vertical plots (histograms and boxplots, > > mostly). > > > > best regards, > > Peter Juhasz > > "How to make a sideways plot" does seem to be a very > frequently asked question. There may be some clever way to select > an x/y axis transposition in the general case, but if so I have not > been > able to find it. > I might have mislead the discussion with my suggestion, because as it turns out, the only common thing it has with the original violin plot question is "would there be a way to do X in a single command". Sorry for the confusion. That said, I don't think bringing in 3D (s)plot styles is a good direction towards a general solution for sideways plots. To me, it sounds like looking for our lost car keys in the corner only because that's where there is light. > The program was designed from the start to have a single 2D plot mode > with x always horizontal, [...] Yes, originally it was designed like that, but then more complex plot styles like histograms and boxplots were added, which do non-trivial preprocessing and aggregating steps before plotting the data. For boxplots (and less acutely, even for histograms) the x axis of the plot is no longer directly maps to any column of the original data. > Peter - would the plot you constructed > by hand be a good example to adapt? If the combination > set view projection xz > splot ... with boxerror > doesn't handle it adequately, that would highlight where it would > be worth some additional work on the code. No, not really, unless I misunderstand you - my point was that I wanted to produce (IIRC) a columnstacked histogram, and if it could have been a vertical plot, I could have used `set style histogram columnstacked; set style data histogram`, with all the nice intuitive data layout and all the automatic box placement that style provides. But the requirements called for a horizontal plot, so I had to do all that by hand. Doing the same in 3D wouldn't have helped. Peter > > Ethan > > |
|
From: Ethan A M. <me...@uw...> - 2020-08-15 22:56:12
|
On Saturday, 15 August 2020 13:51:32 PDT Dima Kogan wrote: > If we add better support for these, I think supporting more general > transformations than just a simple x/y transpose would be useful. While > thinking of violin plots I had a workaround idea: instead of a set of > horizontally-spaced vertical density plots, I'd be fine with a set of > vertically-spaced horizontal density plots. But I think gnuplot > currently can't do that either: the density plots must be horizontal AND > they must start at y=0. Right? So being able to support translations > would be nice. I may not understand what you want. kdensity smoothing is a sum of Gaussians, so by definition the baseline is zero. That is not a limitation of how gnuplot plots things, that is the definition of the function being plotted. You can of course save the resulting curve and plot it with an offset on y, just as the violin plot demo replots it vertically with an offset on x. Are you trying to avoid the extra step of saving to an array or datablock and then replotting? That seems like a totally different question from vertical/horizontal layout or coordinate transformations. Ethan |
|
From: Dima K. <gn...@di...> - 2020-08-15 23:37:47
|
Ethan A Merritt <me...@uw...> writes: > Are you trying to avoid the extra step of saving to an array or > datablock and then replotting? That seems like a totally different > question from vertical/horizontal layout or coordinate > transformations. Yes. Avoiding that extra step is the question in this thread; see the subject. I've never tried to plot sideways histograms, like Peter did; I was assuming that this is simple if we plot into a datablock and then replot, but maybe not. In any case, here's my problem. I use gnuplot A LOT. But 99% of that usage is via one of two wrappers (I wrote both of these): feedgnuplot (a nice shell interface) gnuplotlib (a nice python interface) Both of these work as thin wrappers around gnuplot, the idea being that with some "set" commands and a fancy "plot" command you can do anything. As it currently stands, violin plots are apparently not a part of this "anything". One could say that my wrappers are silly and not flexible-enough. Which maybe is true, but realistically speaking, I don't see ever expanding these tools to use datablocks, since that would break all sorts of interface assumptions both of these tools are making. So I can live without violin plots, or maybe go use matplotlib. Which I'd rather not do. Any suggestions appreciated. |
|
From: Ethan A M. <me...@uw...> - 2020-08-16 02:58:29
|
On Saturday, 15 August 2020 16:37:35 PDT Dima Kogan wrote: > Ethan A Merritt <me...@uw...> writes: > > > Are you trying to avoid the extra step of saving to an array or > > datablock and then replotting? That seems like a totally different > > question from vertical/horizontal layout or coordinate > > transformations. > > Yes. Avoiding that extra step is the question in this thread; see the > subject. I've never tried to plot sideways histograms, like Peter did; I > was assuming that this is simple if we plot into a datablock and then > replot, but maybe not. > > In any case, here's my problem. I use gnuplot A LOT. But 99% of that > usage is via one of two wrappers (I wrote both of these): > > feedgnuplot (a nice shell interface) > gnuplotlib (a nice python interface) > > Both of these work as thin wrappers around gnuplot, the idea being that > with some "set" commands and a fancy "plot" command you can do anything. > As it currently stands, violin plots are apparently not a part of this > "anything". One could say that my wrappers are silly and not > flexible-enough. Which maybe is true, but realistically speaking, I > don't see ever expanding these tools to use datablocks, since that would > break all sorts of interface assumptions both of these tools are making. I don't get it. What is it about the shell interface that would prevent you from doing exactly what is in violinplot.dem? set table $datablock plot ... unset table plot $datablock ... Ethan |
|
From: Dima K. <gn...@di...> - 2020-08-16 05:06:47
|
Ethan A Merritt <me...@uw...> writes: > > I don't get it. What is it about the shell interface that would prevent you > from doing exactly what is in violinplot.dem? > set table $datablock > plot ... > unset table > plot $datablock ... Both gnuplotlib and feedgnuplot work as very thin wrappers around gnuplot, where they pass strings directly to gnuplot without knowing what the strings mean. This allows those interfaces to support lots and lots of styles, while containing no code that makes those styles work: all the logic is inside gnuplot itself. The double-plotting in violinplot.dem is qualitatively different than pretty much every other gnuplot style, so I would need to add special-case support for it. I COULD do that, but I really don't want to: the really simple API of feedgnuplot and gnuplotlib is a feature, and this special-case path would dilute that feature. In a perfect world we'd be able to make violin plots like all others: with some "set" commands (that don't have the data in it) and a single plot/splot command that is given data. That is sounding like a big project inside gnuplot, though. |
|
From: Ethan A M. <me...@uw...> - 2020-08-16 06:24:12
|
On Saturday, 15 August 2020 22:06:34 PDT Dima Kogan wrote:
> Ethan A Merritt <me...@uw...> writes:
> >
> > I don't get it. What is it about the shell interface that would prevent you
> > from doing exactly what is in violinplot.dem?
> > set table $datablock
> > plot ...
> > unset table
> > plot $datablock ...
>
> Both gnuplotlib and feedgnuplot work as very thin wrappers around
> gnuplot, where they pass strings directly to gnuplot without knowing
> what the strings mean. This allows those interfaces to support lots and
> lots of styles, while containing no code that makes those styles work:
> all the logic is inside gnuplot itself. The double-plotting in
> violinplot.dem is qualitatively different than pretty much every other
> gnuplot style, so I would need to add special-case support for it. I
> COULD do that, but I really don't want to: the really simple API of
> feedgnuplot and gnuplotlib is a feature, and this special-case path
> would dilute that feature.
>
> In a perfect world we'd be able to make violin plots like all others:
> with some "set" commands (that don't have the data in it) and a single
> plot/splot command that is given data. That is sounding like a big
> project inside gnuplot, though.
I guess I still don't get it.
Since the wrapper can pass in any necessary set of commands,
why not just pass in the commands that do the double plot?
Would it help to have a library of helper scripts for gnuplot?
Here's one that creates a vertical violin plot from a single gnuplot
command. You could obviously add a lot of customization either
by passing in additional parameters or defining them globally.
gnuplot> set term pngcairo
gnuplot> set output 'violin.png'
gnuplot> # unit width violin plot centered at x=10., linetype 3
gnuplot> call 'violin.gp' 'filename.dat' 10. 3
violin.gp script follows
%%%%%%%%%%%%%%%%%%%%%%%%
#
# invoke this script from inside gnuplot using
# call violin.gp filename xcenter linetype
#
filename = ARGV[1]
xcenter = ARGV[2]
LT = ARGV[3]
#
set xrange [*:*]
set table $kdensity
plot filename using 2:(1) smooth kdensity with filledcurves above x1
unset table
stats $kdensity using 2 noout
plot [0:20][0:*]\
$kdensity using (xcenter + column(2)/STATS_max):1 with filledcurves x=xcenter lt LT, \
$kdensity using (xcenter - column(2)/STATS_max):1 with filledcurves x=xcenter lt LT
#
%%%%%%%%%%%%%%%%%%%%%%%%%
|
|
From: Dima K. <gn...@di...> - 2020-08-16 20:20:21
|
Ethan A Merritt <me...@uw...> writes: > I guess I still don't get it. > Since the wrapper can pass in any necessary set of commands, > why not just pass in the commands that do the double plot? Because my tools would then need special-case logic for this one case. I would need some sort of "feedgnuplot --violin" and logic internally to handle it. At the very start I decided that explicitly supporting everything gnuplot supports with such special-case logic would be extremely effortful and extremely error-prone and maintenance-full. And I avoided the issue entirely by passing user-specified strings to gnuplot transparently. Which works great for most styles. If (as a random example) I have 3-column input that I want to plot as errorbars I can do this: < 3columns_datafile feedgnuplot --domain --tuplesizeall 3 --with yerrorbars feegnuplot then knows to be dealing with 3-values-per-point data, and tells gnuplot to plot with "yerrorbars". There's no special-case logic for "yerrorbars". And I don't want to create a separate path for violin plots. Full disclosure: there IS one special-case path to deal with histograms. But those are extremely useful, and worth violating the general design. violin plots aren't nearly as ubiquitous, and I dont want to add a big special-case path for them. |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X