gnuplot-bugs — Place to submit bug reports on gnuplot

Re: [Gnuplot-bugs] Gnuplot 4.0 Win32 crashes on plot from file

[Hans-Bernhard B. <br...@ph...>]

On Tue, 1 Jun 2004, Uwe Zimmermann wrote:

[...]
> plot          \
>      '030910alogg.csv' \
>         every 1:::0::0 \
>         using ($1<4700? $1/60.0-60.0:1/0):($2) \
>           '"%*[^"]",%lf,%lf,"%*[^"]",%lf,%lf,"%*[^"]",%lf,%lf'\

That's 6 %lf specifiers...

> but adding another column to the format specifier crashes Gnuplot on
> Win32 (WinXP sp1+updates):
[...]
>    "%*[^"]",%lf,%lf,"%*[^"]",%lf,%lf,"%*[^"]",%lf,%lf,"%*[^"]",%lf,%lf'\

Now it's 8 %lf specifiers, and that's the cause of the problem.  None of
gnuplot's plot styles uses more than 7 'using' specifiers, so the format
string isn't expected to contain more than 7 instances of %lf.  You should
replace the %lf for those columns you aren't going to actually use by
%*lf, which parses a number but then ignores it.

So the real bugs are two-fold: this limitation should be documented in
'help using', and exceeding the limit should yield an error message rather
than crash gnuplot.  I'll see how this can be fixed.

> Earlier I was able to plot this same datafile with GnuPlot 3.7x where
> the column separator could be redefined to be a comma instead of a
> whitespace...

You're mixing up versions here, I think.  I'm quite positive none of the
officially released 3.7x versions had such an option; i.e. yours must have
been a modified one.  gnuplot 4.0, OTOH, does have this option.  See "help
separator".

-- 
Hans-Bernhard Broeker (br...@ph...)
Even if all the snow were burnt, ashes would remain.

[Gnuplot-bugs] Gnuplot 4.0 Win32 crashes on plot from file

[Uwe Z. <uw...@kt...>]

Gnuplot 3.8i and 4.0 both crash while plotting a data file using a
format specifier on a data file. The data file has 21 comma separated
columns where every third column is a text formated date (which I
ignore):

#101(Time stamp),101(Seconds),101(C),102(Time stamp),102(Seconds),102(C),103(Time stamp),103(Seconds),103(C),104(Time stamp),104(Seconds),104(C),105(Time stamp),105(Seconds),105(C),106(Time stamp),106(Seconds),106(C),107(Time stamp),107(Seconds),107(C)
"2003-09-10 12:14:43.748",0.019,+2.448500E+01,"2003-09-10 12:14:43.968",0.239,+1.652400E+01,"2003-09-10 12:14:44.178",0.449,+1.645500E+01,"2003-09-10 12:14:44.387",0.658,+1.638900E+01,"2003-09-10 12:14:44.597",0.868,+1.633000E+01,"2003-09-10 12:14:44.807",1.078,+1.624000E+01,"2003-09-10 12:14:45.616",1.887,+1.617400E+01
"2003-09-10 12:14:46.733",3.004,+2.448600E+01,"2003-09-10 12:14:46.953",3.224,+1.652200E+01,"2003-09-10 12:14:47.162",3.433,+1.645900E+01,"2003-09-10 12:14:47.372",3.643,+1.639300E+01,"2003-09-10 12:14:47.581",3.852,+1.633100E+01,"2003-09-10 12:14:47.791",4.062,+1.623100E+01,"2003-09-10 12:14:48.601",4.872,+1.618800E+01
"2003-09-10 12:14:49.733",6.004,+2.448700E+01,"2003-09-10 12:14:49.953",6.224,+1.651800E+01,"2003-09-10 12:14:50.162",6.433,+1.645300E+01,"2003-09-10 12:14:50.372",6.643,+1.638700E+01,"2003-09-10 12:14:50.582",6.853,+1.632200E+01,"2003-09-10 12:14:50.791",7.062,+1.623400E+01,"2003-09-10 12:14:51.601",7.872,+1.618400E+01


a minimum sample which still works:
------------------------
reset
set nologscale y

set xrange [-20:20]
set autoscale y

plot          \
     '030910alogg.csv' \
        every 1:::0::0 \
        using ($1<4700? $1/60.0-60.0:1/0):($2) '"%*[^"]",%lf,%lf,"%*[^"]",%lf,%lf,"%*[^"]",%lf,%lf'\
        axes x1y1 \
        title 'center temp.' \
        with lines linewidth 4 \
    ;
------------------------

but adding another column to the format specifier crashes Gnuplot on
Win32 (WinXP sp1+updates):


------------------------
reset
set nologscale y

set xrange [-20:20]
set autoscale y

plot          \
     '030910alogg.csv' \
        every 1:::0::0 \
        using ($1<4700? $1/60.0-60.0:1/0):($2) '"%*[^"]",%lf,%lf,"%*[^"]",%lf,%lf,"%*[^"]",%lf,%lf,"%*[^"]",%lf,%lf'\
        axes x1y1 \
        title 'center temp.' \
        with lines linewidth 4 \
    ;
------------------------

...independently on which pair of columns I select to read.

Earlier I was able to plot this same datafile with GnuPlot 3.7x where
the column separator could be redefined to be a comma instead of a
whitespace...

Any ideas?

   Uwe.

Re: [Gnuplot-bugs] why i cannot draw the file m10

[Hans-Bernhard B. <br...@ph...>]

On Thu, 27 May 2004, Elisabeth Ressayre wrote:

> In the attached file m10_bis, I explain my problem to draw the file m10.

[It would have been more helpful to keep the explanation in the mail body,
and only the data file in the attachment.]

The root of this problem is that the y range of your data is degenerate.  
All the y values are the same, within a *very* small error margin, way
down close to the technical limit of what a double-precision floating
point number can represent (1 +/- n * DBL_EPS, for small integer 'n').

gnuplot's automatic tic step sizing algorithm fails, this close to the
boundary.  As a workaround, you could remove the constant 1.0 from the
data before plotting:

	plot 'datafile' u 1:($2-1.0)


-- 
Hans-Bernhard Broeker (br...@ph...)
Even if all the snow were burnt, ashes would remain.

[Gnuplot-bugs] why i cannot draw the file m10

[Elisabeth R. <Eli...@pp...>]

In the attached file m10_bis, I explain my problem to draw the file m10.
Thank you in advance
E. Ressayre=20

[Gnuplot-bugs] Unexpected behavior when using more than one palette

[Lutz M. <ma...@uc...>]

I encountered the following (to me) surprising behavior with gnuplot 4.0. Take 
the following snippet:

set multiplot
set size 0.5,1
set pm3d map
set palette gray
set origin 0,0
set palette defined ( 0 "black", 1 "white" )
splot x**2+y**2
set origin 0.5,0
set palette defined ( 0 "white", 1 "black" )
splot x**2+y**2
unset multiplot

and put it into a file, say, test.gp. Running this script in a gnuplot session 
under X I get two graphs where "white" corresponds to zero on the z-axis, 
i.e., the second "set palette" command affected not only the second, but also 
the first plot. Similarly, using the postscript terminal, both plots range 
from black for z=0 to white for z=200. This is unexpected, because...

a) I think that my X (running at 16 bit depth), and certainly postscript, do 
not run out of available colors, and

b) the second plot doesn't need more colors than the first one anyways, since 
they both require only shades of gray.

Is there any other way to reverse the color range between to graphs in the 
same plot? I tried various combinations of
	set cbrange [0:200]
	set cbrange [0:200] reverse
	set cbrange [200:0]
for the second plot, but none of them gave the desired result.

As in interesting side node, if first execute in a fresh gnuplot session
	load 'test.gp'
and then, after closing the appearing X window,
	set term post; set outp 'test.ps'; load 'test.gp'; set outp
the resulting postscript file "test.ps" contains only one graph. I don't 
understand why that might be.

  Lutz

[Gnuplot-bugs] Re: <a name=...' problem in docs/doc2texi.el

[Shigeharu T. <sh...@ie...>]

shige 05/14 2004
----------------

I found a problem below:

> shige 04/30 2004
> ----------------
> 
> I found a problem in docs/doc2texi.el. This deals with some HTML 
> tag lines started by '^' in gnuplot.doc, but it has no code for 
> "^ <a name=..." tag lines which exist in gnuplot.doc. So, .texi
> file made by it has raw "^ <a name=..." lines.

The following small patch may fix it.

----- From here -----
*** docs/doc2texi.el.ORG	Sun Apr 11 07:55:00 2004
--- docs/doc2texi.el	Fri May 14 14:46:13 2004
***************
*** 769,775 ****
  					 ","
  					 (remove* ?^ (match-string 2)
  						  :test 'char-equal)
! 					 "}"))))
  	     ;; translate <ul> </ul> to @itemize environment
  	     ((and (string= bracket "<") (string-match "^ul" tag))
  	      (delete-region (point) eol)
--- 769,777 ----
  					 ","
  					 (remove* ?^ (match-string 2)
  						  :test 'char-equal)
! 					 "}"))
! 		(insert "@c "))
! 	      )
  	     ;; translate <ul> </ul> to @itemize environment
  	     ((and (string= bracket "<") (string-match "^ul" tag))
  	      (delete-region (point) eol)
----- To here -----

+========================================================+
 Shigeharu TAKENO     NIigata Institute of Technology
                       kashiwazaki,Niigata 945-1195 JAPAN
 sh...@ie...   TEL(&FAX): +81-257-22-8161
+========================================================+

Re: [Gnuplot-bugs] Is it a bug?

[Hans-Bernhard B. <br...@ph...>]

On Tue, 11 May 2004, Hans-Bernhard Broeker wrote:

> On Tue, 11 May 2004, VTs (Vadim Z. Tsalyuk) wrote:
> 
> > I have found that 'set arrow... size...' do not work in size.
> > set arrow 2 to 0,2.0 size 100,30 filled ls 2
> > does the same that 
> > set arrow 2 to 0,2.0 size 0.2,30 filled ls 2
> > does. 
> 
> Which terminal driver?  At least version 4.0.0 on both X11 and PostScript
> shows a considerable difference in behaviour between these two settings.

Oh, blast.  Forget I ever wrote that.  Your script showed you're using
epslatex as your terminal driver.  Which doesn't support customized arrow
heads.

-- 
Hans-Bernhard Broeker (br...@ph...)
Even if all the snow were burnt, ashes would remain.

Re: [Gnuplot-bugs] Is it a bug?

[Hans-Bernhard B. <br...@ph...>]

On Tue, 11 May 2004, VTs (Vadim Z. Tsalyuk) wrote:

> I have found that 'set arrow... size...' do not work in size.
> set arrow 2 to 0,2.0 size 100,30 filled ls 2
> does the same that 
> set arrow 2 to 0,2.0 size 0.2,30 filled ls 2
> does. 

Which terminal driver?  At least version 4.0.0 on both X11 and PostScript
shows a considerable difference in behaviour between these two settings.

-- 
Hans-Bernhard Broeker (br...@ph...)
Even if all the snow were burnt, ashes would remain.

[Gnuplot-bugs] Is it a bug?

[VTs \(V. Z. Tsalyuk\) <vt...@ma...>]

I have found that 'set arrow... size...' do not work in size.
set arrow 2 to 0,2.0 size 100,30 filled ls 2
does the same that 
set arrow 2 to 0,2.0 size 0.2,30 filled ls 2
does. The full text is attached.
I have MS Win32 (98 or XP), PS installed is AFPL Ghostscript 7.03.

   VTs (Vadim Z. Tsalyuk)
http://public.kubsu.ru/vts
E-mail:  vt...@ma...

Re: [Gnuplot-bugs] gnuplot info missing information

[Hans-Bernhard B. <br...@ph...>]

On Sun, 2 May 2004, [iso-8859-2] Karel Kulhav=FD wrote:

> info gnuplot
> Commands
> "on-line versions may not be complete."
>=20
> There is missing an information where an online document with compl=
ete
> list of the gnuplot commands can be obtained.

It says that right in the same sentence, exactly before the fragment
you quote: "printed versions contain all commands".  That obviously
includes all printable formats, e.g. the .ps one we distribute right
on our main web sites.

> For example I have been seeking information on usage of the "set" c=
ommand
> and it is missing in this chanpter. The chapter is obviously not co=
mplete.

'info' files don't have "chapters", so I don't think I know what you'=
re
talking about.  There's a node "set-show" right there in the "command=
s"
node you already found.  "set" and "show" share a node because they'r=
e
discussed together, in each individual setting.

--=20
Hans-Bernhard Broeker (br...@ph...)
Even if all the snow were burnt, ashes would remain.

Re: [Gnuplot-bugs] info set grid missing reference

[Hans-Bernhard B. <br...@ph...>]

On Sun, 2 May 2004, [iso-8859-2] Karel Kulhav=FD wrote:

> Hello
>=20
> info gnuplot
> ctrl+s set grid ctrl+s ctrl+s

A side note: gnuplot.info has an index, so typing 'igrid' and
then <Return> would have got you there faster and easier...

> This chapter "grid" operates with some "major_linestyle"
> (for example in the syntax, linestyle <major_linestyle>) but lacks
> a definition of what it is (it clearly may not be anything,
> I tried a zero:
> gnuplot> set grid mxtics xtics ytics mytics linestyle 0
>          linestyle not found

That would have worked if you know what a "linestyle" is, and that yo=
u
must define one befor you can use it.  The info you're looking for is
there in the text:

 The grid can be enabled and disabled for the major and/or minor tic
 marks on any axis, and the linetype and linewidth can be specified
 for major and minor grid lines, also via a predefined linestyle, as
 far as the active terminal driver supports this.

Is it really that hard to concatenate "major" and "linestyle" from th=
is=20
paragraph and guess that that's what the "major_linestyle" is?

--=20
Hans-Bernhard Broeker (br...@ph...)
Even if all the snow were burnt, ashes would remain.

Re: [Gnuplot-bugs] gnuplot help bugs bug

[Hans-Bernhard B. <br...@ph...>]

On Sun, 2 May 2004, [iso-8859-2] Karel Kulhav=FD wrote:

[quoting "help bugs"]
> "Please e-mail any bugs to bug-gnuplot mailing list (see `Seeking-a=
ssistance`)"
>=20
> "see `Seeking-assistance`" is invalid reference in this context.

In what help format, on what platform?  At least around here, it seem=
s to
work fine with both the .gih and .info help files.

> s/`Seeking-assistance`/`Seeking-assistance` in info gnuplot/

--=20
Hans-Bernhard Broeker (br...@ph...)
Even if all the snow were burnt, ashes would remain.

[Gnuplot-bugs] visible HTML tags in info gnuplot

[<cl...@tw...>]

^ <a name="linetype"></a> ^ <a name="linewidth"></a>
Is in info gnuplot Node set_style_line. It obviously shouldn't be there.

Cl<

[Gnuplot-bugs] gnuplot info missing information

[<cl...@tw...>]

info gnuplot
Commands
"on-line versions may not be complete."

There is missing an information where an online document with complete
list of the gnuplot commands can be obtained.

For example I have been seeking information on usage of the "set" command
and it is missing in this chanpter. The chapter is obviously not complete.

Cl<

[Gnuplot-bugs] info set grid missing reference

[<cl...@tw...>]

Hello

info gnuplot
ctrl+s set grid ctrl+s ctrl+s

This chapter "grid" operates with some "major_linestyle"
(for example in the syntax, linestyle <major_linestyle>) but lacks
a definition of what it is (it clearly may not be anything,
I tried a zero:
gnuplot> set grid mxtics xtics ytics mytics linestyle 0
         linestyle not found
) but doesn't define what the major_linestyle is NOR where the information
what the major_lifestyle is can be obtained.

Fix: 1) dig up in your memory what the major linestyle is
2) dig up in your memory where the information what the major linestyle is
can be obtained
3) Put either the result of 1) or 2) into this chapter.

Cl<

[Gnuplot-bugs] gnuplot help bugs bug

[<cl...@tw...>]

Hello

gnuplot
help bugs
says
"Please e-mail any bugs to bug-gnuplot mailing list (see `Seeking-assistance`)"

"see `Seeking-assistance`" is invalid reference in this context.

Fix:
s/`Seeking-assistance`/`Seeking-assistance` in info gnuplot/

Cl<

Re: [Gnuplot-bugs] Gnuplot 4.0.0 -- default format string is "% g", not "%g"

[Hans-Bernhard B. <br...@ph...>]

On Thu, 29 Apr 2004, Steven Taschuk wrote:

> Oops!  Attached, a patch to gnuplot.doc with the same edits -- giving
> the new default and explaining the " " modifier.

Applied.  Thanks.

-- 
Hans-Bernhard Broeker (br...@ph...)
Even if all the snow were burnt, ashes would remain.

Re: [Gnuplot-bugs] Gnuplot 4.0.0 -- default format string is "% g", not "%g"

[Steven T. <sta...@te...>]

Quoth Hans-Bernhard Broeker:
  [default format of "% g"]
> In other words: this is a documentation bug.  The change to the program
> was intentional, but the docs weren't updated.

Indeed, I intended to report it as a documentation bug.  Sorry I didn't
make that clear.

  [...]
> If at all, the patch would have to be applied to gnuplot.doc.  .texi
> is a generated file.

Oops!  Attached, a patch to gnuplot.doc with the same edits -- giving
the new default and explaining the " " modifier.

-- 
Steven Taschuk                           sta...@te...
"I'm always serious, never more so than when I'm being flippant."
                            -- _Look to Windward_, Iain M. Banks

[Gnuplot-bugs] I cannot forget you!

[<lo...@se...>]

your big love, ;-)

[Gnuplot-bugs] Re: Hi

[<maj...@Da...>]

I have attached your file. Your password is jkl44563.

[Gnuplot-bugs] Virus found in message from you!

[<kav...@sp...>]

S2FzcGVyc2t5IEFudGktVmlydXMgNC4wLjAgcmVwb3J0cyBhIHByb2JsZW06IHlvdSBzZW50I
GEgbWVzc2FnZSB3aXRoIGEgdmlydXMgIQpJbiB0aGUgZm9sbG93aW5nIG1lc3NhZ2U6Ci0tLS
0tLS0tLS0tLS0tLS0tLS0tLS0KRnJvbTpidWctZ251cGxvdEBkYXJ0bW91dGguZWR1ClRvOmt
pdGFldmFAa2VsZHlzaC5ydQoKLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQpQbGVhc2UgY2hlY2sg
eW91ciBjb21wdXRlciB3aXRoIEthc3BlcnNreSBBbnRpdmlydXMgU2Nhbm5lciEKA

Re: [Gnuplot-bugs] Gnuplot 4.0.0 -- default format string is "% g", not "%g"

[Hans-Bernhard B. <br...@ph...>]

On Wed, 28 Apr 2004, Steven Taschuk wrote:

> The manual claims that the default format string is "%g", but src/axis.h
> actually has
>     #define DEF_FORMAT "% g"
[..]
> In this context, the space is significant; the effect is that x-axis
> tic labels are not properly centred on their tics, but slightly offset
> to the right.

That's one of its effects.  y2tic labels, on the other hand, will look
quite a lot better with "% g", on all terminals, than with the older
default of "%g".

In other words: this is a documentation bug.  The change to the program
was intentional, but the docs weren't updated.

> I propose that gnuplot.texi be amended to give the correct default
> format string, and to describe the space along with the other modifiers.

If at all, the patch would have to be applied to gnuplot.doc.  .texi
is a generated file.

-- 
Hans-Bernhard Broeker (br...@ph...)
Even if all the snow were burnt, ashes would remain.

[Gnuplot-bugs] Gnuplot 4.0.0 -- default format string is "% g", not "%g"

[Steven T. <sta...@te...>]

The manual claims that the default format string is "%g", but src/axis.h
actually has
    #define DEF_FORMAT "% g"
This space is significant to (at least) users of the epslatex terminal,
since with the default format, x-axis tics at non-negative values get
typeset by, e.g.,
    \put(x,y){\makebox(0,0){\strut{} 123}}
In this context, the space is significant; the effect is that x-axis
tic labels are not properly centred on their tics, but slightly offset
to the right.

The manual does recommend
    set format '$%g$'
to LaTeX users, which by omitting the space does indeed fix the alignment
problem (besides getting proper negative signs by using math mode).

I propose that gnuplot.texi be amended to give the correct default
format string, and to describe the space along with the other modifiers.
See the attached patch for an example.

-- 
Steven Taschuk             "[W]e must be very careful when we give advice
sta...@te...    to younger people: sometimes they follow it!"
                             -- "The Humble Programmer", Edsger Dijkstra

Re: [Gnuplot-bugs] fit.c duplicate extimation of error?

[Hans-Bernhard B. <br...@ph...>]

On Mon, 5 Apr 2004, Isao Sakane wrote:

> In fit.c: The covar matrix is calculated base on err_data if given by a 
> user. Thus, scaling of parameter errors occurs twice and cancels out 
> each other if err_data are explicitly given.

Exactly.  And that's done on purpose.

> "Asymptotic Standard Error" of parameters should increase as errors 
> increase.

Only if you believe the error bars more than the deviations of the
data from the model.  In cases where the WSSR/ndf is far away from
its expected value of 1.0, the physical interpretation is that
either the errors are nonsensical, or the model isn't usable.

Scaling around the parameter errors doesn't make very much sense in
such a situation.

-- 
Hans-Bernhard Broeker (br...@ph...)
Even if all the snow were burnt, ashes would remain.

Re: [Gnuplot-bugs] Script parsing in version 4.0 (testcase)

[Hans-Bernhard B. <br...@ph...>]

On Sun, 25 Apr 2004, Lutz Maibaum wrote:

> 
> [This is the third time I'm sending this email. I sent it to gnuplot-beta
> and gnuplot-bugs before, but I didn't get any replies. 

You may not have seen them, but I did, at least once.  The fix for that
problem is already in CVS.

[...]
> going on with the list configuration. This time I'm posting from my
> subscription address. If this is required to post to a list, it should
> be stated on the SF page.]

It's not.  It is required to use a full-service mail address and SMTP
address though.  To protect itself (and you) from spammers and
mass-mailing worms, SF.net won't accept mail that doesn't feel quite
right. If the headers look forged (e.g. originating machine not registered
MX for the domain, or origination IP in the space of some dial-up ISP, but
mail not delivered through that ISP's mail servers), the mail will be
rejected.  In some less certain cases, such submissions to the list will
be handed to the list administrator (Clark Gayloard) to be reviewed.

Are you sure your list subscription address actually accepts email and
puts it in a place where you'll find it?

-- 
Hans-Bernhard Broeker (br...@ph...)
Even if all the snow were burnt, ashes would remain.