gnuplot-beta — Developers and beta testers of new gnuplot code

Re: Problems with while/splot/wxt

[Philipp K. J. <ja...@ie...>]

[snip]

> > Sometimes not even that. It has to be killed externally.
> 
> I suspect it would work to hit ctrl-C twice in quick
> succession.  There is an extra check for pretty much
> exactly this case.

Is this "double-Control-C" (which does work!)
mentioned anywhere in the documentation?

[snip]

Re: Plans for gnuplot version 5

[Goodluck L. <goo...@gm...>]

About some features I have suggested long ago, could someone tell me
how are they progressing?

[multiple keys]
[multiple files in the same using spec]
[arrays]
[control over dashed lines]

gbliu


在 2014-03-06 1:52, Ethan A Merritt 写道:
> On Wednesday, 05 March, 2014 19:18:24 Liu Guibin wrote:
>> I expect that gnuplot can have the following several functions:
> [multiple keys]
> [multiple files in the same using spec]
> [arrays]
> [control over dashed lines]
>
> In general adding a new feature does not break older scripts or familiar usage.
> So in general a new feature can be added at any time; it does not need to
> wait for a transition from one major release to the next, in this case version 4
> to version 5.
>
> The four features you mention are reasonable suggestions.
> That does not mean that it would be easy to implement, but if someone
> someone contributes code for any or all of them I don't see any
> obvious reason why they couldn't be added  when ready without breaking
> backward compatibility.
>
> Two of these, more control over key placement and multiple files contributing
> to a single plot, are already tracked in the Feature Requests section on
> the project development site on SourceForge.  The other two, arrays and
> dashed lines, have been discussed on the mailing list but I do not see
> Feature Request entries for them.  Feel free to add them.
>
> 	Ethan
>
>
>
>
>>
>> <1>.
>>
>> I expect that the keys (legends) can be manipulated in groups in stead
>> of as a whole objects.
>>
>> e.g.
>>
>> set key 1 top right
>> set key 2 bottom left
>> plot 'data' t 't1a' key 1, '' t 't1b' key 1, '' t 't2a' key 2, '' t
>> 't2b' key 2
>>
>> Thus, if I have many legends and there's no space to put them together,
>> I can divide them into two groups
>> "key 1" and "key 2" and put them at different places.
>>
>>
>> <2>.
>>
>> Columns from different files can be calculated together. e.g. I have two
>> files that have the same format, say, 100 row of (x, y) data, named
>> 'file1' and 'file2'. Now I want to plot the different between y columns
>> from the two files.
>>
>> plot 'file1' u 1:($2-column('file2',2)) w lp
>>
>>
>> <3>.
>>
>> I expect gnuplot to have arrays.
>>
>>
>> <4>.
>>
>> I want to set the style of dashed line, that is, how dashed the line is.
>> e.g. - - - - or - - - - or -- -- -- ....
>>
>>
>>
>> gbliu
>>
>>
>> 于 2014-03-05 12:51, sfeam 写道:
>>> Important note:  If there is some behaviour or syntax in gnuplot
>>> that has been annoying you for the last 20 years, please speak up.
>>> This is the best chance you will have to get it changed!
>>
>>
>> ------------------------------------------------------------------------------
>> Subversion Kills Productivity. Get off Subversion & Make the Move to Perforce.
>> With Perforce, you get hassle-free workflows. Merge that actually works.
>> Faster operations. Version large binaries.  Built-in WAN optimization and the
>> freedom to use Git, Perforce or both. Make the move to Perforce.
>> http://pubads.g.doubleclick.net/gampad/clk?id=122218951&iu=/4140/ostg.clktrk
>> _______________________________________________
>> gnuplot-beta mailing list
>> gnu...@li...
>> Membership management via: https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
>>

Re: Problems with while/splot/wxt

[sfeam <sf...@us...>]

On Thursday, 12 February 2015 05:08:09 PM Philipp K. Janert wrote:
> 
> I seem to be encountering a problem when running
> splot in a loop. 
> 
> Assume this is in a file called "script.gp":
> 
> t = 0
> while( 1 ) {
>   t = t + 0.1
>   splot [][][-1:1] cos(sqrt(x**2+y**2) - t)
> }
> 
> Then 
> 	load "script.gp"
> runs fine and can be stopped w/ Control-C.
> 
> Now, let's assume that I let it run for a few
> seconds, then stop it, then "load" the script
> again. After about 2 or 3 repetitions of this
> cycle, gnuplot becomes unresponsive - sometimes
> printing the following message:
> 
> 	wxt display server shutting down - no response
> 	Gnuplot not exited using gp_exit(). Exit handlers may not work
> 	correctly!
> 
> Sometimes not even that. It has to be killed externally.

I suspect it would work to hit ctrl-C twice in quick
succession.  There is an extra check for pretty much
exactly this case.

> Is this known behavior?

Well what did you expect?

You put the program in an infinite loop sending messages
from one process (gnuplot main program) to another
(outboard wxt driver running in a separate thread)
with no delay in the loop.
So the communication channel between them is presumably
saturated.  Then you kill one end with ^C, probably
truncating the last message sent.  Is it any
wonder that the other end of the channel is left waiting for
completion of that last message, which never comes?


> I have no idea how to
> debug this. (The problem is not an overflow 
> of "t". I checked that.)

I don't really see anything to debug.
Try ^C ^C.
If that doesn't work then open up gdb -p <pid>
using the pid of the hung process and type
"where" to find where it is stuck.
But I'll bet it's waiting for a poll() operation
on the communication channel which is now defunct.

	Ethan

Problems with while/splot/wxt

[Philipp K. J. <ja...@ie...>]

I seem to be encountering a problem when running
splot in a loop. 

Assume this is in a file called "script.gp":

t = 0
while( 1 ) {
  t = t + 0.1
  splot [][][-1:1] cos(sqrt(x**2+y**2) - t)
}

Then 
	load "script.gp"
runs fine and can be stopped w/ Control-C.

Now, let's assume that I let it run for a few
seconds, then stop it, then "load" the script
again. After about 2 or 3 repetitions of this
cycle, gnuplot becomes unresponsive - sometimes
printing the following message:

	wxt display server shutting down - no response
	Gnuplot not exited using gp_exit(). Exit handlers may not work
	correctly!

Sometimes not even that. It has to be killed
externally.

Is this known behavior? I have no idea how to
debug this. (The problem is not an overflow 
of "t". I checked that.)

Best,

		Ph.

Re: Does gnuplot still read commands from stdin?

[Daniel J S. <dan...@ie...>]

On 02/09/2015 12:07 AM, Philipp K. Janert wrote:
>
> No, it doesn't work for me.
>
> Here is the contents of my test script:
>
> set t pngcairo
> plot sin(x)
>
> I invoke it like this:
>
> cat script.gp | gnuplot>  graph.png
>
> When I use gnuplot 4.6 patchlevel 3 (which comes
> with my distro), all is well. But when I use version
> 5, nothing happens - I simply get dropped into an
> interactive session.
>
> Mind you, batch processing works with version 5:
>
> gnuplot5 script.gp>  graph.png
>
> is fine.

Version 5.1 patchlevel 0 works on your test script.

What are you seeing when the shell goes into interactive session?  If I run

gnuplot > graph.png

as if the two sides of the command were treated normally (i.e., not one 
piped into another), the interactive part doesn't work because the 
visual output is sent to graph.png.

How about something in your autoload .gnuplot file that might be causing 
problems.  (Although I can't imagine what that might be.)

Dan

Re: Does gnuplot still read commands from stdin?

[sfeam <sf...@us...>]

On Sunday, 08 February 2015 10:07:42 PM Philipp K. Janert wrote:
> 
> No, it doesn't work for me.
> 
> Here is the contents of my test script:
> 
> set t pngcairo
> plot sin(x)
> 
> I invoke it like this:
> 
> cat script.gp | gnuplot > graph.png

Works fine here using the v5 release and also current CVS.

	Ethan



> 
> When I use gnuplot 4.6 patchlevel 3 (which comes
> with my distro), all is well. But when I use version
> 5, nothing happens - I simply get dropped into an
> interactive session.
> 
> Mind you, batch processing works with version 5:
> 
> gnuplot5 script.gp > graph.png
> 
> is fine.
> 
> 
> Here are the specifics:
> 
> Linux puget 3.11.0-12-generic #19-Ubuntu SMP Wed Oct 9 16:20:46 UTC
> 2013 x86_64 x86_64 x86_64 GNU/Linux
> 
> 
>         G N U P L O T
>         Version 5.0 patchlevel 0    last modified 2015-01-01 
> 
>         Copyright (C) 1986-1993, 1998, 2004, 2007-2015
>         Thomas Williams, Colin Kelley and many others
> 
>         gnuplot home:     http://www.gnuplot.info
>         faq, bugs, etc:   type "help FAQ"
>         immediate help:   type "help"  (plot window: hit 'h')
> 
> 
> On Mon, 9 Feb 2015 00:26:20 -0500
> Jonathan Thornburg <jt...@as...> wrote:
> 
> > Hi,
> > 
> > On Sun, Feb 08, 2015 at 07:37:15PM -0800, Philipp K. Janert wrote:
> > > It used to be possible to pipe commands to gnuplot:
> > > 
> > > 	cat script.gp | gnuplot
> > > 
> > > When I try this with gp5, gnuplot seems to ignore 
> > > the input. 
> > > 
> > > I did not see any comment on this in the documentation
> > > either way. What behavior should I expect?
> > 
> > Piping commands to gnuplot works fine for me with gnuplot 5.0.0
> > running on OpenBSD 5.6.  In fact, I often do this for visualization:
> > I've written a Tk/Perl program 'slider' which provides a GUI to walk
> > through a data set, and outputs gnuplot commands for visualization;
> > I use it via shell scripts like this one:
> > 
> > #!/bin/sh
> > slider --min   401.022164175591         \
> >        --delta   1.00255541043898       \
> >        --max   501.277705219488         \
> >        --continuous                     \
> >        --command-file ../Phi.rl1-4.3D-slider-gnuplot-template \
> >   | gnuplot
> > 
> > For a standalone test:
> > 
> > % uname -a
> > OpenBSD copper.astro.indiana.edu 5.6 GENERIC.MP#0 amd64
> > % echo 'show version long' | gnuplot
> > 
> >         G N U P L O T
> >         Version 5.0 patchlevel 0    last modified 2015-01-01 
> > 
> >         Copyright (C) 1986-1993, 1998, 2004, 2007-2015
> >         Thomas Williams, Colin Kelley and many others
> > 
> >         gnuplot home:     http://www.gnuplot.info
> >         faq, bugs, etc:   type "help FAQ"
> >         immediate help:   type "help"  (plot window: hit 'h')
> > Compile options:
> > -READLINE  +LIBREADLINE  -HISTORY  
> > -BACKWARDS_COMPATIBILITY  +BINARY_DATA  
> > +GD_PNG  +GD_JPEG  +GD_TTF  +GD_GIF  +ANIMATION  
> > -USE_CWDRC  +X11  +X11_POLYGON  +MULTIBYTE  +X11_EXTERNAL +USE_MOUSE
> > +HIDDEN3D_QUADTREE +DATASTRINGS  +HISTOGRAMS  +OBJECTS  +STRINGVARS
> > +MACROS  +THIN_SPLINES  +IMAGE  +USER_LINETYPES +STATS
> > +EXTERNAL_FUNCTIONS 
> > 
> > GNUPLOT_DRIVER_DIR = "/usr/local/libexec/gnuplot/5.0"
> > GNUPLOT_PS_DIR     = "/usr/local/share/gnuplot/5.0/PostScript"
> > HELPFILE           = "/usr/local/share/gnuplot/5.0/gnuplot.gih"
> > 
> > % echo 'set term x11 persist; plot sin(x)' | gnuplot
> > % 
> > 
> > That last command produced an X window with the plot.
> > 
> > 
> > What gnuplot version are you using, and on what system?

Re: Does gnuplot still read commands from stdin?

[Philipp K. J. <ja...@ie...>]

No, it doesn't work for me.

Here is the contents of my test script:

set t pngcairo
plot sin(x)

I invoke it like this:

cat script.gp | gnuplot > graph.png

When I use gnuplot 4.6 patchlevel 3 (which comes
with my distro), all is well. But when I use version
5, nothing happens - I simply get dropped into an
interactive session.

Mind you, batch processing works with version 5:

gnuplot5 script.gp > graph.png

is fine.


Here are the specifics:

Linux puget 3.11.0-12-generic #19-Ubuntu SMP Wed Oct 9 16:20:46 UTC
2013 x86_64 x86_64 x86_64 GNU/Linux


        G N U P L O T
        Version 5.0 patchlevel 0    last modified 2015-01-01 

        Copyright (C) 1986-1993, 1998, 2004, 2007-2015
        Thomas Williams, Colin Kelley and many others

        gnuplot home:     http://www.gnuplot.info
        faq, bugs, etc:   type "help FAQ"
        immediate help:   type "help"  (plot window: hit 'h')


On Mon, 9 Feb 2015 00:26:20 -0500
Jonathan Thornburg <jt...@as...> wrote:

> Hi,
> 
> On Sun, Feb 08, 2015 at 07:37:15PM -0800, Philipp K. Janert wrote:
> > It used to be possible to pipe commands to gnuplot:
> > 
> > 	cat script.gp | gnuplot
> > 
> > When I try this with gp5, gnuplot seems to ignore 
> > the input. 
> > 
> > I did not see any comment on this in the documentation
> > either way. What behavior should I expect?
> 
> Piping commands to gnuplot works fine for me with gnuplot 5.0.0
> running on OpenBSD 5.6.  In fact, I often do this for visualization:
> I've written a Tk/Perl program 'slider' which provides a GUI to walk
> through a data set, and outputs gnuplot commands for visualization;
> I use it via shell scripts like this one:
> 
> #!/bin/sh
> slider --min   401.022164175591         \
>        --delta   1.00255541043898       \
>        --max   501.277705219488         \
>        --continuous                     \
>        --command-file ../Phi.rl1-4.3D-slider-gnuplot-template \
>   | gnuplot
> 
> For a standalone test:
> 
> % uname -a
> OpenBSD copper.astro.indiana.edu 5.6 GENERIC.MP#0 amd64
> % echo 'show version long' | gnuplot
> 
>         G N U P L O T
>         Version 5.0 patchlevel 0    last modified 2015-01-01 
> 
>         Copyright (C) 1986-1993, 1998, 2004, 2007-2015
>         Thomas Williams, Colin Kelley and many others
> 
>         gnuplot home:     http://www.gnuplot.info
>         faq, bugs, etc:   type "help FAQ"
>         immediate help:   type "help"  (plot window: hit 'h')
> Compile options:
> -READLINE  +LIBREADLINE  -HISTORY  
> -BACKWARDS_COMPATIBILITY  +BINARY_DATA  
> +GD_PNG  +GD_JPEG  +GD_TTF  +GD_GIF  +ANIMATION  
> -USE_CWDRC  +X11  +X11_POLYGON  +MULTIBYTE  +X11_EXTERNAL +USE_MOUSE
> +HIDDEN3D_QUADTREE +DATASTRINGS  +HISTOGRAMS  +OBJECTS  +STRINGVARS
> +MACROS  +THIN_SPLINES  +IMAGE  +USER_LINETYPES +STATS
> +EXTERNAL_FUNCTIONS 
> 
> GNUPLOT_DRIVER_DIR = "/usr/local/libexec/gnuplot/5.0"
> GNUPLOT_PS_DIR     = "/usr/local/share/gnuplot/5.0/PostScript"
> HELPFILE           = "/usr/local/share/gnuplot/5.0/gnuplot.gih"
> 
> % echo 'set term x11 persist; plot sin(x)' | gnuplot
> % 
> 
> That last command produced an X window with the plot.
> 
> 
> What gnuplot version are you using, and on what system?
> 
> ciao,
> 

Re: Does gnuplot still read commands from stdin?

[Jonathan T. <jt...@as...>]

Hi,

On Sun, Feb 08, 2015 at 07:37:15PM -0800, Philipp K. Janert wrote:
> It used to be possible to pipe commands to gnuplot:
> 
> 	cat script.gp | gnuplot
> 
> When I try this with gp5, gnuplot seems to ignore 
> the input. 
> 
> I did not see any comment on this in the documentation
> either way. What behavior should I expect?

Piping commands to gnuplot works fine for me with gnuplot 5.0.0
running on OpenBSD 5.6.  In fact, I often do this for visualization:
I've written a Tk/Perl program 'slider' which provides a GUI to walk
through a data set, and outputs gnuplot commands for visualization;
I use it via shell scripts like this one:

#!/bin/sh
slider --min   401.022164175591         \
       --delta   1.00255541043898       \
       --max   501.277705219488         \
       --continuous                     \
       --command-file ../Phi.rl1-4.3D-slider-gnuplot-template \
  | gnuplot

For a standalone test:

% uname -a
OpenBSD copper.astro.indiana.edu 5.6 GENERIC.MP#0 amd64
% echo 'show version long' | gnuplot

        G N U P L O T
        Version 5.0 patchlevel 0    last modified 2015-01-01 

        Copyright (C) 1986-1993, 1998, 2004, 2007-2015
        Thomas Williams, Colin Kelley and many others

        gnuplot home:     http://www.gnuplot.info
        faq, bugs, etc:   type "help FAQ"
        immediate help:   type "help"  (plot window: hit 'h')
Compile options:
-READLINE  +LIBREADLINE  -HISTORY  
-BACKWARDS_COMPATIBILITY  +BINARY_DATA  
+GD_PNG  +GD_JPEG  +GD_TTF  +GD_GIF  +ANIMATION  
-USE_CWDRC  +X11  +X11_POLYGON  +MULTIBYTE  +X11_EXTERNAL +USE_MOUSE  +HIDDEN3D_QUADTREE  
+DATASTRINGS  +HISTOGRAMS  +OBJECTS  +STRINGVARS  +MACROS  +THIN_SPLINES  +IMAGE  +USER_LINETYPES +STATS +EXTERNAL_FUNCTIONS 

GNUPLOT_DRIVER_DIR = "/usr/local/libexec/gnuplot/5.0"
GNUPLOT_PS_DIR     = "/usr/local/share/gnuplot/5.0/PostScript"
HELPFILE           = "/usr/local/share/gnuplot/5.0/gnuplot.gih"

% echo 'set term x11 persist; plot sin(x)' | gnuplot
% 

That last command produced an X window with the plot.


What gnuplot version are you using, and on what system?

ciao,

-- 
-- "Jonathan Thornburg [remove -animal to reply]" <jt...@as...>
   Dept of Astronomy & IUCSS, Indiana University, Bloomington, Indiana, USA
   "There was of course no way of knowing whether you were being watched
    at any given moment.  How often, or on what system, the Thought Police
    plugged in on any individual wire was guesswork.  It was even conceivable
    that they watched everybody all the time."  -- George Orwell, "1984"

Does gnuplot still read commands from stdin?

[Philipp K. J. <ja...@ie...>]

It used to be possible to pipe commands to gnuplot:

	cat script.gp | gnuplot

When I try this with gp5, gnuplot seems to ignore 
the input. 

I did not see any comment on this in the documentation
either way. What behavior should I expect?

Best,

		Ph.

Re: Online demos contain typos

[sfeam <sf...@us...>]

On Monday, 02 February 2015 01:38:04 PM Christoph Bersch wrote:
> Hi,
> 
> the online demos contain typos, e.g. in  
> http://www.gnuplot.info/demo/contours.1.gnu are some lines with a  
> duplicate `lt -1`:
> 
> set xlabel  font "" textcolor lt -1 lt -1 norotate


Heh.  That duplicated "lt -1" was a bug in the cvs present for
only a few days.  I guess the demo set must have been regenerated
during that window.

	Ethan

Online demos contain typos

[Christoph B. <us...@be...>]

Hi,

the online demos contain typos, e.g. in  
http://www.gnuplot.info/demo/contours.1.gnu are some lines with a  
duplicate `lt -1`:

set xlabel  font "" textcolor lt -1 lt -1 norotate


Christoph

Re: limitations of fit?

[Hans-Bernhard B. <HBB...@t-...>]

Am 31.01.2015 um 20:47 schrieb pl...@pi...:

> I have about 2300 data points that I need to fit a simple cosine to.
> However, fit says it is converging at the first iteration and
> effectively does nothing.
>
> The data has a good signal to noise and I have primed the parameters
> with values which are pretty close. It just needs to shift the constant
> term closer to zero.

The RMS you got appears to disagree with that assessment.

 > final sum of squares of residuals : 3036.32

For 2300 points, and a function that only varies between 0 and 2 with 
the given starting parameters, you're getting an average deviation 
between function and data of more than 1.0 per data point.  That's quite 
a bit removed from being "pretty close".

> I had this working fine with less data points (about 200)  on
> essentially the same dataset.

200 data points cannot ever be "essentially the same dataset" as 2300.

> Is the large number of points causing fit to fail to converge properly?

Almost certainly not.

For a more meaningful answer you'll have to divulge the dataset in question.

limitations of fit?

[<pl...@pi...>]

Hi,

I have about 2300 data points that I need to fit a simple cosine to. 
However, fit says it is converging at the first iteration and 
effectively does nothing.

The data has a good signal to noise and I have primed the parameters 
with values which are pretty close. It just needs to shift the constant 
term closer to zero.

I had this working fine with less data points (about 200)  on 
essentially the same dataset.

Is the large number of points causing fit to fail to converge properly?

TIA, Peter.



  fcos1(x)= a1*cos(2*pi*(x-yz1)/p1)+c1
a1=c1=1; yz1=1990; p1=4.5
  fit [:1991.5] fcos1(x) datafile1  u 1:2 via  a1,c1,p1,yz1

After 1 iterations the fit converged.
final sum of squares of residuals : 3036.32
rel. change during last iteration : 0

Re: dynamic axex [was Re: with parallelaxes dumps core]

[sfeam <sf...@us...>]

On Wednesday, 28 January 2015 10:55:40 PM Hans-Bernhard Bröker wrote:
> Am 27.01.2015 um 18:46 schrieb Ethan A Merritt:
> 
> > However, none of these are the reason for a cap on the number
> > of parallel axes. That comes instead from a poor design
> > decision now lost in the mists of program history.
> 
> I disagree about that decision having been a poor one. It was correct at 
> the time it was originally made, because it matched the capabilities and 
> of the program at the time.  There was really no way anyone could have 
> anticipated the amount of stuff that was later grafted onto the original 
> design.  A truly bad design would never have withstood 20+ years of add-ons.

Closer to 30 years now :-)

> > This is bad, because you can't just allocate a new
> > axis structure and pass it to any of the existing
> > subroutines or macros.
> 
> That wouldn't work anyway, and for rather more important reasons than 
> the implementation detail of whether axis methods' primary argument is 
> an index or a pointer.
> 
> The axes have to be in an array because the indices into that array have 
> more meaning than just as the indicator of one array entry to work with. 
>   The sequence of AXIS_INDEX enumeration values has been the same since 
> just about forever, and it has extra properties.  The entire first vs. 
> second axes mechanism is built on these properties.
> 
> IOW: as long as there remains
> 
> 	* any use of the macros FIRST_AXES and SECOND_AXES
> 	* any loop over a variable of type AXIS_INDEX
> 	* any inequality comparison among AXIS_INDEX values
> 
> you won't get rid of axis_array[].

I take your point, but that by itself isn't an argument against 
designing the various subroutines to accept pointers rather than
indices.  It is no harder to call sub(&array_axis[INDEX]) than
it is to call sub(INDEX).  All the FIRST and SECOND axes could
continue to live in an array just as they do now.  But unlike now
it would also be possible to dynamically allocate a temporary axis
structure, or a contiguous array of them if that makes sense.

As to manipulations using FIRST_AXES and SECOND_AXES,
there are not very many of these.  I suspect it would suffice to 
add a field or flag to the axis structure.

Instead of having code like axis.c:1381
    TBOOLEAN axis_is_second = ((axis / SECOND_AXES) == 1);
you would have
    TBOOLEAN axis_is_second = axis->is_second_axis;

> The best one could do before that would be to make axis_array[] itself 
> dynamically sized.  That, however, would mean that _all_ uses of 
> pointer-to-AXIS would have to be forbidden, because the array itself 
> could move when reallocated.  I.e. it would push things into the 
> opposite direction of your intention.

I agree that option is not very workable.

	Ethan

Re: dynamic axex [was Re: with parallelaxes dumps core]

[Hans-Bernhard B. <HBB...@t-...>]

Am 27.01.2015 um 18:46 schrieb Ethan A Merritt:

> However, none of these are the reason for a cap on the number
> of parallel axes. That comes instead from a poor design
> decision now lost in the mists of program history.

I disagree about that decision having been a poor one. It was correct at 
the time it was originally made, because it matched the capabilities and 
of the program at the time.  There was really no way anyone could have 
anticipated the amount of stuff that was later grafted onto the original 
design.  A truly bad design would never have withstood 20+ years of add-ons.

> This is bad, because you can't just allocate a new
> axis structure and pass it to any of the existing
> subroutines or macros.

That wouldn't work anyway, and for rather more important reasons than 
the implementation detail of whether axis methods' primary argument is 
an index or a pointer.

The axes have to be in an array because the indices into that array have 
more meaning than just as the indicator of one array entry to work with. 
  The sequence of AXIS_INDEX enumeration values has been the same since 
just about forever, and it has extra properties.  The entire first vs. 
second axes mechanism is built on these properties.

IOW: as long as there remains

	* any use of the macros FIRST_AXES and SECOND_AXES
	* any loop over a variable of type AXIS_INDEX
	* any inequality comparison among AXIS_INDEX values

you won't get rid of axis_array[].

The best one could do before that would be to make axis_array[] itself 
dynamically sized.  That, however, would mean that _all_ uses of 
pointer-to-AXIS would have to be forbidden, because the array itself 
could move when reallocated.  I.e. it would push things into the 
opposite direction of your intention.

Re: Weirdness with boxplot

[Ethan A M. <sf...@us...>]

On Wednesday, 28 January, 2015 10:32:49 Ethan A Merritt wrote:
> On Wednesday, 28 January, 2015 09:48:07 Philipp K. Janert wrote:
> > 
> > The "level" of the FIRST record has been changed.
> > Now there are three levels, but I get the same 
> > plot as for File1, except that the name of the
> > first level is now 10.
> 
> I do not know exactly why that happens in gnuplot 5.0.0
> but in any case it is no longer happening since the 
> boxplot "layer" code was reworked as suggested by Achim Gratz.
> See discussion attached to Bug #1532.

Sorry, I misread the ChangeLog file.
The revised boxplot algorithm came from Jouke Witteveen.

> Therefore this issue is no longer present in the CVS version
> for either 5.0 or 5.1.   It is unfortunate that it wasn't
> caught earlier, but apparently 2 weeks of post-release testing
> brings in more testers and more reports of problems than
> 6 months of pre-release testing.
>
>  Ethan

Re: Weirdness with boxplot

[Philipp K. J. <ja...@ie...>]

[snip]

> 
> I do not know exactly why that happens in gnuplot 5.0.0
> but in any case it is no longer happening since the 
> boxplot "layer" code was reworked as suggested by Achim Gratz.
> See discussion attached to Bug #1532.
> 
> Therefore this issue is no longer present in the CVS version
> for either 5.0 or 5.1.   It is unfortunate that it wasn't
> caught earlier, but apparently 2 weeks of post-release testing
> brings in more testers and more reports of problems than
> 6 months of pre-release testing.

Good with me. Apparently I need to upgrade. ;-)

Re: Weirdness with boxplot

[Ethan A M. <merritt@u.washington.edu>]

On Wednesday, 28 January, 2015 09:48:07 Philipp K. Janert wrote:
> 
> Consider the following data file:
> 
> # File1
> 1	1
> 2	1
> 2	1
> 3	1
> 3	2
> 4	2
> 4	2
> 5	2
> 
> Now the command:
> 	plot "d" u (1):1:(0.3):2 w boxplot
> gives me two nice box plots, at levels "1"
> and "2", side by side.
> 
> Now consider the following file:
> 
> # File2
> 1	10
> 2	1
> 2	1
> 3	1
> 3	2
> 4	2
> 4	2
> 5	2
> 
> The "level" of the FIRST record has been changed.
> Now there are three levels, but I get the same 
> plot as for File1, except that the name of the
> first level is now 10.

I do not know exactly why that happens in gnuplot 5.0.0
but in any case it is no longer happening since the 
boxplot "layer" code was reworked as suggested by Achim Gratz.
See discussion attached to Bug #1532.

Therefore this issue is no longer present in the CVS version
for either 5.0 or 5.1.   It is unfortunate that it wasn't
caught earlier, but apparently 2 weeks of post-release testing
brings in more testers and more reports of problems than
6 months of pre-release testing.

	Ethan

> 
> Now consider this file:
> 
> # File3
> 1	1
> 2	10
> 2	1
> 3	1
> 3	2
> 4	2
> 4	2
> 5	2
> 
> Here, the level of some other (not the first)
> record has been changed. Now I do get the plot
> that I'd expect, showing three levels (one only
> having a single point, of course).
> 
> Doing this, by the way, has no effeect:
> 	plot "d" u (1):1:(0.3):(stringcolumn(2)) w boxplot
> 
> Strange, isn't it?
> 
> Best,
> 
> 		Ph.
> 
> ------------------------------------------------------------------------------
> Dive into the World of Parallel Programming. The Go Parallel Website,
> sponsored by Intel and developed in partnership with Slashdot Media, is your
> hub for all things parallel software development, from weekly thought
> leadership blogs to news, videos, case studies, tutorials and more. Take a
> look and join the conversation now. http://goparallel.sourceforge.net/
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> Membership management via: https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
-- 
Ethan A Merritt
Biomolecular Structure Center,  K-428 Health Sciences Bldg
MS 357742,   University of Washington, Seattle 98195-7742

Weirdness with boxplot

[Philipp K. J. <ja...@ie...>]

Consider the following data file:

# File1
1	1
2	1
2	1
3	1
3	2
4	2
4	2
5	2

Now the command:
	plot "d" u (1):1:(0.3):2 w boxplot
gives me two nice box plots, at levels "1"
and "2", side by side.

Now consider the following file:

# File2
1	10
2	1
2	1
3	1
3	2
4	2
4	2
5	2

The "level" of the FIRST record has been changed.
Now there are three levels, but I get the same 
plot as for File1, except that the name of the
first level is now 10.

Now consider this file:

# File3
1	1
2	10
2	1
3	1
3	2
4	2
4	2
5	2

Here, the level of some other (not the first)
record has been changed. Now I do get the plot
that I'd expect, showing three levels (one only
having a single point, of course).

Doing this, by the way, has no effeect:
	plot "d" u (1):1:(0.3):(stringcolumn(2)) w boxplot

Strange, isn't it?

Best,

		Ph.

Re: Make Gnuplot using the mathematical minus sign

[Allin C. <cot...@wf...>]

On Tue, 27 Jan 2015, Ethan A Merritt wrote:

> On Tuesday, 27 January, 2015 15:33:15 Philipp K. Janert wrote:
>>
>> [snip]
>>
>> In that spirit (and sorry for hijacking your
>> posting): I noticed that the %h and %H conversion
>> specifiers use an 'x' (letter x) and a '*' (asterisk)
>> to form numbers like 3.1 x 10^4.
>>
>> It would be lovely if they used the "multiplication
>> sign" (U+00d7) and the dot operator (U+22c5 - or
>> alternatively U+00b7) instead.
>
> gnuplot does in fact use a multiplication sign (U+00d7)
> if the encoding permits.  That covers almost all linux
> systems since the default encoding is UTF-8.  MSWin encoding
> CP1252 uses the symbol 0xd7, which I think is the same?
> I'm not sure what the default encoding is on OSX.

OS X uses UTF-8. These days only Windows is the odd man out.

--
Allin Cottrell
Department of Economics
Wake Forest University

Re: Make Gnuplot using the mathematical minus sign

[Philipp K. J. <ja...@ie...>]

On Tue, 27 Jan 2015 16:54:01 -0800
Ethan A Merritt <sf...@us...> wrote:

I see - this is very interesting:

Upon gnuplot startup:

	show encoding
        	nominal character encoding is default
	        however LC_CTYPE in current locale is en_US.UTF-8

and tic labels use 'x' chars.

When I explicitly do:

	set encoding utf8

then (as you say) the tic labels use the mult sign.

At the same time, I can use Unicode characters
(beyond ASCII) in strings - which led me to believe
that UTF8 encoding was already active.

I am confused, but will put "set encoding utf8" 
in my .gnuplot file.

Best,

		Ph.



> On Tuesday, 27 January, 2015 16:35:02 Philipp K. Janert wrote:
> > On Tue, 27 Jan 2015 15:53:13 -0800
> > Ethan A Merritt <sf...@us...> wrote:
> > 
> > > On Tuesday, 27 January, 2015 15:33:15 Philipp K. Janert wrote:
> > > > 
> > > > [snip]
> > > > 
> > > > In that spirit (and sorry for hijacking your
> > > > posting): I noticed that the %h and %H conversion
> > > > specifiers use an 'x' (letter x) and a '*' (asterisk)
> > > > to form numbers like 3.1 x 10^4.
> > > > 
> > > > It would be lovely if they used the "multiplication
> > > > sign" (U+00d7) and the dot operator (U+22c5 - or
> > > > alternatively U+00b7) instead.
> > > 
> > > gnuplot does in fact use a multiplication sign (U+00d7)
> > > if the encoding permits.  That covers almost all linux
> > 
> > Well, if I do:
> > 	set t wxt font "Times"
> > 	plot [:20] exp(x)
> > then the ytic labels look very much like an 'x', 
> > not like the multiplication sign.
> 
> I cannot say what your fonts look like.
> I suspect if you look closely you will see a difference
> after:
> 
>    set encoding utf8; replot
>    set encoding iso_8859_1; replot
> 
> The relevant source code is in file util.c starting at line 644.
> 
> In looking at it now, I see that it would be possible to
> pick up several other ISO_8859 encodings as well as UTF8.
> I wonder how many systems still default to ISO_8859-{1|2|15}
> rather than UTF8.
> 
> 	Ethan
> 
> > Is this a font problem (substituting 'x' if
> > no glyph for U+00d7 is available)? But I 
> > thought that fontconfig will supply another
> > FONT if necessary, but not substitute a
> > different CHARACTER.
> >
> > > systems since the default encoding is UTF-8.  MSWin encoding
> > > CP1252 uses the symbol 0xd7, which I think is the same?
> > > I'm not sure what the default encoding is on OSX.
> > > The LaTeX terminals use \\times or \\cdot.
> > > 
> > > 	Ethan
> > > 

Re: Make Gnuplot using the mathematical minus sign

[Mojca M. <moj...@gm...>]

On Tue, Jan 27, 2015 at 10:45 AM, Maurizio Tomasi wrote:
> Hi to everybody,
>
>   Yesterday I posted a question on StackOverflow about the possibility to
> use the mathematical minus sign for negative numbers for tick labels in
> Gnuplot instead of the hyphen. (This is a request I got from the referee of
> a paper I've just submitted.)
>
> Although I have never hacked Gnuplot, I am fluent with C/C++ and would like
> to try to write a patch that implements this feature. I would like to ask
> you which would be the best way to do this:
>
> 1. Implement a pair of commands ("set hyphenminus" / "unset hyphenminus")
> which change this setting globally, i.e., on the X/Y/X2/Y2 axes.
>
> 2. Implement a new formatting sequence, like "%h", which takes care of using
> the correct character.
>
> My preference goes to the first option (if one cares for typographical
> correctness, chances are that it wants it on every axis.). Moreover, I would
> like to make the mathematical minus the default, and leave the possibility
> to use the hyphen only as a way to retain backwards compatibility (this is
> what Matplotlib does).
>
> What do you think? Do you have suggestions about how to properly code this?

Quick solution:
If you are using some TeX-based terminal, you could easily use something like
    set format x "$%g$"
(or whatever format you require). Then TeX will automatically convert
the hyphen into mathematical minus.


Matplotlib has full control of its output, but gnuplot is more
heterogeneous, so the problem is slightly more difficult.


In my opinion changing to the mathematical minus *by default* might
cause some problems.

Mathematical minus wouldn't work with terminals or fonts that don't
support that character/glyph. In particular, no encoding from the
ISO-8859 standard contains mathematical minus (I didn't check all, so
please excuse me if I'm wrong). I'm not saying that it's completely
impossible to implement this, but one would need to adapt almost every
terminal.


If you invent a new formatting sequence just for the sake of this one
character, we'll end up in an exponential combinatorics problem.

We could have a single highly configurable formatting sequence with
lots of configuration options (whether to use dot or comma for the
decimal separator; whether or not to use the thousands separator and
if so, which one; what to use for multiplication sign; what to use for
minus sign; whether to make sure that all numbers end up with the same
number of decimal places [something that annoys me a lot; usually one
gets 0, 0.5, 1, 1.5, ... instead of 0.0, 0.5, 1.0, 1.5, ...], how to
format the exponent, ...). But inventing a new formatting for every
single option would quickly spoil the game.


Something like "set minussign ..." sounds like the most reasonable
option to me, but please note that I'm not a gnuplot developer, so
this is just my personal opinion.

Mojca

Re: Make Gnuplot using the mathematical minus sign

[Ethan A M. <sf...@us...>]

On Tuesday, 27 January, 2015 16:35:02 Philipp K. Janert wrote:
> On Tue, 27 Jan 2015 15:53:13 -0800
> Ethan A Merritt <sf...@us...> wrote:
> 
> > On Tuesday, 27 January, 2015 15:33:15 Philipp K. Janert wrote:
> > > 
> > > [snip]
> > > 
> > > In that spirit (and sorry for hijacking your
> > > posting): I noticed that the %h and %H conversion
> > > specifiers use an 'x' (letter x) and a '*' (asterisk)
> > > to form numbers like 3.1 x 10^4.
> > > 
> > > It would be lovely if they used the "multiplication
> > > sign" (U+00d7) and the dot operator (U+22c5 - or
> > > alternatively U+00b7) instead.
> > 
> > gnuplot does in fact use a multiplication sign (U+00d7)
> > if the encoding permits.  That covers almost all linux
> 
> Well, if I do:
> 	set t wxt font "Times"
> 	plot [:20] exp(x)
> then the ytic labels look very much like an 'x', 
> not like the multiplication sign.

I cannot say what your fonts look like.
I suspect if you look closely you will see a difference
after:

   set encoding utf8; replot
   set encoding iso_8859_1; replot

The relevant source code is in file util.c starting at line 644.

In looking at it now, I see that it would be possible to
pick up several other ISO_8859 encodings as well as UTF8.
I wonder how many systems still default to ISO_8859-{1|2|15}
rather than UTF8.

	Ethan

> Is this a font problem (substituting 'x' if
> no glyph for U+00d7 is available)? But I 
> thought that fontconfig will supply another
> FONT if necessary, but not substitute a
> different CHARACTER.
>
> > systems since the default encoding is UTF-8.  MSWin encoding
> > CP1252 uses the symbol 0xd7, which I think is the same?
> > I'm not sure what the default encoding is on OSX.
> > The LaTeX terminals use \\times or \\cdot.
> > 
> > 	Ethan
> > 

Re: Make Gnuplot using the mathematical minus sign

[Philipp K. J. <ja...@ie...>]

On Tue, 27 Jan 2015 15:53:13 -0800
Ethan A Merritt <sf...@us...> wrote:

> On Tuesday, 27 January, 2015 15:33:15 Philipp K. Janert wrote:
> > 
> > [snip]
> > 
> > In that spirit (and sorry for hijacking your
> > posting): I noticed that the %h and %H conversion
> > specifiers use an 'x' (letter x) and a '*' (asterisk)
> > to form numbers like 3.1 x 10^4.
> > 
> > It would be lovely if they used the "multiplication
> > sign" (U+00d7) and the dot operator (U+22c5 - or
> > alternatively U+00b7) instead.
> 
> gnuplot does in fact use a multiplication sign (U+00d7)
> if the encoding permits.  That covers almost all linux

Well, if I do:
	set t wxt font "Times"
	plot [:20] exp(x)
then the ytic labels look very much like an 'x', 
not like the multiplication sign.

Is this a font problem (substituting 'x' if
no glyph for U+00d7 is available)? But I 
thought that fontconfig will supply another
FONT if necessary, but not substitute a
different CHARACTER.

> systems since the default encoding is UTF-8.  MSWin encoding
> CP1252 uses the symbol 0xd7, which I think is the same?
> I'm not sure what the default encoding is on OSX.
> The LaTeX terminals use \\times or \\cdot.
> 
> 	Ethan
> 

Re: Make Gnuplot using the mathematical minus sign

[Ethan A M. <sf...@us...>]

On Tuesday, 27 January, 2015 15:33:15 Philipp K. Janert wrote:
> 
> [snip]
> 
> In that spirit (and sorry for hijacking your
> posting): I noticed that the %h and %H conversion
> specifiers use an 'x' (letter x) and a '*' (asterisk)
> to form numbers like 3.1 x 10^4.
> 
> It would be lovely if they used the "multiplication
> sign" (U+00d7) and the dot operator (U+22c5 - or
> alternatively U+00b7) instead.

gnuplot does in fact use a multiplication sign (U+00d7)
if the encoding permits.  That covers almost all linux
systems since the default encoding is UTF-8.  MSWin encoding
CP1252 uses the symbol 0xd7, which I think is the same?
I'm not sure what the default encoding is on OSX.
The LaTeX terminals use \\times or \\cdot.

	Ethan