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
(21) |
Oct
(26) |
Nov
(10) |
Dec
(2) |
| 2017 |
Jan
(26) |
Feb
(27) |
Mar
(44) |
Apr
(11) |
May
(32) |
Jun
(28) |
Jul
(75) |
Aug
(45) |
Sep
(35) |
Oct
(285) |
Nov
(99) |
Dec
(16) |
| 2018 |
Jan
(8) |
Feb
(8) |
Mar
(42) |
Apr
(35) |
May
(23) |
Jun
(12) |
Jul
(16) |
Aug
(11) |
Sep
(8) |
Oct
(16) |
Nov
(5) |
Dec
(8) |
| 2019 |
Jan
(9) |
Feb
(28) |
Mar
(4) |
Apr
(10) |
May
(7) |
Jun
(4) |
Jul
(4) |
Aug
|
Sep
(4) |
Oct
|
Nov
(23) |
Dec
(3) |
| 2020 |
Jan
(19) |
Feb
(3) |
Mar
(22) |
Apr
(17) |
May
(10) |
Jun
(69) |
Jul
(18) |
Aug
(23) |
Sep
(25) |
Oct
(11) |
Nov
(20) |
Dec
(9) |
| 2021 |
Jan
(1) |
Feb
(7) |
Mar
(9) |
Apr
|
May
(1) |
Jun
(8) |
Jul
(6) |
Aug
(8) |
Sep
(7) |
Oct
|
Nov
(2) |
Dec
(23) |
| 2022 |
Jan
(23) |
Feb
(9) |
Mar
(9) |
Apr
|
May
(8) |
Jun
(1) |
Jul
(6) |
Aug
(8) |
Sep
(30) |
Oct
(5) |
Nov
(4) |
Dec
(6) |
| 2023 |
Jan
(2) |
Feb
(5) |
Mar
(7) |
Apr
(3) |
May
(8) |
Jun
(45) |
Jul
(8) |
Aug
|
Sep
(2) |
Oct
(14) |
Nov
(7) |
Dec
(2) |
| 2024 |
Jan
(4) |
Feb
(4) |
Mar
|
Apr
(7) |
May
(2) |
Jun
(1) |
Jul
|
Aug
(5) |
Sep
|
Oct
|
Nov
(4) |
Dec
(14) |
| 2025 |
Jan
(22) |
Feb
(6) |
Mar
(5) |
Apr
(14) |
May
(6) |
Jun
(11) |
Jul
(19) |
Aug
|
Sep
(17) |
Oct
(1) |
Nov
(2) |
Dec
(18) |
| 2026 |
Jan
|
Feb
|
Mar
(5) |
Apr
|
May
(2) |
Jun
(1) |
Jul
(6) |
Aug
(1) |
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Allin C. <cot...@wf...> - 2009-03-19 15:12:42
|
On Thu, 19 Mar 2009, Petr Mikulik wrote: > > Every now and then I build a binary of CVS gnuplot for win32 > > (cross-building on Linux). The last time I did that was several > > months ago, and the binary worked fine. I recently (2009-03-02) > > updated and re-built. The new binary seemed OK at first, but now > > I notice that it crashes whenever I try to use the "handle" > > cursor to rotate a 3d plot in the windows terminal. > > I cannot reproduce this problem --- executable compiled by > Mingw32 on Wine. Thanks for the replies. I think the issue must have been that I wasn't correctly synced with CVS. I deleted my gnuplot tree and checked out the sources again, rebuilt, and now the 3d plot is OK. Apologies for the noise. Allin Cottrell |
|
From: Ethan A M. <merritt@u.washington.edu> - 2009-03-19 06:40:37
|
On Wednesday 18 March 2009, Petr Mikulik wrote:
> Can somebody else on Windows reproduce the bug below? I would like this gets
> fixed before 4.2.5 is released.
>
> In Windows, there is only one open and active graph window.
> I think this could be the reason while mouse.c:event_keypress() reports
> "protocol error" if you try e.g.:
>
> bind 's' 'print "Hello";'
> bind 'd' 'set grid;'
> bind 'f' 'set time'
> bind 'g' 'plot x;'
> bind 'x' 'test;'
> plot x*x
>
> and then press "s" hotkey (or the others) several times.
>
> The code in mouse.c after
> if (ptr->allwindows && ptr->command) {
>
> is testing "allwindows" and "active" windows but it could somehow miss the
> case of a single-window graph. I'm not sure what should be the correct fix
> among these several if .. else if ... This well handles case of multiple
> windows (x11, wxt), but what should it do for single-window cases such as
> windows or pm terminals?
It must recognize the current window correctly, or it would have exited the
loop before reaching that protocol error message.
1387: } else if (!current) break;
I think it is more likely that some spurious event is being generated
in addition to the desired keypress event, and we should just ignore it.
Is the behaviour acceptable if you change the fprintf() to FPRINTF(())?
--
Ethan A Merritt
|
|
From: Petr M. <mi...@ph...> - 2009-03-19 05:55:05
|
Can somebody else on Windows reproduce the bug below? I would like this gets
fixed before 4.2.5 is released.
In Windows, there is only one open and active graph window.
I think this could be the reason while mouse.c:event_keypress() reports
"protocol error" if you try e.g.:
bind 's' 'print "Hello";'
bind 'd' 'set grid;'
bind 'f' 'set time'
bind 'g' 'plot x;'
bind 'x' 'test;'
plot x*x
and then press "s" hotkey (or the others) several times.
The code in mouse.c after
if (ptr->allwindows && ptr->command) {
is testing "allwindows" and "active" windows but it could somehow miss the
case of a single-window graph. I'm not sure what should be the correct fix
among these several if .. else if ... This well handles case of multiple
windows (x11, wxt), but what should it do for single-window cases such as
windows or pm terminals?
---
PM
|
|
From: Petr M. <mi...@ph...> - 2009-03-19 05:46:38
|
> Every now and then I build a binary of CVS gnuplot for win32 > (cross-building on Linux). The last time I did that was several > months ago, and the binary worked fine. I recently (2009-03-02) > updated and re-built. The new binary seemed OK at first, but now > I notice that it crashes whenever I try to use the "handle" > cursor to rotate a 3d plot in the windows terminal. I cannot reproduce this problem --- executable compiled by Mingw32 on Wine. --- PM |
|
From: Tatsuro M. <tma...@ya...> - 2009-03-19 02:48:41
|
Hello I have not met the problem that you met on my buid binaries on Msys+MINGW GCC-4.3.2-dw2-TDM. (windows XP.) I am distributing the binaries of gnuplot 4.3 (cvs) on my web site. http://www.tatsuromatsuoka.com/gnuplot/Eng/winbin/ Please download and check. If you have no trouble, problems perheps rely on the your build system. Regards Tatsuro --- Allin Cottrell wrote: > Every now and then I build a binary of CVS gnuplot for win32 > (cross-building on Linux). The last time I did that was several > months ago, and the binary worked fine. I recently (2009-03-02) > updated and re-built. The new binary seemed OK at first, but now > I notice that it crashes whenever I try to use the "handle" > cursor to rotate a 3d plot in the windows terminal. > > Debugging on Windows is not very convenient for me so I haven't > tried that yet. Does anyone happen to have an idea of what might > be wrong here? I've briefly scanned CVS, but a lot has gone on > lately so I couldn't isolate anything "suspicious". Thanks. > > -- > Allin Cottrell > Department of Economics > Wake Forest University > > > ------------------------------------------------------------------------------ > Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are > powering Web 2.0 with engaging, cross-platform capabilities. Quickly and > easily build your RIAs with Flex Builder, the Eclipse(TM)based development > software that enables intelligent coding and step-through debugging. > Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com > _______________________________________________ > gnuplot-beta mailing list > gnu...@li... > https://lists.sourceforge.net/lists/listinfo/gnuplot-beta > -------------------------------------- Power up the Internet with Yahoo! Toolbar. http://pr.mail.yahoo.co.jp/toolbar/ |
|
From: Tait <gnu...@t4...> - 2009-03-19 01:05:16
|
> ... The new binary seemed OK at first, but now > I notice that it crashes whenever I try to use the "handle" > cursor to rotate a 3d plot in the windows terminal. I also observed this behavior on release version 4.2.3. I isolated it (to pm3d? I forget) but it went away on release 4.2.4 so I never bothered pursuing it further. Maybe there's been a regression? Tait |
|
From: Allin C. <cot...@wf...> - 2009-03-18 23:36:57
|
On Thu, 19 Mar 2009, [ISO-8859-1] Hans-Bernhard Bröker wrote: > Allin Cottrell wrote: > > Every now and then I build a binary of CVS gnuplot for win32 > > (cross-building on Linux). > > Using which compiler and cross-build toolkit? Using mingw32-gcc (gcc 3.4.5). > > I notice that it crashes whenever I try to use the "handle" > > cursor to rotate a 3d plot in the windows terminal. > > FWIW I can't reproduce the problem with a binary built from > today's MKS, using the OpenWatcom compiler version 1.8 directly > on XP. I could rotate every single plot of 'surface1.dem' > without a hitch. Thanks, I'll try 'surface1.dem' and see what happens. Obviously I can't rule out the possibility that the problem lies with my build of gnuplot rather than the source code, although my builds have generally worked in the past. Allin Cottrell |
|
From: Allin C. <cot...@wf...> - 2009-03-18 23:32:34
|
On Wed, 18 Mar 2009, Ethan Merritt wrote: > On Wednesday 18 March 2009 14:25:52 Allin Cottrell wrote: > > Every now and then I build a binary of CVS gnuplot for win32 > > (cross-building on Linux). The last time I did that was several > > months ago, and the binary worked fine. I recently (2009-03-02) > > updated and re-built. The new binary seemed OK at first, but now > > I notice that it crashes whenever I try to use the "handle" > > cursor to rotate a 3d plot in the windows terminal. > > I see no Windows-specific changes since 7-Nov-2008, and that bunch > was supposed to be conditional on the configuration option > WGP_CONSOLE. It would help to know whether your previous > working version was built before or after that date. I think the previous version was built in August, 2008. > As to recent changes that would affect 3D in general, I see... Thanks very much for the listing. > Beyond that, the changes I notice mostly depend on the specific type of > plot. Could you check whether the problem is only present for a simple > line plot? +/- pm3d? With all axis labels and tick marks turned off? The plot in question doesn't use pm3d, but does use axis labels and tick marks. > Oh, one other annoying possibility... > Does it only happen when the executable is run under Windows? > I.e., if you run it in linux under Wine, does it still crash? I haven't tried under Wine, but I'll give that a go. Allin Cottrell |
|
From: Hans-Bernhard B. <HBB...@t-...> - 2009-03-18 23:10:15
|
Allin Cottrell wrote: > Every now and then I build a binary of CVS gnuplot for win32 > (cross-building on Linux). Using which compiler and cross-build toolkit? > I notice that it crashes whenever I try to use the "handle" > cursor to rotate a 3d plot in the windows terminal. FWIW I can't reproduce the problem with a binary built from today's MKS, using the OpenWatcom compiler version 1.8 directly on XP. I could rotate every single plot of 'surface1.dem' without a hitch. |
|
From: Ethan M. <merritt@u.washington.edu> - 2009-03-18 21:56:31
|
On Wednesday 18 March 2009 14:25:52 Allin Cottrell wrote:
> Every now and then I build a binary of CVS gnuplot for win32
> (cross-building on Linux). The last time I did that was several
> months ago, and the binary worked fine. I recently (2009-03-02)
> updated and re-built. The new binary seemed OK at first, but now
> I notice that it crashes whenever I try to use the "handle"
> cursor to rotate a 3d plot in the windows terminal.
I see no Windows-specific changes since 7-Nov-2008, and that bunch
was supposed to be conditional on the configuration option
WGP_CONSOLE. It would help to know whether your previous
working version was built before or after that date.
In fact, in all of 2008 I only see about 6 windows-specific
changes in ChangeLog, and most of those are both trivial and not
specific to 3D plots.
As to recent changes that would affect 3D in general, I see
2009-03-11 Ethan A Merritt <merritt@u.washington.edu>
* src/graph3d.c (do_3dplot): Define the clipping area in 3D plots to lie
between the left-most and right-most graph box edges. This is a change!
The intent is to allow the canvas terminal to use the plot's BoundingBox
as a zoom region. If it causes problems for other terminals, we will
need to create and use a separate BoundingBox for this purpose.
2009-01-07 Ethan Merritt <merritt@u.washington.edu>
* src/util3d.c (edge3d_intersect): Fix long-standing bug in which
the z coordinate was clipping against xmax rather than zmax.
Beyond that, the changes I notice mostly depend on the specific type of
plot. Could you check whether the problem is only present for a simple
line plot? +/- pm3d? With all axis labels and tick marks turned off?
Oh, one other annoying possibility...
Does it only happen when the executable is run under Windows?
I.e., if you run it in linux under Wine, does it still crash?
> Debugging on Windows is not very convenient for me so I haven't
> tried that yet. Does anyone happen to have an idea of what might
> be wrong here? I've briefly scanned CVS, but a lot has gone on
> lately so I couldn't isolate anything "suspicious". Thanks.
>
> --
> Allin Cottrell
> Department of Economics
> Wake Forest University
>
>
--
Ethan A Merritt
|
|
From: Allin C. <cot...@wf...> - 2009-03-18 21:26:03
|
Every now and then I build a binary of CVS gnuplot for win32 (cross-building on Linux). The last time I did that was several months ago, and the binary worked fine. I recently (2009-03-02) updated and re-built. The new binary seemed OK at first, but now I notice that it crashes whenever I try to use the "handle" cursor to rotate a 3d plot in the windows terminal. Debugging on Windows is not very convenient for me so I haven't tried that yet. Does anyone happen to have an idea of what might be wrong here? I've briefly scanned CVS, but a lot has gone on lately so I couldn't isolate anything "suspicious". Thanks. -- Allin Cottrell Department of Economics Wake Forest University |
|
From: Mojca M. <moj...@gm...> - 2009-03-17 11:02:29
|
On Tue, Mar 17, 2009 at 03:29, James R. Van Zandt wrote: > > Let me try again. Assuming this data file: > > # R I V > 2000 0.001000 2 > 2750 0.000727 2 > 3500 0.000571 2 > 4250 0.000471 2 > 5000 0.000400 2 > > > 2000 0.002500 5 > 2750 0.001818 5 > 3500 0.001429 5 > 4250 0.001176 5 > 5000 0.001000 5 > > > 2000 0.005000 10 > 2750 0.003636 10 > 3500 0.002857 10 > 4250 0.002353 10 > 5000 0.002000 10 > > I'd like to plot current as a function of resistance, with the title > for each curve giving the voltage. I understand your question, but if I had this kind of data, I would transform the data first into this form: # first column: R # header: I # data: V R 2 5 10 2000 0.001000 0.002500 0.005000 2750 0.000727 0.001818 0.003636 3500 0.000571 0.001429 0.002857 4250 0.000471 0.001176 0.002353 5000 0.000400 0.001000 0.002000 set key autotitle columnhead plot for [n=2:4] 'lab.dat' using 1:n (Nobody can guarantee that the label in each row is identical in your case.) Mojca |
|
From: James R. V. Z. <jr...@co...> - 2009-03-17 02:10:27
|
Ethan A Merritt wrote:
> On Sunday 15 March 2009, James R. Van Zandt wrote:
> >
...
> >
> > I would like to plot each datablock with its own title taken from the
> > third column. I can use
> >
> > plot for [n=0:3] 'lab.dat' in n title 3
> >
> > except that the first line of each datablock is not plotted.
>
> Of course it isn't. You have told the program that the first line
> contains labels, not data.
Right. But I would like a way to tell the program that the first line
contains data that I would *also* like to use for labels.
> > Maybe what I want is
> >
> > plot for [n=0:3] 'lab.dat' in n title datastring(3)
> >
> > but that isn't implemented?
>
> I don't know, because I don't quite understand what you are trying to do.
> How can every line of the data file contain a plot title?
I'm not necessarily plotting every datablock. But the significant
thing about a datablock I do plot is that it has a constant value in
the third column. So naturally I want to use that value for the
title.
> I could understand using each 3rd column value as a point symbol,
> or a color, or an xticlabel, etc, but it doesn't make sense to have
> multiple titles for the same plot.
No, just one title.
> Maybe you are over-thinking this? If that is really what your data file
> looks like, maybe you just want
>
> plot for [n=0:3] 'lab.dat' in n title sprintf("Data block %d",n)
No, because it's the parameter value rather than the block number that
is significant. In this particular case I could use
plot for [n=0:3] 'lab.dat' in n title sprintf("parameter = %d",n+2)
but that would not work if the parameter values were not linearly
spaced, and would have to be manually adjusted every time the
parameter values changed.
> > BTW my application is a simulation where several of the columns have
> > input parameters, and the rest of the columns have outputs. I can
> > plot one output as a function of two inputs using splot. However, to
> > make it possible to actually read values off the curves, I would like
> > to plot iso-<whatever> lines: output as a function of one input
> > parameter, for selected values of a second parameter, and all other
> > parameters held constant. It would be very helpful to get the curve
> > labels from the data file itself.
>
> Sorry, I still don't follow what you are aiming for.
> You are doing something to select coordinate pairs from a subset of
> lines in the file. OK. But whatever set you pick within a single "plot"
> command can have only one title, right?
Let me try again. Assuming this data file:
# R I V
2000 0.001000 2
2750 0.000727 2
3500 0.000571 2
4250 0.000471 2
5000 0.000400 2
2000 0.002500 5
2750 0.001818 5
3500 0.001429 5
4250 0.001176 5
5000 0.001000 5
2000 0.005000 10
2750 0.003636 10
3500 0.002857 10
4250 0.002353 10
5000 0.002000 10
I'd like to plot current as a function of resistance, with the title
for each curve giving the voltage.
- Jim Van Zandt
|
|
From: Petr M. <mi...@ph...> - 2009-03-16 22:37:43
|
In Windows, there is only one open and active graph window.
I think this could be the reason while mouse.c:event_keypress() reports
"protocol error" if you try e.g.:
bind 's' 'print "Hello";'
plot x*x
and then press "s" hotkey several times.
The code after
if (ptr->allwindows && ptr->command) {
is testing "allwindows" and "active" windows but it could somehow miss that
case of a single-window graph. I'm not sure what should be the correct fix
among these several if .. else if ...
---
PM
|
|
From: Ethan A M. <merritt@u.washington.edu> - 2009-03-16 04:35:58
|
On Sunday 15 March 2009, James R. Van Zandt wrote:
>
> Ethan Merritt wrote:
> > On Thursday 12 March 2009, Juergen Wieferink wrote:
> > I have [...] modified the parsing code, which now accepts:
> > plot ... title columnheader
> > plot ... title columnheader(N)
> > The option is now handled by the normal title parsing code, so there is
> > no strangeness with the order of title options on the command line.
> >
> > The original form of the command, which was never documented but was
> > used in several of the demos, is now deprecated. However it still works
> > if you ./configure --enable-backwards-compatibility
> > Thus
> > plot ... using 1 title 1
> > should be re-written using any of the following:
> > plot ... using 1 title col
> > plot ... using 1 title columnhead(1)
> > set key autotitle columnhead
> > plot ... using 1
>
> Suppose I have data that looks like this:
>
> 1.000000 2.000000 2.000000
> 2.000000 1.000000 2.000000
> 3.000000 0.666667 2.000000
> 4.000000 0.500000 2.000000
>
>
> 1.000000 3.000000 3.000000
> 2.000000 1.500000 3.000000
> 3.000000 1.000000 3.000000
> 4.000000 0.750000 3.000000
>
>
> 1.000000 4.000000 4.000000
> 2.000000 2.000000 4.000000
> 3.000000 1.333333 4.000000
> 4.000000 1.000000 4.000000
> ...
>
> I would like to plot each datablock with its own title taken from the
> third column. I can use
>
> plot for [n=0:3] 'lab.dat' in n title 3
>
> except that the first line of each datablock is not plotted.
Of course it isn't. You have told the program that the first line
contains labels, not data.
> Maybe what I want is
>
> plot for [n=0:3] 'lab.dat' in n title datastring(3)
>
> but that isn't implemented?
I don't know, because I don't quite understand what you are trying to do.
How can every line of the data file contain a plot title?
I could understand using each 3rd column value as a point symbol,
or a color, or an xticlabel, etc, but it doesn't make sense to have
multiple titles for the same plot.
Maybe you are over-thinking this? If that is really what your data file
looks like, maybe you just want
plot for [n=0:3] 'lab.dat' in n title sprintf("Data block %d",n)
Ethan
>
> BTW my application is a simulation where several of the columns have
> input parameters, and the rest of the columns have outputs. I can
> plot one output as a function of two inputs using splot. However, to
> make it possible to actually read values off the curves, I would like
> to plot iso-<whatever> lines: output as a function of one input
> parameter, for selected values of a second parameter, and all other
> parameters held constant. It would be very helpful to get the curve
> labels from the data file itself.
Sorry, I still don't follow what you are aiming for.
You are doing something to select coordinate pairs from a subset of
lines in the file. OK. But whatever set you pick within a single "plot"
command can have only one title, right?
> - Jim Van Zandt
>
|
|
From: James R. V. Z. <jr...@co...> - 2009-03-16 02:16:18
|
Ethan Merritt wrote:
> On Thursday 12 March 2009, Juergen Wieferink wrote:
> I have [...] modified the parsing code, which now accepts:
> plot ... title columnheader
> plot ... title columnheader(N)
> The option is now handled by the normal title parsing code, so there is
> no strangeness with the order of title options on the command line.
>
> The original form of the command, which was never documented but was
> used in several of the demos, is now deprecated. However it still works
> if you ./configure --enable-backwards-compatibility
> Thus
> plot ... using 1 title 1
> should be re-written using any of the following:
> plot ... using 1 title col
> plot ... using 1 title columnhead(1)
> set key autotitle columnhead
> plot ... using 1
Suppose I have data that looks like this:
1.000000 2.000000 2.000000
2.000000 1.000000 2.000000
3.000000 0.666667 2.000000
4.000000 0.500000 2.000000
1.000000 3.000000 3.000000
2.000000 1.500000 3.000000
3.000000 1.000000 3.000000
4.000000 0.750000 3.000000
1.000000 4.000000 4.000000
2.000000 2.000000 4.000000
3.000000 1.333333 4.000000
4.000000 1.000000 4.000000
...
I would like to plot each datablock with its own title taken from the
third column. I can use
plot for [n=0:3] 'lab.dat' in n title 3
except that the first line of each datablock is not plotted.
Maybe what I want is
plot for [n=0:3] 'lab.dat' in n title datastring(3)
but that isn't implemented?
BTW my application is a simulation where several of the columns have
input parameters, and the rest of the columns have outputs. I can
plot one output as a function of two inputs using splot. However, to
make it possible to actually read values off the curves, I would like
to plot iso-<whatever> lines: output as a function of one input
parameter, for selected values of a second parameter, and all other
parameters held constant. It would be very helpful to get the curve
labels from the data file itself.
- Jim Van Zandt
|
|
From: Ethan A M. <merritt@u.washington.edu> - 2009-03-15 05:04:40
|
Barring last minute bug reports, I plan to push out version 4.2.5
in a few days. It contains a dozen or so bug-fixes and a few
features back-ported from CVS. The biggest change is support for
linking against BSD libedit, providing a third alternative to the
built-in readline code and to gnu libreadline.
This should help installation under OSX.
I have updated the patchlevel and internal version references in CVS,
but have not yet tagged it for release.
If you can think of any reason to delay it, or have recently happened
across a long-standing bug [*], please let me know.
[*] Don't laugh. I stubbed my toe on one just this evening:
set view map; set pm3d; splot {0,1};
hung both 4.2 and 4.3.
--
Ethan A Merritt
|
|
From: Ethan M. <merritt@u.washington.edu> - 2009-03-13 16:35:12
|
On Friday 13 March 2009 03:09:16 Mojca Miklavec wrote:
> On Thu, Mar 12, 2009 at 06:52, Ethan A Merritt wrote:
> > On Wednesday 11 March 2009, Mojca Miklavec wrote:
> >
> >> Also, I miss a bit two things. The first one being something like
> >> set format title "$a=%.2f$"
> >> or some other way to transform title.
> >>
> >> Let's say that legend (first line in data file) looks like
> >> 0.001 0.1 1 1.5 2 2.5
> >> and that I want to use the third to sixth column and generate
> >> $a=1,0$ $a=1,5$ $a=2,0$ $a=2,5$
> >> as the title for some LaTeX terminal. I know that I can change the
> >> label myself, but I cannot control the data and should make copies of
> >> it first. I got used to be able to change
> >> set format y
> >> so much that I sometimes want to misuse way it above its limits.
> >
> > Sorry, I didn't understand that. Could you try again?
>
> I would like to do something like this, but with datafiles:
> plot [0:1] for[n=1:4] sin(n*x/pi) t sprintf("sin(%dx)", n)
>
> Let's say that my data looks like this:
>
> # this is header
> 0 0.5 1 1.5 2
> # this is data
> ...
The only thing I can think of is
set key title "sin(ax) for a ="
set key autotitle columnhead
> I didn't recompile gnuplot with your most recent modifications, so
> maybe the behaviour is different now, but with older gnuplot trying to
> use
> plot for[n=1:5] "data.dat" using n t sprintf("$%.1f\\pi$", column(n))
No. That has never worked, and was never intended to work.
The function column(n), if it were legal at all in this context,
would be called for every line of data, which makes no sense.
> as an equivalent of
> # a command to ignore the first row should come here first
> plot \
> "data.dat" using 1 t '$0.0\pi$',\
> "data.dat" using 2 t '$0.5\pi$',\
> "data.dat" using 3 t '$1.0\pi$',\
> "data.dat" using 4 t '$1.5\pi$',\
> "data.dat" using 5 t '$2.0\pi$'
> didn't work.
>
> In gnuplot I often use syntax
> set logscale y
> set format y "$10^{%T}$"
> in order to print 10^1, 10^2, 10^3 on y axis (in LaTeX/ConTeXt) or
> (double misuse, I'm referring to "set format x"):
> set format x "$%.1f\\pi$"
> plot [0:2] for[n=1:4] sin(n*x*pi) t sprintf("sin(%dx)", n)
> to print 0.0π, 0.5π, 1.0π, 1.5π, 2.0π on x axis (that's hopefully
> unicode "pi" in case that mail agents have probems with it).
>
> So I would imagine that something like
> set key autotitle columnhead format "$%.1f\\pi$"
> plot for[n=1:5] "data.dat" using n
> could do the dirty trick.
>
> But I would be happy enough to have
> plot for[n=1:5] "data.dat" using n t sprintf("$%.1f\\pi$", column(n))
> working.
Nope. sorry. There is no way to do that.
The plot title and other titles and labels are simply strings, not format
statements. There is a reason why the one command is 'set format', while the
other commands are 'set title' or 'set label'.
--
Ethan A Merritt
|
|
From: Ethan M. <merritt@u.washington.edu> - 2009-03-13 16:26:18
|
On Friday 13 March 2009 02:01:48 Mojca Miklavec wrote: > One more tiny question from a dumb user. Let's assume that the data > has a title row, like this: > > # first column is quarter, second and third are data for specific year > # zero is just a placeholder > # this is header > 0 2000 2001 > # this is data > 1 50 55 > 2 15 30 > 3 20 40 > 4 30 53 > > I can now say > plot for[n=2:3] "data.dat" using 1:n title columnhead > which triggers the first row in data to be handled as header. What if > I want that header line to be simply ignored? > The command > unset key > plot for[n=2:3] "data.dat" using 1:n > alone will treat the first row as part of data. > > I didn't try it, but I guess that > unset key autotitle columnhead > doesn't work as such :) :) :) You still haven't explained what you would like the result to be. Do you not want a key at all? unset key plot .... Do you want a key, but have this particular column omitted from the key? set key autotitle columnheader plot foo using 2 notitle, '' using 3 notitle > Maybe > set key autotitle columnhead > plot for[n=2:3] "data.dat" using 1:n notitle > ? But I still hope that there's a some better option. Better in what way? If that is what you want, how else would you specify it? Or maybe the whole issue of plot titles is not relevant... Are you asking how to skip the first line of a data file? plot '< tail +2 file.dat' .... Or maybe: plot 'file.dat' every ::2 using ... -- Ethan A Merritt |
|
From: Mojca M. <moj...@gm...> - 2009-03-13 10:09:24
|
On Thu, Mar 12, 2009 at 06:52, Ethan A Merritt wrote:
> On Wednesday 11 March 2009, Mojca Miklavec wrote:
>
>> Also, I miss a bit two things. The first one being something like
>> set format title "$a=%.2f$"
>> or some other way to transform title.
>>
>> Let's say that legend (first line in data file) looks like
>> 0.001 0.1 1 1.5 2 2.5
>> and that I want to use the third to sixth column and generate
>> $a=1,0$ $a=1,5$ $a=2,0$ $a=2,5$
>> as the title for some LaTeX terminal. I know that I can change the
>> label myself, but I cannot control the data and should make copies of
>> it first. I got used to be able to change
>> set format y
>> so much that I sometimes want to misuse way it above its limits.
>
> Sorry, I didn't understand that. Could you try again?
I would like to do something like this, but with datafiles:
plot [0:1] for[n=1:4] sin(n*x/pi) t sprintf("sin(%dx)", n)
Let's say that my data looks like this:
# this is header
0 0.5 1 1.5 2
# this is data
...
I didn't recompile gnuplot with your most recent modifications, so
maybe the behaviour is different now, but with older gnuplot trying to
use
plot for[n=1:5] "data.dat" using n t sprintf("$%.1f\\pi$", column(n))
as an equivalent of
# a command to ignore the first row should come here first
plot \
"data.dat" using 1 t '$0.0\pi$',\
"data.dat" using 2 t '$0.5\pi$',\
"data.dat" using 3 t '$1.0\pi$',\
"data.dat" using 4 t '$1.5\pi$',\
"data.dat" using 5 t '$2.0\pi$'
didn't work.
In gnuplot I often use syntax
set logscale y
set format y "$10^{%T}$"
in order to print 10^1, 10^2, 10^3 on y axis (in LaTeX/ConTeXt) or
(double misuse, I'm referring to "set format x"):
set format x "$%.1f\\pi$"
plot [0:2] for[n=1:4] sin(n*x*pi) t sprintf("sin(%dx)", n)
to print 0.0π, 0.5π, 1.0π, 1.5π, 2.0π on x axis (that's hopefully
unicode "pi" in case that mail agents have probems with it).
So I would imagine that something like
set key autotitle columnhead format "$%.1f\\pi$"
plot for[n=1:5] "data.dat" using n
could do the dirty trick.
But I would be happy enough to have
plot for[n=1:5] "data.dat" using n t sprintf("$%.1f\\pi$", column(n))
working.
> Are you talking about the plot title, the key entries, tick labels, or what?
> Anyhow, I suspect the answer in no, there is no way to do that.
>> The second question: is there a way to say something like
>> for [n=2:4,6,8:20,25,30:40]
>> ? (I know that I can construct it myself from several commands, but
>> the for loop is really practical for long expressions that repeat
>> themselves anyway.)
>
> That you can do:
>
> for [i in "2 4 6 8 9 10..."]
>
> Although this is a string, so long as the component 'words' are
> pure numbers the code should auto-convert back to integers when needed.
> This feature has not been extensively tested, I suspenct.
> So if you have problems, please complain.
Wow! Great, thanks a lot. I didn't know that it can work that way.
I'll test and report in case of problems.
Mojca
|
|
From: Mojca M. <moj...@gm...> - 2009-03-13 09:01:51
|
On Fri, Mar 13, 2009 at 06:23, Ethan A Merritt wrote:
>
> I have so modified the parsing code, which now accepts:
> plot ... title columnheader
> plot ... title columnheader(N)
> The option is now handled by the normal title parsing code, so there is
> no strangeness with the order of title options on the command line.
>
> The original form of the command, which was never documented but was
> used in several of the demos, is now deprecated. However it still works
> if you ./configure --enable-backwards-compatibility
> Thus
> plot ... using 1 title 1
> should be re-written using any of the following:
> plot ... using 1 title col
> plot ... using 1 title columnhead(1)
> set key autotitle columnhead
> plot ... using 1
>
> The change leaves one chunk of dead code in df_open() that looks like it
> used to handle some exceptional case, but can now never be reached.
> This may mean that the exceptional case is now broken, but I haven't
> been able to work out what it was :-/ Oh well.
Hello,
First - thanks a lot for clearing it up.
One more tiny question from a dumb user. Let's assume that the data
has a title row, like this:
# first column is quarter, second and third are data for specific year
# zero is just a placeholder
# this is header
0 2000 2001
# this is data
1 50 55
2 15 30
3 20 40
4 30 53
I can now say
plot for[n=2:3] "data.dat" using 1:n title columnhead
which triggers the first row in data to be handled as header. What if
I want that header line to be simply ignored?
The command
unset key
plot for[n=2:3] "data.dat" using 1:n
alone will treat the first row as part of data.
I didn't try it, but I guess that
unset key autotitle columnhead
doesn't work as such :) :) :)
Maybe
set key autotitle columnhead
plot for[n=2:3] "data.dat" using 1:n notitle
? But I still hope that there's a some better option.
Thanks a lot,
Mojca
|
|
From: Ethan A M. <merritt@u.washington.edu> - 2009-03-13 05:23:24
|
On Thursday 12 March 2009, Juergen Wieferink wrote:
> Am Donnerstag, 12. März 2009 schrieb Ethan A Merritt:
> > On Wednesday 11 March 2009, Mojca Miklavec wrote:
> > > One more question. I know that the order of reading parameters is a
> > > pretty sensitive issue in gnuplot, but it nevertheless confused me
> > > that
> > > plot for [n=2:5] 'data.dat' using 1:n title column with lines
> > > plot for [n=2:5] 'data.dat' using 1:n with lines title "something"
> > > both work while
> > > plot for [n=2:5] 'data.dat' using 1:n with lines title column
> > > fails. Is that behaviour "compatible" with previous and future
> > > versions of gnuplot?
> >
> > It is all part of the same problem. The code that implements the
> > 'using ... title column(foo)' option is an ugly hack.
> > It is a known bug, and has been on the list of things to fix for a long
> > time.
> >
> > The reason it persists as a sore point rather than being fixed
> > immediately is that in order to work properly it needs information that
> > is only visible inside the datafile.c routines, whereas normally command
> > options are parsed elsewhere. To fix it we will have to rearrange the
> > code, and/or introduce new global variables, etc.
>
> One option would be to put the parsing code into a separate function
> in datafile.c which is called on a keyword not known within
> plot?d.c. Though I suspect that this would not be too easy. I do
> not know how to set the default title then.
You are right. It can be done that way.
I have so modified the parsing code, which now accepts:
plot ... title columnheader
plot ... title columnheader(N)
The option is now handled by the normal title parsing code, so there is
no strangeness with the order of title options on the command line.
The original form of the command, which was never documented but was
used in several of the demos, is now deprecated. However it still works
if you ./configure --enable-backwards-compatibility
Thus
plot ... using 1 title 1
should be re-written using any of the following:
plot ... using 1 title col
plot ... using 1 title columnhead(1)
set key autotitle columnhead
plot ... using 1
The change leaves one chunk of dead code in df_open() that looks like it
used to handle some exceptional case, but can now never be reached.
This may mean that the exceptional case is now broken, but I haven't
been able to work out what it was :-/ Oh well.
--
Ethan A Merritt
|
|
From: Juergen W. <wie...@fr...> - 2009-03-12 08:17:00
|
Am Donnerstag, 12. März 2009 schrieb Ethan A Merritt: > On Wednesday 11 March 2009, Mojca Miklavec wrote: > > One more question. I know that the order of reading parameters is a > > pretty sensitive issue in gnuplot, but it nevertheless confused me > > that > > plot for [n=2:5] 'data.dat' using 1:n title column with lines > > plot for [n=2:5] 'data.dat' using 1:n with lines title "something" > > both work while > > plot for [n=2:5] 'data.dat' using 1:n with lines title column > > fails. Is that behaviour "compatible" with previous and future > > versions of gnuplot? > > It is all part of the same problem. The code that implements the > 'using ... title column(foo)' option is an ugly hack. > It is a known bug, and has been on the list of things to fix for a long > time. > > The reason it persists as a sore point rather than being fixed > immediately is that in order to work properly it needs information that > is only visible inside the datafile.c routines, whereas normally command > options are parsed elsewhere. To fix it we will have to rearrange the > code, and/or introduce new global variables, etc. One option would be to put the parsing code into a separate function in datafile.c which is called on a keyword not known within plot?d.c. Though I suspect that this would not be too easy. I do not know how to set the default title then. That said, I think it would have been a good idea to name the title option in datafile.c something like "autot$itle". Juergen |
|
From: Ethan A M. <merritt@u.washington.edu> - 2009-03-12 05:53:06
|
On Wednesday 11 March 2009, Mojca Miklavec wrote: > On Mon, Mar 9, 2009 at 17:46, Juergen Wieferink wrote: > > > >> May I request adding a simple example like this (using for loop and > >> "title column()") to > >> http://gnuplot.sourceforge.net/demo/datastrings.html > >> ? > > > > From the code, > > > > plot ... title column(<int expr>) > > > > does more or less the same as > > > > plot ... title <int const> > > > > The command > > > > plot ... title column > > > > without following "(" tries to guess which column to fetch data > > from, which in this case might be exactly what you want. I do not > > like that "column" has two different meanings. > > > > As soon as it is documented or in the demos, this can never be > > changed. > > One more question. I know that the order of reading parameters is a > pretty sensitive issue in gnuplot, but it nevertheless confused me > that > plot for [n=2:5] 'data.dat' using 1:n title column with lines > plot for [n=2:5] 'data.dat' using 1:n with lines title "something" > both work while > plot for [n=2:5] 'data.dat' using 1:n with lines title column > fails. Is that behaviour "compatible" with previous and future > versions of gnuplot? It is all part of the same problem. The code that implements the 'using ... title column(foo)' option is an ugly hack. It is a known bug, and has been on the list of things to fix for a long time. The reason it persists as a sore point rather than being fixed immediately is that in order to work properly it needs information that is only visible inside the datafile.c routines, whereas normally command options are parsed elsewhere. To fix it we will have to rearrange the code, and/or introduce new global variables, etc. > Also, I miss a bit two things. The first one being something like > set format title "$a=%.2f$" > or some other way to transform title. > > Let's say that legend (first line in data file) looks like > 0.001 0.1 1 1.5 2 2.5 > and that I want to use the third to sixth column and generate > $a=1,0$ $a=1,5$ $a=2,0$ $a=2,5$ > as the title for some LaTeX terminal. I know that I can change the > label myself, but I cannot control the data and should make copies of > it first. I got used to be able to change > set format y > so much that I sometimes want to misuse way it above its limits. Sorry, I didn't understand that. Could you try again? Are you talking about the plot title, the key entries, tick labels, or what? Anyhow, I suspect the answer in no, there is no way to do that. > The second question: is there a way to say something like > for [n=2:4,6,8:20,25,30:40] > ? (I know that I can construct it myself from several commands, but > the for loop is really practical for long expressions that repeat > themselves anyway.) That you can do: for [i in "2 4 6 8 9 10..."] Although this is a string, so long as the component 'words' are pure numbers the code should auto-convert back to integers when needed. This feature has not been extensively tested, I suspenct. So if you have problems, please complain. > Thanks a lot, > Mojca > > ------------------------------------------------------------------------------ > Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are > powering Web 2.0 with engaging, cross-platform capabilities. Quickly and > easily build your RIAs with Flex Builder, the Eclipse(TM)based development > software that enables intelligent coding and step-through debugging. > Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com > _______________________________________________ > gnuplot-beta mailing list > gnu...@li... > https://lists.sourceforge.net/lists/listinfo/gnuplot-beta > -- Ethan A Merritt Biomolecular Structure Center University of Washington, Seattle 98195-7742 |
|
From: Mojca M. <moj...@gm...> - 2009-03-12 05:23:56
|
On Mon, Mar 9, 2009 at 17:46, Juergen Wieferink wrote: > >> May I request adding a simple example like this (using for loop and >> "title column()") to >> http://gnuplot.sourceforge.net/demo/datastrings.html >> ? > > From the code, > > plot ... title column(<int expr>) > > does more or less the same as > > plot ... title <int const> > > The command > > plot ... title column > > without following "(" tries to guess which column to fetch data > from, which in this case might be exactly what you want. I do not > like that "column" has two different meanings. > > As soon as it is documented or in the demos, this can never be > changed. One more question. I know that the order of reading parameters is a pretty sensitive issue in gnuplot, but it nevertheless confused me that plot for [n=2:5] 'data.dat' using 1:n title column with lines plot for [n=2:5] 'data.dat' using 1:n with lines title "something" both work while plot for [n=2:5] 'data.dat' using 1:n with lines title column fails. Is that behaviour "compatible" with previous and future versions of gnuplot? Also, I miss a bit two things. The first one being something like set format title "$a=%.2f$" or some other way to transform title. Let's say that legend (first line in data file) looks like 0.001 0.1 1 1.5 2 2.5 and that I want to use the third to sixth column and generate $a=1,0$ $a=1,5$ $a=2,0$ $a=2,5$ as the title for some LaTeX terminal. I know that I can change the label myself, but I cannot control the data and should make copies of it first. I got used to be able to change set format y so much that I sometimes want to misuse way it above its limits. The second question: is there a way to say something like for [n=2:4,6,8:20,25,30:40] ? (I know that I can construct it myself from several commands, but the for loop is really practical for long expressions that repeat themselves anyway.) Thanks a lot, Mojca |