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}
(31) 
_{May}

_{Jun}

_{Jul}

_{Aug}

_{Sep}

_{Oct}

_{Nov}

_{Dec}

S  M  T  W  T  F  S 







1

2
(10) 
3
(9) 
4
(15) 
5
(12) 
6
(12) 
7
(9) 
8
(3) 
9
(4) 
10
(6) 
11
(15) 
12
(17) 
13
(15) 
14
(6) 
15
(4) 
16
(5) 
17
(4) 
18

19

20
(2) 
21
(4) 
22
(7) 
23
(6) 
24
(13) 
25
(1) 
26

27
(3) 
28

29

30
(1) 
31






From: Ethan Merritt <merritt@u.washington.edu>  20051024 19:16:38

On Monday 24 October 2005 12:04 pm, mikulik@... wrote: > > rotated text, you can easily use some variant of > > set label "`date`". > > This is not portable to Windows. Windows doesn't support rotated text to begin with, so this seems like a quibble.  Ethan A Merritt merritt@... Biomolecular Structure Center Mailstop 357742 University of Washington, Seattle, WA 98195 
From: <mikulik@ph...>  20051024 19:04:25

> rotated text, you can easily use some variant of > set label "`date`". This is not portable to Windows.  PM 
From: HansBernhard Broeker <broeker@ph...>  20051024 18:45:00

Harald Harders wrote: > With your argument that I could use an ordinary label I also could say > that the function timestamp was useless. It quite possibly might be. That's what happens if you add generic implementations of some features (the sprintf() function) several years after other people added some very specifically target special cases ('set timestamp', my numberprinting extension to 'set label'). OTOH, there are still some things that 'set timestamp' does, but a similar 'set label' doesn't: it gets space reserved for itself by the global layout function, boundary(). 
From: Harald Harders <h.harders@tu...>  20051024 18:06:59

On Sun, 23 Oct 2005, Ethan A Merritt wrote: > On Sunday 23 October 2005 03:00 pm, Harald Harders wrote: > > float a = 0.0; > > if (a == 0) ... > > > > always is true? I don't think so. > > IEEE standard guarantees this. Even in the case that an architecture > can represent both +0 and 0, it is required that +0 == 0. Good to hear. But as Petr sais, this does not count for angles that are multiples of 90 deg. Thus, I think it is the saves way to introduce a range in the test for horizontal or vertical texts. > >> The only place a rotation angle gets set is in parse_label_options(). > > I find more: 3555, 4020 > > True. This may be telling us that these places > ("set tics" and "set {xyz}tics") should call parse_label_options() > rather than duplicating the code locally. Independent of this problem, yes. > > Sooner or later, this will also have to be added in line 3715 (by the > > way, funny that there still are texts not rotatable by arbitrary > > angles). > > You want to rotate the timestamp? That seems a little bit overboard. > If you really want to write the data on a plot in a fancy font or > rotated text, you can easily use some variant of set label "`date`". I think all text objects should be handled equally. Thus, every text object should be rotatable. This would eas handling and documentation. We could say 'Text can be rotated by using the option `rotate by`'. If you or I find it useful to rotate a specific type of text does not matter there. With your argument that I could use an ordinary label I also could say that the function timestamp was useless. > > Another thing could be thought of: > > Terminals that can only set term horizontally or vertically should > > switch from horizontal to vertical text when exceeding 45 degrees, not > > when going from zero to one. What do you mean? > > I think that if someone really wants 45 degree text, they will be > equally unhappy with either 0 or 90. 45 Degrees was an arbitrary example. A user that gives 10 deg will be more happy with horizontal text than with vertical text. And vertical text is what happens at the moment. Best regards Harald  Harald Harders h.harders@... http://www.haraldharders.de 
From: Petr Mikulik <mikulik@ph...>  20051024 17:19:35

>> I would keep the x, y and z for both plot and splot cases, and add that >> the default using for plot is >> plot 'a.dat' matrix using 1:3 >> and not using 1:2 which makes no good sense for matrices. > > Sorry, I must be really dense today. > I am just not understanding your way of naming things. > > In a 2D plot we are plotting y = f(x). > x is taken from the first using spec. > y is taken from the second using spec. > There is no z. > > So when you say "plot 'a.dat' matrix using 1:3" > you are asking for x from column 1 and y from column 3. > How can it be correct to document column 3 as being z > in this case? I consider matrix as a 3D object, and I draw its section in 2D. See 'help binary general' and 'help binary general examples'  it's the same thing, just binary not ascii, and also plot as (x,y,z) via "plot" in 2D. > Maybe we need to write totally separate sections for the 2D case > and the 3D case. I tried that in my proposal text for the two help sections, with examples. > section. I'll hand it back to you. > Or maybe somebody else wants to take a stab at it? At the moment I stay with the proposed text.  PM 
From: Petr Mikulik <mikulik@ph...>  20051024 17:15:16

>>>>> x = $1, y = $2 (autogenerated row and column index of the matrix) > > That's indeed at least slightly strange. It boils down to two questions, > which are strongly interconnected: > > 1) Why not use existing pseudocolumn numbers 0 and 1, instead of 1 and 2? I think $1, $2 and $3 is logic for this matrix case. > 2) Should > > 1 2 3 > 4 5 6 > 7 8 9 > > read by the ordinary routines, or to > > 0 0 1 > 1 0 2 > 2 0 3 yes, to this one, as it now works  just the docs is missing >> You don't find it confusing that in 2D plots you need to say >> plot 'data' matrix using ($1):($3) No, because you "plot" (in 2D) a 3D object (matrix with axes). That's the same as for "plot ... with image". > Thus my suggestion is: we make up our mind about the answers to the above > questions, and add to 'help matrix' accordingly. That's what I meant when sending proposal for the new text of 'help matrix' and 'help matrix ascii'. Please update it if you like.  PM 
From: Petr Mikulik <mikulik@ph...>  20051024 17:08:44

>> Then there should be these groups of color terminals, each group with the >> same color sequence: >> screen&bitmaps: >> x11, windows, pm, wx >> png, gif, jpeg, ... > > Neither of the below is particular 'screen', and none of them is a bitmap. > So I don't see convincing reasons they should use the 'screen' > colour sequence, instead of the 'paper' one. >> svg, cgm, wmf, ... >> xfig, corel, ... What is your proposal for the color unification?  PM 
From: HansBernhard Broeker <broeker@ph...>  20051024 14:35:19

Petr Mikulik wrote: > Then there should be these groups of color terminals, each group with > the same color sequence: > screen&bitmaps: > x11, windows, pm, wx > png, gif, jpeg, ... Neither of the below is particular 'screen', and none of them is a bitmap. So I don't see convincing reasons they should use the 'screen' colour sequence, instead of the 'paper' one. > svg, cgm, wmf, ... > xfig, corel, ... 
From: HansBernhard Broeker <broeker@ph...>  20051024 14:02:35

Harald Harders wrote: > I don't trust C compilers that they will return exactly 0 when you set a > variable to 0 in all cases. Does the ANSI C standard define > that > > float a = 0.0; > if (a == 0) ... > > always is true? Pretty much so. For zero literals, that is. As soon as you use any kind of computation that your maths book says yields zero, all bets are off. > Another thing could be thought of: > Terminals that can only set term horizontally or vertically should switch > from horizontal to vertical text when exceeding 45 degrees, not when going > from zero to one. What do you mean? As part of your change from integer to float, which is a complete break of the existing terminal API anyway, that modification makes sense. As part of the previous extension, where we just extended the interpretation of an int argument that was meant to be boolean (rotate by 90 degrees or not), it wouldn't have. 
From: HansBernhard Broeker <broeker@ph...>  20051024 13:48:45

Ethan A Merritt wrote: > On Saturday 22 October 2005 02:55 pm, Petr Mikulik wrote: > > >>>> x = $1, y = $2 (autogenerated row and column index of the matrix) That's indeed at least slightly strange. It boils down to two questions, which are strongly interconnected: 1) Why not use existing pseudocolumn numbers 0 and 1, instead of 1 and 2? 2) Should 1 2 3 4 5 6 7 8 9 read as 'matrix' be equivalent to a file 1 2 3 4 5 6 7 8 9 read by the ordinary routines, or to 0 0 1 1 0 2 2 0 3 0 1 4 1 1 5 2 1 6 0 2 7 1 2 8 2 2 9 The current implementation seems to be implying the latter format, which in turn makes column numbers 1, 2 a suitable choice. It effectively gives x values $1 = $0, and y vales $2 = column(1). > You don't find it confusing that in 2D plots you need to say > plot 'data' matrix using ($1):($3) Well, given the current documentation (as in: lack of) what 'matrix' actually means in terms of column numbers, any expectations would be wrong by default. Thus my suggestion is: we make up our mind about the answers to the above questions, and add to 'help matrix' accordingly. 
From: Ethan A Merritt <merritt@u.washington.edu>  20051024 07:02:06

On Sunday 23 October 2005 10:38 pm, mikulik@... wrote: > > "Column 3" may or may not be a Z value, depending > > on what kind of graph you are describing. > > I would keep the x, y and z for both plot and splot cases, and add that > the default using for plot is > plot 'a.dat' matrix using 1:3 > and not using 1:2 which makes no good sense for matrices. Sorry, I must be really dense today. I am just not understanding your way of naming things. In a 2D plot we are plotting y = f(x). x is taken from the first using spec. y is taken from the second using spec. There is no z. So when you say "plot 'a.dat' matrix using 1:3" you are asking for x from column 1 and y from column 3. How can it be correct to document column 3 as being z in this case? > > Matrix values are read in a row at a time, i. e., > > M11 M12 M13 M14 ... (i=1) > > M21 M22 M23 M24 ... (i=2) > > M31 M32 M33 M34 ... (i=3) > > ... ... ... ... Mij > > > > The interpretation of columns in the "using" specification for > > matrix data is different from the usual case. "$1" refers to the > > matrix row index i, "$2" refers to the matrix column index j, > > and "$3" refers to the matrix entry Mij. > > Indexing starts from 0. Oops. Yes. > Further, x is the column index j, y is row index i. Yeah, I'm not doing so well in describing this either. And on top of that we may be suffering from a difference in naming conventions. I am now uncertain whether the term "row index" means the same thing to you that it does to me. And even if it does, there are people in the world that use a different convention so maybe it is better not to use the terms at all. I agree that the x value of the plot is taken from the index j. But neither i nor j is "y" in the sense of a 2D graph coordinate. The y value is take from Mij. If there are multiple lines in the data file, then i will be counting out successive plots in the 2D graph. So it is neither "x" nor "y", but rather it is "plot number". Maybe we need to write totally separate sections for the 2D case and the 3D case. Anyhow, I don't seem to be having much luck at writing this section. I'll hand it back to you. Or maybe somebody else wants to take a stab at it?  Ethan A Merritt Biomolecular Structure Center University of Washington, Seattle 981957742 
From: <mikulik@ph...>  20051024 05:38:53

>> But where can these rounding errors occur? >> Not internal to gnuplot, because gnuplot does not calculate >> text rotation angle internally anywhere that I can think of. > > I don't trust C compilers that they will return exactly 0 when you set a variable to 0 in all cases. The rounding error correction could be useful for all multiples of 90 deg rotations, if they were calculated from n*pi/2; mainly if there are special terminal routines for vertical text.  PM 
From: <mikulik@ph...>  20051024 05:38:37

> I'm still confused by the documentation, and will try to > clarify it. For example, you suggest > >> X and yindices of the matrix correspond to column and row index of the > > But this is not really correct, as the use of "plot <foo> matrix" > demonstrates. "Column 3" may or may not be a Z value, depending > on what kind of graph you are describing. I would keep the x, y and z for both plot and splot cases, and add that the default using for plot is plot 'a.dat' matrix using 1:3 and not using 1:2 which makes no good sense for matrices. > Matrix values are read in a row at a time, i. e., > M11 M12 M13 M14 ... (i=1) > M21 M22 M23 M24 ... (i=2) > M31 M32 M33 M34 ... (i=3) > ... ... ... ... Mij > > The interpretation of columns in the "using" specification for > matrix data is different from the usual case. "$1" refers to the > matrix row index i, "$2" refers to the matrix column index j, > and "$3" refers to the matrix entry Mij. Indexing starts from 0. Further, x is the column index j, y is row index i. > Does this description seem OK to you? Please combine it with my longer description with example for both 'help matrix' and 'help matrix ascii'.  PM 