here's a very concrete feature request: In gretl's GUI window for gnuplot there's still some space below the drop-down list for the point symbol (which applies at least to "points" and "lines-points" styles). IMO it would be useful to put a box there to specify the point size; for example, a value of 0.5 would imply adding "ps 0.5" to the respective gnuplot command line. The box could be exactly like the one for linewidth, but of course would only be active whenever the point type selector is active as well.

As a more general remark, I've learned that with gnuplot 5 it seems easier (compared to gnuplot 4) to handle the data values that are given "inline" in the gnuplot file, by specifying a named "datablock". Stuff like shaded areas and so forth should be easier to achieve from gretl's side I guess. But Debian for example switched to gnuplot 5 less than a year ago (if I understand correctly, but could be wrong?). I wonder what an acceptable timeframe for gretl would be to require gnuplot 5.

My suggestion would be to switch to gnuplot v5 as soon as all these stable releases have prebuilt packages available, where an official backport would be good enough IMHO. Admittedly that might mean problems for users who want to keep using Ubuntu 14.04 LTS, for example. But you wouldn't want to wait until 2019 or so when that is offically retired.

On Thu, 28 Jan 2016, Sven Schreiber wrote: > My suggestion would be to switch to gnuplot v5 as soon as all these > stable releases have prebuilt packages available, where an official > backport would be good enough IMHO. Admittedly that might mean problems > for users who want to keep using Ubuntu 14.04 LTS, for example. But you > wouldn't want to wait until 2019 or so when that is offically retired. There's the non-deb world to monitor too. Fedora etc, plus Arch, SUSE and so on. (BSD is dead anyway ;) )

I learned (again?) that dashed lines seem to be much better handled in gnuplot v5. IMHO yet another reason to push for the switch. The situation on Ubuntu appears better than I thought: "gnuplot5 vivid (math): version 5 [universe] 5.0.0~rc+dfsg2-1: all wily (math): version 5 [universe] 5.0.1+dfsg1-3: all xenial (math): version 5 [universe] 5.0.3+dfsg2-1: all " As 'vivid' is 15.04, next month it will be one year when gnuplot 5 is easily available. Version 16.04 will be a LTS release for those people that do not want to upgrade often (which I absolutely understand). I also understand that people wait a month or two before upgrading their distro, but IMHO switching to gnuplot 5 for gretl in June 2016 would not be a major problem. (A minor problem it would be anyway I guess, since things have to be adjusted of course.)

Am 28.01.2016 um 10:25 schrieb Sven Schreiber: > Am 27.01.2016 um 22:31 schrieb Allin Cottrell: >> On Wed, 27 Jan 2016, Sven Schreiber wrote: >> >>> here's a very concrete feature request: In gretl's GUI window for >>> gnuplot there's still some space below the drop-down list for the >>> point symbol (which applies at least to "points" and "lines-points" >>> styles). >>> >>> IMO it would be useful to put a box there to specify the point size; >>> for example, a value of 0.5 would imply adding "ps 0.5" to the >>> respective gnuplot command line. The box could be exactly like the one >>> for linewidth, but of course would only be active whenever the point >>> type selector is active as well. >> >> There's now an attempt at this in git. No doubt there are bugs that need >> to be beaten out of it. > > thanks -- will tests ASAP. > I see the dialog box in the latest snapshot. The "ps" setting doesn't make it into the gnuplot commands, though, and I don't see any effect.

Also, it would be nice if somehow the new box didn't need a new "line"/row on its own. I also notice that the "data scale" field fills the entire row width, although it's just a single number just as the linewidth and point size values. Almost the same for the y-axis chooser, doesn't need the full row width.

On Thu, 28 Jan 2016, Allin Cottrell wrote:

> > Ah, in my testing I changed the point-type as well as the point size, > and it works fine. But I now see that if you don't change the point > type, then the point-size selection doesn't get applied. (In the > background gretl must be thinking that "nothing has changed"). Should > be quite easily fixable. That's now fixed. Plus, the layout under the Lines tab may now be more to your taste.

Am 31.01.2016 um 12:12 schrieb Sven Schreiber: > > One unrelated thing: I don't remember how the creation of a secondary > y-axis used to work, but now I'm having difficulties finding how to add > that (if it's not added by gretl automatically in the first place).

P.S.: Wasn't there recently also some "data scaling" option as a setting for the individual lines? I'm not seeing that with today's/yesterday's snapshot anymore.

Am 31.01.2016 um 15:14 schrieb Allin Cottrell: > On Sun, 31 Jan 2016, Sven Schreiber wrote: > >> Am 31.01.2016 um 12:12 schrieb Sven Schreiber: >>> >>> One unrelated thing: I don't remember how the creation of a secondary >>> y-axis used to work, but now I'm having difficulties finding how to add >>> that (if it's not added by gretl automatically in the first place). > > Example: open Ramanathan data9-7 and create a time-series plot with > PRIME and UNEMP. The two series share a single y-axis. Open the graph > editor and select the Lines tab. Under line 1 select "right" from the > y-axis selector. Click "Apply": this adds a secondary y-axis and > attaches PRIME to it. See below. > >> P.S.: Wasn't there recently also some "data scaling" option as a setting >> for the individual lines? I'm not seeing that with today's/yesterday's >> snapshot anymore. > > To change the scale, type a different value into its "data scale" box. > See the attchment. If you have a case where this box is not shown, > please describe it. > Indeed I remember it exactly as you describe it, but it's different here (= yesterday's snapshot on 32bit Windows 10), and that's the reason: For each line I'm getting the first four "rows" of settings (up to "size"), and I'm not seeing the last row, with "data scale" and "y axis". HOWEVER: In order to be absolutely sure I also did exactly what you said, with the Ramanathan dataset, and then it's actually like you say. Here's a recipe to provoke my problem: - use the data Ramanathan data9-7 - run the following script: <hansl> series s2 = STOCK/10 list pus = PRIME UNEMP s2 matrix m = {pus} gnuplot 2 3 1 --matrix=m --output=display </hansl> - open the graph editor (right-click and edit) and to the lines tab: you shouldn't see the data scale and y-axis settings

Am 01.02.2016 um 01:20 schrieb Allin Cottrell:

> No, I'm not seeing them. The criterion for showing these things hasn't > changed lately. It's debatable, no doubt, but here it is: > > Either (a) the plot is a regular time-series plot, or (b) it contains at > least one "line" that is already attached to a secondary y-axis. (See > the function show_axis_chooser() in gui2/gpt_dialog.c.) > Ah ok. Then the question would be how to activate the secondary y-axis when the plot is created, so something like the inverse of "--single-yaxis". Right now it seems the user is at the mercy of gretl that decides when the second axis would be good. With respect to time series, so let's start the "debatable" part: It's not clear why the definition of the x-axis would determine what is done with the y-axis.

Hi Sven, a while ago I uploaded the package "plot_ts_y2axis" which you may check. It is uses a very simple example. Actually, I have started to compile a kind of "plotting-library" which comprises different scripts calling gnuplot for specific purposes in flexible manner, e.g. draw scatter/time-series plots with 2-axis, adjust different things easily like labels, line width etc., draw shaded regions, draw contour plots etc. I think it would be worth if we could collect such user-written scripts for a function package which acts similar to a plotting-library.

On Wed, 23 Mar 2016, Sven Schreiber wrote:

>> >> With respect to time series, so let's start the "debatable" part: It's >> not clear why the definition of the x-axis would determine what is done >> with the y-axis. > > Still think this sounds reasonable. I agree. I've now relaxed the criterion in the GUI plot editor. Provided the plot has at least two lines you will now get a y-axis chooser for each line (regardless of whether or not it's a time-series plot). Should there also be an option mechanism for specifying y-axis choices via script? Probably, but that will be more work.