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}
(9) 
_{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: <timothee.lecomte@en...>  20051030 19:33:22

Hello ! I am happy to provide an updated patch for the wxWidgets terminal, which = goes, as usually, a little further ! The patch on sourceforge : http://sourceforge.net/tracker/index.php?func=3Ddetail&aid=3D1267434&grou= p_id=3D2055&atid=3D302055 Some screenshots : http://tipote.free.fr/wxt12.png http://tipote.free.fr/wxt13.png http://tipote.free.fr/wxt14.png Changes in this patch : * rendering is done offscreen via the cairo library. This gives to the us= er really goodlooking plots thanks to line antialiasing ! And it gives me a more consistent drawing library... Of course, you need = to have cairo installed. It may seem another overhead, but in fact cairo is needed by gtk>2.8. * No longer use the readline thread, do all gnuplot<>term communication = via _waitforinput. It avoids to modify core gnuplot files, the main loop is no longer affect= ed. The patch is now completely safe as far as other terminals are concerned. * implement 'pause mouse' ( not very exciting : * implement 'suspend' ) Bug fixing : * should compile cleanly with a unicodeenabled wxwidgets library * reworked pattern/solid fill, much consistent What is remaining in my 'todo' list ? The following : * I plan to use the pango library to manage text. As you will see, cairo = draws text almost correctly (symbol font is working  in particular), but there are still some alignement problems. Pango will giv= e solid functions to calculate complete text extents. The pango dependency is not a problem under unix, as wxwidgets already de= pends on gtk, which depends on pango and cairo. * I have still not tested under Windows. * clipboard bug (two plots in clipboard) remains I hope you will enjoy these changes and I will be pleased to have your ad= vice. Best regards, Timoth=E9e Lecomte 
From: Petr Mikulik <mikulik@ph...>  20051027 20:50:10

>  But both should not "differ too much". Maybe a "screen_color_sequence" >  option for postscripts? > > I don't know such option of postscript terminal. That was a pure proposal. >  It would be really great if someone unitifies the sequence for at least 16 >  colors. > > I am sorry I can't understand many good opinions from many > authors well, and I seem the topic have spreaded too widely. If someone writes down a sequence of 16, 32, or ... colors which will be the same on all terminals, than we can vote to put it there. > In png terminal, we can set any color sequence. And some users > want to know how to set it to the same one of x11 (or win) term. > I use the color sequence setting of png terminal, but the test > command don't make the same image because png terminal use > original color over the user setting. Currently "many" terminals have the same color seq as the postscript terminal, for at least the first "few" color items. > Is not useful to introduce such looping option (limitation of use > of colors) to png terminal ? It would be nice to have this feature consistent for all terminals.  PM 
From: Ethan Merritt <merritt@u.washington.edu>  20051027 15:32:53

On Tuesday 25 October 2005 11:01 am, Mangas wrote: > hi all, > Having a gnuplot plugin for mozilla would be quite useful to me for a web > application I'm writing (my server is too resource limited for gnuplot). Before > I dive into the task, I figured I would check if others have already put some > thought or development effort into a gnuplot browser plugin. Would folks (other > than me) find such a plugin useful? Any feedback would be appreciated. Please see my web page for examples of gnuplot use via the web: http://www.bmsc.washington.edu/people/merritt/gnuplot_test.html Now that you remind me, I realize that I have not tested that demo page since moving it to a new web server, so I don't promise that the actual demo is functional at the moment, although the description and instructions should still be valid. You might also have a look at using the svg terminal driver. It produces svg files that can be embedded in normal html and viewed serverside by an svg plugin. A lot more could be done to test and improve this driver, so if you are looking for a place to start this might be a good one. For instance, it is possible to add clientside mousing interactions with embedded svg code. Here are some web pages that point to examples using svg + mousing: http://www.mit.edu/afs/athena/course/11/11.951/www/media/SVG.html http://www.carto.net/papers/svg/samples/  Ethan A Merritt merritt@... Biomolecular Structure Center Mailstop 357742 University of Washington, Seattle, WA 98195 
From: Shigeharu TAKENO <shige@ie...>  20051027 00:50:56

shige 10/27 2005   Date: Fri, 21 Oct 2005 18:01:56 +0200 (CEST)  From: Petr Mikulik <mikulik@...>  To: Shigeharu TAKENO <shige@...>  Cc: merritt@..., gnuplotbeta@...  Subject: Re: color loop for gd.trm =====  >  So your goal is not to reduce the total number of colors, instead  >  it is to have the same default colors on all terminals?  >  > No. I only want to realize x11 or win term's color loops on png  > term simply. =====  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, ...  svg, cgm, wmf, ...  xfig, corel, ...  postscript and other paper printings:  postscript, pdf, pslatex, pstex   But both should not "differ too much". Maybe a "screen_color_sequence"  option for postscripts? I don't know such option of postscript terminal.  It would be really great if someone unitifies the sequence for at least 16  colors. I am sorry I can't understand many good opinions from many authors well, and I seem the topic have spreaded too widely. So I explain my opinion. In png terminal, we can set any color sequence. And some users want to know how to set it to the same one of x11 (or win) term. I use the color sequence setting of png terminal, but the test command don't make the same image because png terminal use original color over the user setting. So, I think I will be able to set simply if png terminal has the color loop option. Is not useful to introduce such looping option (limitation of use of colors) to png terminal ? +========================================================+ Shigeharu TAKENO NIigata Institute of Technology kashiwazaki,Niigata 9451195 JAPAN shige@... TEL(&FAX): +81257228161 +========================================================+ 
From: Mangas <mangas.fox@gm...>  20051025 19:02:23

hi all, Having a gnuplot plugin for mozilla would be quite useful to me for a web application I'm writing (my server is too resource limited for gnuplot). Before I dive into the task, I figured I would check if others have already put some thought or development effort into a gnuplot browser plugin. Would folks (other than me) find such a plugin useful? Any feedback would be appreciated. cheers, mangas 
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 
From: Ethan A Merritt <merritt@u.washington.edu>  20051023 23:16:14

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. Yes, I know that not all C compilers require IEEE floating point. But I am inclined to say that if your compiler is so broken that it fails to store 0 as 0, then using it to build gnuplot will reveal bigger problems than accurate text rotation :) >> 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. > 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`". > 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. > And we really should find out which terminals are capable of arbitrary > text angles but do not use it right now. Sure. I originally added it to all the terminal types I could test at the time. And there's a patch on SourceForge that adds it to metapost. But there remain other terminal types I cannot test, or I do not have documentation for their output device capabilities.  Ethan A Merritt Biomolecular Structure Center University of Washington, Seattle 981957742 
From: Harald Harders <h.harders@tu...>  20051023 21:54:48

Ethan, I will also post this mail to the mailing list because at least parts of it can be interesting to the gnuplot community. On Sun, 23 Oct 2005, Ethan A Merritt wrote: > On Sunday 23 October 2005 01:50 pm, you wrote: > > I do not agree that (angle == 0) is sufficient. Many > > terminals switch from horizontal text to vertical text > > (angle 90) if the given angle is different from 0. If small > > rounding errors lead to vertical text instead of horizontal > > text, this is a severe bug. > > 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. Does the ANSI C standard define that float a = 0.0; if (a == 0) ... always is true? I don't think so. May be, most architectures do so. But all? When learning programming I have always been told not to test against an exact value when using floating variables. > The only place a rotation angle gets set is in > parse_label_options(). > So it should be sufficient to check in that one place. > >  gnuplot/src/set.c 20051009 19:44:36.000000000 0700 > +++ gnuplotcvs/src/set.c 20051023 14:27:18.995207128 0700 > @@ 4741,7 +4788,9 @@ I find more: 3555, 4020 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). With the approach in my patch, all newly introduced angles are covered automatically. And rounding errors of a bad C compiler implementation are eliminated. The number of calles to these functions is not too bad to slow down plots since normally, not too many texts are put into a plot (in comparison to lines, for instance). 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? But I think this could be a seperate patch after this one. And we really should find out which terminals are capable of arbitrary text angles but do not use it right now. I have found at least one of them. Best regards Harald  Harald Harders h.harders@... http://www.haraldharders.de 
From: Ethan A Merritt <merritt@u.washington.edu>  20051023 19:58:01

On Sunday 23 October 2005 12:23 am, Petr Mikulik wrote: > > It would be nice to organize that > plot 'a.dat' matrix > is equivalent to > plot 'a.dat' matrix using 1:3 OK. That part is now in cvs. I'm still amazed that this works. Who knew that you could plot data rows? I'm still confused by the documentation, and will try to clarify it. For example, you suggest > The zvalues are read in a row at a time, i. e., > z11 z12 z13 z14 ... > z21 z22 z23 z24 ... > z31 z32 z33 z34 ... > 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. My current best effort at writing a description is: 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. Example: set view map splot <foo> matrix using ($1 * 5.):2:(sqrt($3)) This example will plot the value sqrt(Mij) at the coordinates x=5i, y=j for each entry i,j represented in the matrix. Does this description seem OK to you? > *** > > Proposal for 'help matrix', please modify: > > Datafile can be in an ascii or binary matrix format. The `matrix` flag > indicates that the file is ascii, the `binary` or `matrix binary` stands > for a binary format. For details, see `matrix ascii` or `matrix binary`. > > Basic usage in `splot`: > splot 'a.dat' matrix > splot 'a.gpbin' {matrix} binary > Advanced usage in `splot`: > splot 'a.dat' matrix using 1:2:3 > splot 'a.gpbin' {matrix} binary using 1:2:3 > allows to manipulate the axes coordinates and the zdata. > > Usage in `plot`: > plot `a.dat` matrix using 1:3 > plot 'a.gpbin' {matrix} binary using 1:3 > will plot rows of the matrix, while using 2:3 will plot matrix columns, > and 1:2 point coordinates. Applying the `every` option you can specify > explicit rows and columns. > > Example  rescale axes for an ascii matrix: > splot `a.dat` matrix using (1+$1):(1+$2*10):3 > > Example  plot the 3rd row of an ascii matrix: > plot 'a.dat' matrix using 1:3 every 1:999:1:2 > (rows are enumerated from 0, thus 2 instead of 3). > > *** > > Proposal for 'help matrix ascii', please modify: > > The `matrix` flag in > {s}plot 'a.dat' matrix > indicates that the ASCII data are stored in matrix format. > > The zvalues are read in a row at a time, i. e., > z11 z12 z13 z14 ... > z21 z22 z23 z24 ... > z31 z32 z33 z34 ... > and so forth. > > X and yindices of the matrix correspond to column and row index of the > matrix, starting from 0. You can rescale or transform the axes as usual > for a data file with three columns (x=$1, y=$2, z=$3), for example > splot 'a.dat' matrix using (1+$1/100):(1+$2*10):3 > > A blank line or comment line ends the matrix, and starts a new > surface mesh. You can select among the meshes inside a file by the > `index` option to the `splot` command, as usual. > > >  > PM  Ethan A Merritt Biomolecular Structure Center University of Washington, Seattle 981957742 
From: Juergen Wieferink <wieferink@fr...>  20051023 08:46:48

On Saturday 22 October 2005 20:42 Ethan A Merritt wrote: > How about if we could plot Petr's example: > splot 'matrix.dat' matrix using (1+$1/100):(1+$2*10):3 > as > f(x) = 1 + x/100 > g(y) = 1 + y*10 > splot 'matrix.dat' matrix xticlabels(f(x)):yticlabels(g(y)) > > Would that be more natural? With this, I would expect one label for each row and each column. I think it would be more natural to introduce some set format x function f(x) where f(x) is a string valued expression with a dummy variable "x". But in the case of matrix, I prefer Petr's example. Juergen 
From: Petr Mikulik <mikulik@ph...>  20051023 07:23:14

> You don't find it confusing that in 2D plots you need to say > plot 'data' matrix using ($1):($3) > > Why ($3)? I never know I can use plot ... matrix I'm still learning gnuplot :)) It would be nice to organize that plot 'a.dat' matrix is equivalent to plot 'a.dat' matrix using 1:3 *** Proposal for 'help matrix', please modify: Datafile can be in an ascii or binary matrix format. The `matrix` flag indicates that the file is ascii, the `binary` or `matrix binary` stands for a binary format. For details, see `matrix ascii` or `matrix binary`. Basic usage in `splot`: splot 'a.dat' matrix splot 'a.gpbin' {matrix} binary Advanced usage in `splot`: splot 'a.dat' matrix using 1:2:3 splot 'a.gpbin' {matrix} binary using 1:2:3 allows to manipulate the axes coordinates and the zdata. Usage in `plot`: plot `a.dat` matrix using 1:3 plot 'a.gpbin' {matrix} binary using 1:3 will plot rows of the matrix, while using 2:3 will plot matrix columns, and 1:2 point coordinates. Applying the `every` option you can specify explicit rows and columns. Example  rescale axes for an ascii matrix: splot `a.dat` matrix using (1+$1):(1+$2*10):3 Example  plot the 3rd row of an ascii matrix: plot 'a.dat' matrix using 1:3 every 1:999:1:2 (rows are enumerated from 0, thus 2 instead of 3). *** Proposal for 'help matrix ascii', please modify: The `matrix` flag in {s}plot 'a.dat' matrix indicates that the ASCII data are stored in matrix format. The zvalues are read in a row at a time, i. e., z11 z12 z13 z14 ... z21 z22 z23 z24 ... z31 z32 z33 z34 ... and so forth. X and yindices of the matrix correspond to column and row index of the matrix, starting from 0. You can rescale or transform the axes as usual for a data file with three columns (x=$1, y=$2, z=$3), for example splot 'a.dat' matrix using (1+$1/100):(1+$2*10):3 A blank line or comment line ends the matrix, and starts a new surface mesh. You can select among the meshes inside a file by the `index` option to the `splot` command, as usual.  PM 
From: Ethan A Merritt <merritt@u.washington.edu>  20051023 04:27:05

On Saturday 22 October 2005 03:02 pm, Petr Mikulik wrote: > I think I've tracked the bug down Found it. Bleah. It really has been there since forever. It's in df_tokenise(), and it is specific to ascii matrix data. Here is the fix:  gnuplot/src/datafile.c 20051021 22:50:13.000000000 0700 +++ gnuplotcvs/src/datafile.c 20051022 21:10:08.276728128 0700 @@ 1145,6 +1146,7 @@ if (df_matrix) { duplication=TRUE; break; } df_matrix = TRUE; #endif + fast_columns = 0; continue; } Corey Satten's monster optimization test skips all columns past the first three unless some test has previously cleared the fast_columns flag. Examples of things that clear the flag are parentheses in the using spec and the presence of the "binary" flag. The optimization test is also skipped if there are no using specs at all. Ascii matrix data is not covered by any of these exceptions, so df_tokenise() only parses the first 3 columns. Amazing that no one has complained in all the time since 3.7 came out.  Ethan A Merritt Biomolecular Structure Center University of Washington, Seattle 981957742 
From: Ethan A Merritt <merritt@u.washington.edu>  20051022 23:48:39

On Saturday 22 October 2005 02:55 pm, Petr Mikulik wrote: >>> x = $1, y = $2 (autogenerated row and column index of the matrix) >> It is very confusing because it is not consistent with all other >> plot/splot "datafile" commands. In all other cases $1 means >> column 1 of the file, regardless of whether it is being used as >> an x value. > It's not confusing, because you specify the "matrix" keyword. Same for > (the new) "binary" stuff. You don't find it confusing that in 2D plots you need to say plot 'data' matrix using ($1):($3) Why ($3)?  Ethan A Merritt Biomolecular Structure Center University of Washington, Seattle 981957742 