You can subscribe to this list here.
2001 
_{Jan}

_{Feb}
(1) 
_{Mar}

_{Apr}

_{May}

_{Jun}

_{Jul}
(1) 
_{Aug}

_{Sep}

_{Oct}

_{Nov}

_{Dec}


2002 
_{Jan}
(1) 
_{Feb}

_{Mar}

_{Apr}

_{May}

_{Jun}

_{Jul}
(1) 
_{Aug}
(1) 
_{Sep}

_{Oct}

_{Nov}
(1) 
_{Dec}

2003 
_{Jan}

_{Feb}

_{Mar}

_{Apr}

_{May}

_{Jun}

_{Jul}
(1) 
_{Aug}
(1) 
_{Sep}

_{Oct}
(83) 
_{Nov}
(57) 
_{Dec}
(111) 
2004 
_{Jan}
(38) 
_{Feb}
(121) 
_{Mar}
(107) 
_{Apr}
(241) 
_{May}
(102) 
_{Jun}
(190) 
_{Jul}
(239) 
_{Aug}
(158) 
_{Sep}
(184) 
_{Oct}
(193) 
_{Nov}
(47) 
_{Dec}
(68) 
2005 
_{Jan}
(190) 
_{Feb}
(105) 
_{Mar}
(99) 
_{Apr}
(65) 
_{May}
(92) 
_{Jun}
(250) 
_{Jul}
(197) 
_{Aug}
(128) 
_{Sep}
(101) 
_{Oct}
(183) 
_{Nov}
(186) 
_{Dec}
(42) 
2006 
_{Jan}
(102) 
_{Feb}
(122) 
_{Mar}
(154) 
_{Apr}
(196) 
_{May}
(181) 
_{Jun}
(281) 
_{Jul}
(310) 
_{Aug}
(198) 
_{Sep}
(145) 
_{Oct}
(188) 
_{Nov}
(134) 
_{Dec}
(90) 
2007 
_{Jan}
(134) 
_{Feb}
(181) 
_{Mar}
(157) 
_{Apr}
(57) 
_{May}
(81) 
_{Jun}
(204) 
_{Jul}
(60) 
_{Aug}
(37) 
_{Sep}
(17) 
_{Oct}
(90) 
_{Nov}
(122) 
_{Dec}
(72) 
2008 
_{Jan}
(130) 
_{Feb}
(108) 
_{Mar}
(160) 
_{Apr}
(38) 
_{May}
(83) 
_{Jun}
(42) 
_{Jul}
(75) 
_{Aug}
(16) 
_{Sep}
(71) 
_{Oct}
(57) 
_{Nov}
(59) 
_{Dec}
(152) 
2009 
_{Jan}
(73) 
_{Feb}
(213) 
_{Mar}
(67) 
_{Apr}
(40) 
_{May}
(46) 
_{Jun}
(82) 
_{Jul}
(73) 
_{Aug}
(57) 
_{Sep}
(108) 
_{Oct}
(36) 
_{Nov}
(153) 
_{Dec}
(77) 
2010 
_{Jan}
(42) 
_{Feb}
(171) 
_{Mar}
(150) 
_{Apr}
(6) 
_{May}
(22) 
_{Jun}
(34) 
_{Jul}
(31) 
_{Aug}
(38) 
_{Sep}
(32) 
_{Oct}
(59) 
_{Nov}
(13) 
_{Dec}
(62) 
2011 
_{Jan}
(114) 
_{Feb}
(139) 
_{Mar}
(126) 
_{Apr}
(51) 
_{May}
(53) 
_{Jun}
(29) 
_{Jul}
(41) 
_{Aug}
(29) 
_{Sep}
(35) 
_{Oct}
(87) 
_{Nov}
(42) 
_{Dec}
(20) 
2012 
_{Jan}
(111) 
_{Feb}
(66) 
_{Mar}
(35) 
_{Apr}
(59) 
_{May}
(71) 
_{Jun}
(32) 
_{Jul}
(11) 
_{Aug}
(48) 
_{Sep}
(60) 
_{Oct}
(87) 
_{Nov}
(16) 
_{Dec}
(38) 
2013 
_{Jan}
(5) 
_{Feb}
(19) 
_{Mar}
(41) 
_{Apr}
(47) 
_{May}
(14) 
_{Jun}
(32) 
_{Jul}
(18) 
_{Aug}
(68) 
_{Sep}
(9) 
_{Oct}
(42) 
_{Nov}
(12) 
_{Dec}
(10) 
2014 
_{Jan}
(14) 
_{Feb}
(139) 
_{Mar}
(137) 
_{Apr}
(66) 
_{May}
(72) 
_{Jun}
(142) 
_{Jul}
(70) 
_{Aug}
(31) 
_{Sep}
(39) 
_{Oct}
(98) 
_{Nov}
(133) 
_{Dec}
(44) 
2015 
_{Jan}
(70) 
_{Feb}
(27) 
_{Mar}
(36) 
_{Apr}
(11) 
_{May}
(15) 
_{Jun}
(70) 
_{Jul}
(30) 
_{Aug}
(63) 
_{Sep}
(18) 
_{Oct}
(15) 
_{Nov}
(42) 
_{Dec}
(29) 
2016 
_{Jan}
(37) 
_{Feb}
(48) 
_{Mar}
(59) 
_{Apr}
(28) 
_{May}
(30) 
_{Jun}
(43) 
_{Jul}
(47) 
_{Aug}
(14) 
_{Sep}

_{Oct}

_{Nov}

_{Dec}

S  M  T  W  T  F  S 

1
(8) 
2
(6) 
3

4

5

6

7
(1) 
8

9
(1) 
10

11
(1) 
12
(4) 
13
(3) 
14
(6) 
15

16
(6) 
17
(2) 
18
(2) 
19
(2) 
20
(2) 
21

22
(1) 
23
(3) 
24
(5) 
25

26

27
(3) 
28

29

30
(1) 
31
(3) 




From: David Ko <dko@uc...>  20070731 21:59:04

Hello all, I've recently been trying to compile Gnuplot in MinGW, and I've gotten everything working except that it crashes when I try to write a png file. The Windows binary I downloaded from gnuplot.info works fine, and I have a couple questions for the Win32 binary maintainer: What build environment was used to create the Win32 binaries? I've tried MinGW and Visual Studio .NET thus far, and everything dies when trying to write a png file. (i.e. 'set terminal png; set output "test.png"; plot x' < dies here) My latest attempt was with the 'config/makefile.mgw' provided makefile in MinGW. What version of libgd was used? I assume that the latest version (2.0.35) was used, but the makefile.mgw that came w/ gnuplot referred to v.1.8 as "new". I've tried using the libgd library built from scratch and the provided prebuilt libraries. I've also tried the v1.8 library. Gnuplot behaves identically for all of them (crash on png write). Any other tips/ideas for me? I'm not really a windows person by any means. Thanks for your time!  David Ko 
From: Paul <psa22@dr...>  20070731 21:35:14

> This will almost certainly need to be done outside gnuplot by > preprocessing the data. CatmullRomm spline would probably be a good > choice to interpolate your example contour at 175mm Hello, Do you know of a good software application in linux which will do this preprocessing? 
From: Ethan Merritt <merritt@u.washington.edu>  20070731 18:30:44

I'd like to collect comments and suggestions on any rough edges marring the new cairopdf terminal driver. I know of 3 problems, 2 of which are illustrated by fillbetween.dem 1) The pattern fill scales as a bitmap rather than as a vector pattern. This is ugly at high resolution. If we can't make the vector pattern scale correctly, then in monochrome mode we should probably replace the pattern fill with incremental solid shading. pattern 1 = no fill pattern 2 = black pattern 3 = 50% grey etc 2) The fill area is not clipped to the plot boundaries. This puzzles me, because I thought that the clipping was done by the core code. But other terminals do not show this, so... The 3rd problem may or may not be a gnuplot bug. 3) Under some conditions the entire plot has a black background. I only see this on machines with very different versions of cairo/pango/kde/kpdf/... so I'm having difficulty figuring out which program or library is at fault. But even if it is a viewer bug, there may still be a fix to gnuplot that would avoid triggering it Missing features: 4) There should be a dashlength option (similar to postscript) 5) Circles (e.g. point types 6 and 7) look jagged. This is ultimately the fault of the cairo library, but perhaps we could work around it by scaling a wellhinted character glyph instead? Any other observations?  Ethan A Merritt 
From: Henri P Gavin <hpgavin@Duke.edu>  20070730 19:14:30

Hello Gnuploters! First, I'd like to say that the Gnuplot fit function has always worked very well every time I've used it. (Thank you.) Second, however, I think there is a bug (or "feature") in the implementation of the LevenbergMarquardt algorithm, which may not have been intended. I think line 376 of fit.c should read tmp_C[num_data + i][i] = sqrt(*lambda); instead of tmp_C[num_data + i][i] = *lambda; The following explains why I think so. (Please forgive the Matlaboriented notation.) The Gnuplot implementation of LevenbergMarquardt solves the overdetermined system of equations [ J ; lambda*eye(n) ] * da = [ dy ; zeros(n,1) ]; , which is related to [ J'*J + lambda^2*eye(n) ] * da = dy; in which lambda is squared ... not necessarily the same as the method proposed by Marquardt, ... http://en.wikipedia.org/wiki/LevenbergMarquardt_algorithm On the other hand, the overdetermined system of equations [ J ; sqrt(lambda)*eye(n) ] * da = [ dy ; zeros(n,1) ]; is related to [ J'*J + lambda*eye(n) ] * da = dy; which *is* the usual form for the LevenbergMarquardt equations. Also see equation (1.4) of the Argonne National Lab page: http://wwwfp.mcs.anl.gov/otc/GUIDE/OptWeb/continuous/unconstrained/nonlinearls/section2_1_2.html Should fit.c be changed in the next release of Gnuplot? I'm not sure, since the fit function ain't necessarily broke, and since it converges really well every time I use it. Although I've studied and studied fit.c, I may not have noticed where the sqrt(*lambda) comes in, if it does. Is the current implementation an improvement over the usual LevenbergMarquardt method? This question would bear further investigation. At any rate, I'd be happy to know the outcome of this bugreport. Henri Gavin _________________________________________________________________________ Henri P. Gavin Henri.Gavin@... Department of Civil and Environmental Engineering tel: 919  660  5201 Duke University, Box 90287 fax: 919  660  5219 Durham, NC 277080287 http://www.duke.edu/~hpgavin/ 
From: <timothee.lecomte@en...>  20070727 10:10:46

> > Hello, > I have been developing a GTK application and I am now using GnuPlot to > create some graphical output. > > I was hoping to embed the gnuplot x window results into my GTK > application. > So far I have been unable to do that can anyone give me any tips on how I > would go about this? > > Thanks, > > Kiran Hi Kiran, Thanks for sharing your interest in gnuplot. There are several possible answers to your question: 1) You could do it in two steps: first, output to png (or whatever format), using gnuplot 'png' terminal, and then display the png inside your application, where you want it to be. Pros: quite easy Cons: Overhead of the png writing and displaying 2) You could use the following patch: http://sourceforge.net/tracker/index.php?func=detail&aid=1027032&group_id=2055&atid=302055 It is entitled "Connect gnuplot_x11 to exterior application window" and does what you want by allowing you to pass an XID in the 'set term x11' command. Pros: no overhead, mousing (zoom) should even work Cons: nonupstream patch, read the patch page for details 3) You could use the 'xlib' terminal. This one (not really restricted to xlib) will write lowlevel drawing commands to a file or a pipe, so that you can then draw by yourself on your window. Pros: you use the gdk API Cons: you have to interpret the drawing commmands, as it is done in gplot_x11.c I hope this can be useful. Best regards, Timothée Lecomte 
From: James R. Van Zandt <jrvz@co...>  20070727 02:17:44

Ethan Merritt wrote: > But that's not an issue of failing to store input data; it's an > issue of whether you apply axis scaling upon input or wait until > later. Currently the data are scaled and replaced. That means if the user reverts to linear scaling, the data has to be unscaled. Any nonpositive data points will have been lost. It also means we need an "unscale" function. The probability scaling in my patch uses the same kind of implementation. I would like to implement general scaling by a userdefined function, and would rather not force the user to supply its inverse too. We could do that with "just in time scaling"  i.e. store the data as read in from the file, and apply scaling immediately before calculating screen positions. If we agree that's the way to go, then it makes sense to make that change before applying [a version of] my axis scaling patch.  Jim Van Zandt 
From: James R. Van Zandt <jrvz@co...>  20070727 02:05:13

Petr Mikulik <mikulik@...> wrote: > > I've just uploaded a patch that implements probability axes: > > Probability axes simplify the presentation of certain kinds of data. > > It's just a particular scaling for one case. I would prefer Ethan's > proposal: > > > > I would like to be able to do something like: > > > > > > set axis x1 x # will use for Energy > > > set axis x2 k/x # will use for Wavelength > > > set axis y1 log(y) # log scale value to be plotted > > > I would like to see a more general mechanism too. For the general case, I would write something like set axis x1 f(x) # how the x1 axis labels and tic marks relate # to the "number being plotted" set axis x2 g(x) # how the x2 axis labels and tic marks relate # to the "number being plotted" set x scale h(x) # how screen distances relate to the "number # being plotted" plot (k($1)):2 # how the "number being plotted" relates to the # data in column 1 of the data file For an ordinary linear plot: f(x) = g(x) = h(x) = x For a log scale: f(x) = g(x) = x h(x) = log10(x) For probability scaling: f(x) = g(x) = x h(x) = inverse_normal_func(x) One tricky part is placing the tic marks and labels if f(h(x)) or g(h(x)) is nonlinear. That's what my code in transform.c does. The other tricky part is actually allowing the user to define the functions. I know the expression parsing and function evaluation is in gnuplot, but I have not been able to hook that up to my code. I'm hoping one of the other developers will consider that an easy job :) There are two more issues: 1) The range of validity for log scaling is hardcoded in, of course. I did the same thing for probability scaling. If we let the user define a function, I think we'll have to let him define its range of validity too. That holds for each of the functions f(), g(), and h(). So for Ethan's wavelength scale we would have something like set axis x1 x set axis x2 k/x valid x>0 set x scale log(x) valid x>0 or for probabilty scales set x scale inverse_normal_func(x) valid ((0<x) && (x<1)) 2) For either linear or log scales, gnuplot can "round out" the plot range so it can put a labeled tic mark at each end of the axis. If the two axes are related by a function, then we cannot generally do that. (A userdefined function may not even be defined outside the range of the data provided.) My code does not round out. > > > Even better if there is a way to automatically lock x1 to x2, so that > > > they are forced to span the same range. I don't follow this. It looks to me that Ethan's syntax does force the two axes to span the same range.  Jim Van Zandt 
From: <HBB<roeker@t...>  20070724 20:36:16

Shigeharu TAKENO wrote: > the following example may have a misprint which was pointed out > in Japanese gnuplot BBS by Prof. Tatsuro MATSUOKA. I send the > unified diff file for it. > >  From here  >  gnuplot.doc~ 20070724 11:26:58.000000000 +0900 > +++ gnuplot.doc 20070724 11:27:43.000000000 +0900 > @@ 3694,7 +3694,7 @@ > a different data set but having a common decay time, estimate the values of > the parameters. If the datafile has the format x:z:s, then > f(x,y) = (y==0) ? a*exp(x/tau) : b*exp(x/tau) >  fit f(x,y) 'datafile' using 1:1:2:3 via a, b, tau > + fit f(x,y) 'datafile' using 1:2:2:3 via a, b, tau That's not really a misprint. As the text above mentions, both 1 and 2 can be correct. It depends on how the data are formatted (separation by single or double blank records). 
From: Theo Hopman <thopman@ph...>  20070724 17:22:33

MartinOShea wrote: > Hello > > I have a set of sample data as follows: > > CEMI (x) ggbs(y) FLOW MM (z) > > 0.0 90.0 0 > 6.5 58.7 166 > 6.6 59.0 169 > 7.3 65.0 141 > 6.1 54.5 162 > 8.5 76.2 217 > 7.1 64.2 174 > 6.0 54.2 209 > 7.0 63.0 198 > 7.6 68.3 171 > > which produces a simple set of points on a 3D graph using splot. However, > what I would like is to do is to interpolate between points to calculate the > coordinates for a flow contour of, for example, 175 mm? > > Can anyone advise how I might do this? Contouring requires that the data be in grid format, i.e., with an equal number of 'y' values for every 'x' value. See `help grid_data` for details. You can use `set dgrid3d` to convert a nongridded data set to gridded, but the results of the default algorithm are (to my sight) generally unsatisfactory. If you're willing to build gnuplot from source, there is an option to replace the default dgrid3d algorithm with a more sophisticated one that produces results which are (again, to my sight) more pleasing. Try './configure enablethinsplines'. In either case, once you've used `set dgrid3d` to produce an interpolated surface, this surface can be used to create contours. Since contours are a global setting, and not a perdataset one, you'll likely want to use `set table` to output the contours to a file, then plot that file with your original data. THeo 
From: Petr Mikulik <mikulik@ph...>  20070724 12:25:41

> I've just uploaded a patch that implements probability axes: > Probability axes simplify the presentation of certain kinds of data. It's just a particular scaling for one case. I would prefer Ethan's proposal: > > I would like to be able to do something like: > > > > set axis x1 x # will use for Energy > > set axis x2 k/x # will use for Wavelength > > set axis y1 log(y) # log scale value to be plotted > > > > Even better if there is a way to automatically lock x1 to x2, so that > > they are forced to span the same range. > (By the way, I do have CVS write access, but I figured this would be > too big a change to apply to the head. I am not comfortable enough > with my CVS skills to start a new branch, let alone to try and merge > later on.) Your proposal is a major patch, so it should be discussed and agreed on the mailing list. Don't make a branch, stay with a patch.  PM 
From: Petr Mikulik <mikulik@ph...>  20070724 12:07:10

> the following example may have a misprint >  fit f(x,y) 'datafile' using 1:1:2:3 via a, b, tau > + fit f(x,y) 'datafile' using 1:2:2:3 via a, b, tau thanks, applied.  PM 
From: Shigeharu TAKENO <shige@ie...>  20070724 03:01:23

shige 07/24 2007  In docs/gnuplot.doc of current CVS version RCS $Id: gnuplot.doc,v 1.441 2007/07/16 20:37:25 sfeam Exp $ the following example may have a misprint which was pointed out in Japanese gnuplot BBS by Prof. Tatsuro MATSUOKA. I send the unified diff file for it.  From here   gnuplot.doc~ 20070724 11:26:58.000000000 +0900 +++ gnuplot.doc 20070724 11:27:43.000000000 +0900 @@ 3694,7 +3694,7 @@ a different data set but having a common decay time, estimate the values of the parameters. If the datafile has the format x:z:s, then f(x,y) = (y==0) ? a*exp(x/tau) : b*exp(x/tau)  fit f(x,y) 'datafile' using 1:1:2:3 via a, b, tau + fit f(x,y) 'datafile' using 1:2:2:3 via a, b, tau For a more complicated example, see the file "hexa.fnc" used by the "fit.dem" demo.  To here  +========================================================+ Shigeharu TAKENO NIigata Institute of Technology kashiwazaki,Niigata 9451195 JAPAN shige@... TEL(&FAX): +81257228161 +========================================================+ 
From: Theo Hopman <thopman@ph...>  20070723 17:48:02

Martin Giersich wrote: > > No change using 0/0. Same broken line drawing. I attached a plot output > of th above plotcommand. > > This rendering problems appear using MacOSX 10.4.... and gnuplot 4.0, > 4.2, 4.3. > > Btw, the official gnuplotdocumentation (Thomas Williams & Colin > Kelley, "gnuplot  An Interactive Plotting Program", 3 March 2007, > available at: http://www.gnuplot.info/docs/gnuplot.pdf) describes at > page 25 using "1/0" as a way that "may be used to generate an > "undefined" flag, which > causes a point to ignored". No other method to do this is refered. > If there is another method to do this  besides change of datfile > format  i'd like to know... > gnuplot is behaving exactly as documented. If you plot `with linespoints`, you will see that the expected points are present. However, not all points are joined with lines, because there is missing or invalid data between them. This is usually important information, and so gnuplot indicates this. If you really want to have the lines joined, you can do something like: plot "<awk '$3==1 { print }' AGdatatest.dat" using 4:5 w li You're effectively changing the data file format on the fly to omit the invalid data. gnuplot won't see it, and so will draw lines between the valid data points. THeo 
From: Lars Hecking <lhecking@us...>  20070723 10:08:14

There might be a problem with recent changes to the gnuplot.doc, or the .texi file generation in current cvs: $ make gnuplot.info /bin/sh ${HOME}/src/cvs/gnuplot/missing run makeinfo I. ./gnuplot.texi nosplit output=gnuplot.info ./gnuplot.texi:11756: Cross reference to nonexistent node `origin' (perhaps incorrect sectioning?). ./gnuplot.texi:11277: Cross reference to nonexistent node `origin' (perhaps incorrect sectioning?). ./gnuplot.texi:10938: Cross reference to nonexistent node `origin' (perhaps incorrect sectioning?). ./gnuplot.texi:10717: Cross reference to nonexistent node `origin' (perhaps incorrect sectioning?). ./gnuplot.texi:10706: Cross reference to nonexistent node `origin' (perhaps incorrect sectioning?). ./gnuplot.texi:10697: Cross reference to nonexistent node `origin' (perhaps incorrect sectioning?). ./gnuplot.texi:10680: Cross reference to nonexistent node `origin' (perhaps incorrect sectioning?). ./gnuplot.texi:10678: Cross reference to nonexistent node `origin' (perhaps incorrect sectioning?). ./gnuplot.texi:8592: Cross reference to nonexistent node `origin' (perhaps incorrect sectioning?). ./gnuplot.texi:5973: Cross reference to nonexistent node `origin' (perhaps incorrect sectioning?). ./gnuplot.texi:5954: Cross reference to nonexistent node `origin' (perhaps incorrect sectioning?). ./gnuplot.texi:5943: Cross reference to nonexistent node `origin' (perhaps incorrect sectioning?). ./gnuplot.texi:4551: Cross reference to nonexistent node `origin' (perhaps incorrect sectioning?). ./gnuplot.texi:3154: Cross reference to nonexistent node `origin' (perhaps incorrect sectioning?). makeinfo: Removing output file `gnuplot.info' due to errors; use force to preserve. make: *** [gnuplot.info] Error 1 
From: Ethan Merritt <merritt@u.washington.edu>  20070723 04:03:11

On Monday 16 July 2007, Martin Giersich wrote: > Btw, the official gnuplotdocumentation (Thomas Williams & Colin > Kelley, "gnuplot  An Interactive Plotting Program", 3 March 2007, > available at: http://www.gnuplot.info/docs/gnuplot.pdf) describes at > page 25 using "1/0" as a way that "may be used to generate an > "undefined" flag, which > causes a point to ignored". No other method to do this is refered. > If there is another method to do this  besides change of datfile > format  i'd like to know... Starting with version 4.2 there is a predefined variable named NaN which may be used for this purpose. 
From: <plotter@pi...>  20070722 22:48:26

On Wed, 18 Jul 2007 12:06:29 +0200, MartinOShea <appy74@...> wrote: > > Hello > > I have a set of sample data as follows: > > CEMI (x) ggbs(y) FLOW MM (z) > > 0.0 90.0 0 > 6.5 58.7 166 > 6.6 59.0 169 > 7.3 65.0 141 > 6.1 54.5 162 > 8.5 76.2 217 > 7.1 64.2 174 > 6.0 54.2 209 > 7.0 63.0 198 > 7.6 68.3 171 > > which produces a simple set of points on a 3D graph using splot. However, > what I would like is to do is to interpolate between points to calculate > the > coordinates for a flow contour of, for example, 175 mm? > > Can anyone advise how I might do this? > > Thanks > > Martin O'Shea. This will almost certainly need to be done outside gnuplot by preprocessing the data. CatmullRomm spline would probably be a good choice to interpolate your example contour at 175mm 
From: Ethan A Merritt <merritt@u.washington.edu>  20070720 03:51:15

On Thursday 19 July 2007 18:40, James R. Van Zandt wrote: > > I've just uploaded a patch that implements probability axes: > > 1757226 Provide "probability" scaling and axes 20070719 21:31 5 nobody vanzandt Looks interesting. But I'm heading out of town for a week, and won't be able to look at it until I get back. Ethan > > Rationale: > > Probability axes simplify the presentation of certain kinds of data. > > Recall that if Y varies as the exponential of X, then data values are > best shown in a log plot  i.e. where you plot the logarithm of Y > against X. More generally, if there are very small and very large Y > values, but all are positive, then it is convenient to use a log Y > axis. E.g. if you plot Y values of .002, .02, and 200 along a linear > axis, it would be hard to tell the first two apart. However, it would > be easy with a log axis. > > Suppose you have a collection of n data values that you think are > normally distributed. Find the "empirical distribution function": a > cumulative probability distribution function that concentrates > probability 1/n at each of the n numbers in the sample. I.e. sort the > values and label them X(1) through X(n). Then let Y(k)=k/n. If you > plot Y vs. X, you get something like a sigmoid curve, which starts > near the line Y=0, rises quickly near the mean of the X values, then > gradually approaches the line Y=1. Probability axes are the way of > transforming Y values such that, if the X values were really normally > distributed, then the transformed data points fall approximately along > a straight line. > > More generally, if there are both very small Y values and values very > near 1, but none outside the range 0 to 1 (e.g. if Ys represent > probabilities), then probability axes can make the data easier to see. > > Summary of changes: Most of the added code is in the new files > "transform.c" and the corresponding header file "transform.h". > > The "probability" transformation (inverse of normal CDF) is the only > one implemented here. However, the logic for labeling the axis is > quite general. The goal is to select a set of tics and minitics such > that: >  tic labels are "simple" >  tic labels do not overlap >  the distances between tics are roughly equal >  the numeric value corresponding to any minitic is unambiguous >  the distances between minitics are roughly equal, and small enough > that the numeric value of any point can be estimated by eye. > > The current code for log axes uses the functional forms for both the > data transform log(x) and its inverse 10^x. This patch for > probability axes does the same. However the part that calculates tic > and minitic locations uses the function form only for the forward > transformation  inverse values are found numerically. My hope is > that this more general implementation can be easily applied to other > transform functions, including usersupplied ones without a convenient > inverse. > > axis_array[axis].log is now an enum, with values SCALE_LINEAR, > SCALE_LOG, and SCALE_PROBABILITY, and AXIS_LOG_VALUE and > AXIS_DE_LOG_VALUE are functions instead of macros. > > TODO: >  Rename axis_array[axis].log to axis_array[axis].scale >  Convert names AXIS_LOG_VALUE and AXIS_DE_LOG_VALUE to lower case. >  Implement several other kinds of axes, including "weibull plots". >  Implement a usersupplied scaling function. >  Implement scaling only of axis labels, without scaling the data. >  New command syntax [axis] "set scale linearlogprobabilityf(x) xy..." > > > Ethan Merritt wrote: > > > > > > > > My request was simply that you leave the existing log scale code > > > > in place until a general mechanism was ready to replace it. > > > > > > What do you mean by general? Able to apply mappings other than > > > log scale? > > > > Exactly. I gave a bunch of examples earlier. The most common > > request (and hardest to work around) is marking off the Xaxis as > > 1/x. For instance, we crystallographers have to deal with > > inconsistent usage all the time; some quantities are given in terms > > of energy while others are given in terms of wavelength. There is > > an inverse relationship: > > Energy = k / Wavelength > > where k is an appropriate constant. It is a pain to try to persuade > > gnuplot to mark off both Energy and Wavelength on axes of the same plot. > > > > I would like to be able to do something like: > > > > set axis x1 x # will use for Energy > > set axis x2 k/x # will use for Wavelength > > set axis y1 log(y) # log scale value to be plotted > > > > Even better if there is a way to automatically lock x1 to x2, so that > > they are forced to span the same range. > > > >  > > Ethan A Merritt > > Ethan wants to rescale one or both axes without changing the data. I > would like to think that this patch is a first step toward that > capability. The patch rescales the data as well as the axes. > At least, it could easily handle the tic/minitic placement. > > (By the way, I do have CVS write access, but I figured this would be > too big a change to apply to the head. I am not comfortable enough > with my CVS skills to start a new branch, let alone to try and merge > later on.) > >  Jim Van Zandt  Ethan A Merritt 
From: James R. Van Zandt <jrvz@co...>  20070720 01:40:28

I've just uploaded a patch that implements probability axes: 1757226 Provide "probability" scaling and axes 20070719 21:31 5 nobody vanzandt Rationale: Probability axes simplify the presentation of certain kinds of data. Recall that if Y varies as the exponential of X, then data values are best shown in a log plot  i.e. where you plot the logarithm of Y against X. More generally, if there are very small and very large Y values, but all are positive, then it is convenient to use a log Y axis. E.g. if you plot Y values of .002, .02, and 200 along a linear axis, it would be hard to tell the first two apart. However, it would be easy with a log axis. Suppose you have a collection of n data values that you think are normally distributed. Find the "empirical distribution function": a cumulative probability distribution function that concentrates probability 1/n at each of the n numbers in the sample. I.e. sort the values and label them X(1) through X(n). Then let Y(k)=k/n. If you plot Y vs. X, you get something like a sigmoid curve, which starts near the line Y=0, rises quickly near the mean of the X values, then gradually approaches the line Y=1. Probability axes are the way of transforming Y values such that, if the X values were really normally distributed, then the transformed data points fall approximately along a straight line. More generally, if there are both very small Y values and values very near 1, but none outside the range 0 to 1 (e.g. if Ys represent probabilities), then probability axes can make the data easier to see. Summary of changes: Most of the added code is in the new files "transform.c" and the corresponding header file "transform.h". The "probability" transformation (inverse of normal CDF) is the only one implemented here. However, the logic for labeling the axis is quite general. The goal is to select a set of tics and minitics such that:  tic labels are "simple"  tic labels do not overlap  the distances between tics are roughly equal  the numeric value corresponding to any minitic is unambiguous  the distances between minitics are roughly equal, and small enough that the numeric value of any point can be estimated by eye. The current code for log axes uses the functional forms for both the data transform log(x) and its inverse 10^x. This patch for probability axes does the same. However the part that calculates tic and minitic locations uses the function form only for the forward transformation  inverse values are found numerically. My hope is that this more general implementation can be easily applied to other transform functions, including usersupplied ones without a convenient inverse. axis_array[axis].log is now an enum, with values SCALE_LINEAR, SCALE_LOG, and SCALE_PROBABILITY, and AXIS_LOG_VALUE and AXIS_DE_LOG_VALUE are functions instead of macros. TODO:  Rename axis_array[axis].log to axis_array[axis].scale  Convert names AXIS_LOG_VALUE and AXIS_DE_LOG_VALUE to lower case.  Implement several other kinds of axes, including "weibull plots".  Implement a usersupplied scaling function.  Implement scaling only of axis labels, without scaling the data.  New command syntax [axis] "set scale linearlogprobabilityf(x) xy..." Ethan Merritt wrote: > > > > > > My request was simply that you leave the existing log scale code > > > in place until a general mechanism was ready to replace it. > > > > What do you mean by general? Able to apply mappings other than > > log scale? > > Exactly. I gave a bunch of examples earlier. The most common > request (and hardest to work around) is marking off the Xaxis as > 1/x. For instance, we crystallographers have to deal with > inconsistent usage all the time; some quantities are given in terms > of energy while others are given in terms of wavelength. There is > an inverse relationship: > Energy = k / Wavelength > where k is an appropriate constant. It is a pain to try to persuade > gnuplot to mark off both Energy and Wavelength on axes of the same plot. > > I would like to be able to do something like: > > set axis x1 x # will use for Energy > set axis x2 k/x # will use for Wavelength > set axis y1 log(y) # log scale value to be plotted > > Even better if there is a way to automatically lock x1 to x2, so that > they are forced to span the same range. > >  > Ethan A Merritt Ethan wants to rescale one or both axes without changing the data. I would like to think that this patch is a first step toward that capability. The patch rescales the data as well as the axes. At least, it could easily handle the tic/minitic placement. (By the way, I do have CVS write access, but I figured this would be too big a change to apply to the head. I am not comfortable enough with my CVS skills to start a new branch, let alone to try and merge later on.)  Jim Van Zandt 
From: Theo Hopman <thopman@ph...>  20070719 13:58:57

j1n3l0 wrote: > I did solve my problem. I measured the distances for each margin and found > that there is a ratio system in place. My findings are summarised below: > > ========================================================================= > > coords [x, y] = [ (lmargin + (abs(xmin  x)/xrange * xlength)), (tmargin + > (abs(ymax  y)/yrange * ylength)) ] > > where: > > lmargin is the length in pixels of the left margin > > lmargin = 7 * gnuplot lmargin [...] > tmargin is the length in pixels of the top margin > > tmargin = 11 * gnuplot tmargin I'm glad your were able to solve your problem, but do note that your method will break if you use a different size default font. Margins are specified in terms of characters, and the font you're using happens to report a width of 7 and a height of 11. It'll likely break if you use a different terminal (probably because of a different default font), or if you add a title. Of course, good enough is often good enough :) THeo 
From: j1n3l0 <nelo.onyiah@gm...>  20070719 10:54:22

I did solve my problem. I measured the distances for each margin and found that there is a ratio system in place. My findings are summarised below: ========================================================================= coords [x, y] = [ (lmargin + (abs(xmin  x)/xrange * xlength)), (tmargin + (abs(ymax  y)/yrange * ylength)) ] where: lmargin is the length in pixels of the left margin lmargin = 7 * gnuplot lmargin xrange is the difference between the max and min x values xrange = abs(xmax  xmin) xlength is the length of the x axis in pixels xlength = image_width  (lmargin + rmargin) tmargin is the length in pixels of the top margin tmargin = 11 * gnuplot tmargin yrange is the difference between the max and min y values yrange = abs(ymax  ymin) ylength is the length of the y axis in pixels ylength = image_height  (tmargin + bmargin) ========================================================================= >From this I was able to construct a class which generates image maps of Gnuplots on the fly. Theo Hopman wrote: > > I'm not sure if it completely solves your problem, but new in 4.3 is a > feature that allows margins to be specified in terms of fractions of the > screen coordinate system. Since you presumably know the size of your > terminal's "screen", you can easily find where the borders of the graph > area are. This method will not work if you need (for whatever reason) to > have automatically calculated margins. > This information will be useful in future. I can substitute my methods for calculating the margins in pixels accordingly.  View this message in context: http://www.nabble.com/Isthereawayofconvertingplotcoordstographcoordstf1832453.html#a11686342 Sent from the Gnuplot  Dev mailing list archive at Nabble.com. 
From: ronnie_raj <kiran.rajaratnam@ba...>  20070718 15:25:29

Hello, I have been developing a GTK application and I am now using GnuPlot to create some graphical output. I was hoping to embed the gnuplot x window results into my GTK application. So far I have been unable to do that can anyone give me any tips on how I would go about this? Thanks, Kiran  View this message in context: http://www.nabble.com/embeddinggnuplotxwindowintogtkapptf4103801.html#a11670440 Sent from the Gnuplot  Dev mailing list archive at Nabble.com. 
From: MartinOShea <appy74@ds...>  20070718 10:06:37

Hello I have a set of sample data as follows: CEMI (x) ggbs(y) FLOW MM (z) 0.0 90.0 0 6.5 58.7 166 6.6 59.0 169 7.3 65.0 141 6.1 54.5 162 8.5 76.2 217 7.1 64.2 174 6.0 54.2 209 7.0 63.0 198 7.6 68.3 171 which produces a simple set of points on a 3D graph using splot. However, what I would like is to do is to interpolate between points to calculate the coordinates for a flow contour of, for example, 175 mm? Can anyone advise how I might do this? Thanks Martin O'Shea.  View this message in context: http://www.nabble.com/ContouringinGnuPlottf4102311.html#a11665821 Sent from the Gnuplot  Dev mailing list archive at Nabble.com. 
From: Theo Hopman <thopman@ph...>  20070717 13:08:15

Daantje wrote: > Isn't there any way to show labels for every point in the graph and not show > them on some command or some condition without plotting the entire graph > again??? No. Note that in your previous approach (turning the labels on with a hot key) you were `replot`ting anyway, so it seems to me it's not a big deal to `replot` to turn them off. > What's a smart way to solve this? If your plot is "big"  by which I assume you mean there is lots of data  preprocess the data to slim down the data set. Most often, if the (re)plotting is slow, it's because there's more data than is necessary for the resolution of the screen. THeo 
From: Daantje <d.deman@bn...>  20070717 07:07:16

HansBernhard Br=C3=B6ker2 wrote: >=20 > The only way to get rid of such an addition to the display is issue a=20 > new 'plot' command without it. >=20 Isn't there any way to show labels for every point in the graph and not sho= w them on some command or some condition without plotting the entire graph again??? What's a smart way to solve this? =20 View this message in context: http://www.nabble.com/GNUPlotundoreplottf4= 087368.html#a11644362 Sent from the Gnuplot  Dev mailing list archive at Nabble.com. 
From: <HBB<roeker@t...>  20070716 21:25:38

Daantje wrote: > I have been trying to figure out how to show and not show an extra graph in a > GNUPlot graph. You rather completely misunderstand the working and intention of 'replot'. > This works fine, the extra graph only shows after pressing the h. But now I > want to be able to get rid of the extra graph preferably by pressing the > same button. I don't want to plot the original graph again since it is > pretty big. Well, that's not going to work. You already plot the original graph again when you did 'replot'. That's what the command does: it REdoes the PLOT, optionally with some more datasets you specify as part of the replot command line. The only way to get rid of such an addition to the display is issue a new 'plot' command without it. 