gnuplot-bugs Mailing List for gnuplot

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.

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

your big love, ;-)

I have attached your file. Your password is jkl44563.

S2FzcGVyc2t5IEFudGktVmlydXMgNC4wLjAgcmVwb3J0cyBhIHByb2JsZW06IHlvdSBzZW50I
GEgbWVzc2FnZSB3aXRoIGEgdmlydXMgIQpJbiB0aGUgZm9sbG93aW5nIG1lc3NhZ2U6Ci0tLS
0tLS0tLS0tLS0tLS0tLS0tLS0KRnJvbTpidWctZ251cGxvdEBkYXJ0bW91dGguZWR1ClRvOmt
pdGFldmFAa2VsZHlzaC5ydQoKLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQpQbGVhc2UgY2hlY2sg
eW91ciBjb21wdXRlciB3aXRoIEthc3BlcnNreSBBbnRpdmlydXMgU2Nhbm5lciEKA

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.

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

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.

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.

[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. This alone wouldn't
be suspicious, but I also didn't receive a copy of my email, which makes
me think that there might be something strange 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.]

I noticed the following behavior of gnuplot 4.0, see the attached file:
the command
  cat test.gp | gnuplot -persist
aborts with the error message "invalid character", but running this script
from within gnuplot with the "load" command works just fine. Under gnuplot
3.7.1, both methods produce the desired result.

I'm sorry for the very strange looking testcase, I couldn't reduce it any
more and still trigger this behavior. Even deleting a single space in
front of the "plot" command cures this problem.

  Lutz

On Thu, 22 Apr 2004, Hans-Bernhard Broeker wrote:

> That suggests two possible reasons:
> 
> 1) Command line length
> 2) Timing
> 
> I suspect the latter, since running this on Linux with a different
> terminal than X11, like this:
> 
> 	cat test.gp | env GNUTERM=dumb gnuplot -persist
> 
> gave me a plot instead of any error message.

I'll eat those words and claim the opposite: it *is* about line length,
and I've found out why.  

The crucial bit is that one of your backslashes from line continuations
falls exactly onto the border where the input_line buffer is extended by
another KiB, i.e. when read_line() calls extend_input_line() in line 2476
of command.c.  The problem is the 'continue' that follows this call --- it
jumps across the handling of backslash-newline.  Patch is under 
construction.

The reason this doesn't happen if you 'load' this same script, I think, is
that the gnuplot prompt is formally part of the input line, i.e. your
critical point gets shifted by a couple of charactes, and the problem
disappears.

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

On Wed, 21 Apr 2004, Lutz Maibaum wrote:

> I noticed the following behavior of gnuplot 4.0, see the attached file: the 
> command
>   cat test.gp | gnuplot -persist
> aborts with the error message "invalid character", but running this script 
> from within gnuplot with the "load" command works just fine. Under gnuplot 
> 3.7.1, both methods produce the desired result.

Which platform?

> I'm sorry for the very strange looking testcase, I couldn't reduce any more 
> and still trigger this behavior. Even deleting a single space in front of the 
> "plot" command cures this problem.

That suggests two possible reasons:

1) Command line length
2) Timing

I suspect the latter, since running this on Linux with a different
terminal than X11, like this:

	cat test.gp | env GNUTERM=dumb gnuplot -persist

gave me a plot instead of any error message.

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

I noticed the following behavior of gnuplot 4.0, see the attached file: the 
command
  cat test.gp | gnuplot -persist
aborts with the error message "invalid character", but running this script 
from within gnuplot with the "load" command works just fine. Under gnuplot 
3.7.1, both methods produce the desired result.

I'm sorry for the very strange looking testcase, I couldn't reduce any more 
and still trigger this behavior. Even deleting a single space in front of the 
"plot" command cures this problem.

  Lutz

Hi,

with gnuplot 4.0 do:

> set size square; set pm3d map; splot exp(-(x-y)**2)
> set xrange [-10:10]; set yrange [-10:10]; replot

In the second plot, i.e. in the replot the y axis is upside down.

This did not happen with Version 3.8j patchlevel 0.

Cheers,
-ha

On Wed, 21 Apr 2004, Harald Anlauf wrote:

> Hi,
> 
> when running "make check" after a successful build of gnuplot 4.0 I
> encounter the following problem:
[...]
> It may be a problem with the PATH variable.  I modified demo/Makefile
> so that it reads
[...]

Formatting was a little botched, but I see what you actually changed: you
kept the old $PATH at the end of the newly set one.  Yes, that makes
sense. I'll check in a change like that unless someone objects (quickly).

Thanks for taking the time to dig into this.

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

Hi,

when running "make check" after a successful build of gnuplot 4.0 I
encounter the following problem:

[...]
Making check in demo
/usr/local/src/packages/gnuplot-4.0.0/demo
make[1]: Entering directory `/usr/local/src/packages/gnuplot-4.0.0/demo'
make  check-local
make[2]: Entering directory `/usr/local/src/packages/gnuplot-4.0.0/demo'
make[2]: *** [check-noninteractive] Error 128
make[2]: Leaving directory `/usr/local/src/packages/gnuplot-4.0.0/demo'
make[1]: *** [check-am] Error 2
make[1]: Leaving directory `/usr/local/src/packages/gnuplot-4.0.0/demo'
make: *** [check-recursive] Error 1

A window pops up that it cannot find cygwin1.dll .
Since the installed gnuplot appears to work, I looked for a quick fix.

It may be a problem with the PATH variable.  I modified demo/Makefile
so that it reads

check-noninteractive: $(BINARY_FILES)
		      @if test -z "$(GNUTERM)" ; then \
		        ( bdir=`pwd` ; PATH=$$bdir/../src:$$PATH
		      GNUPLOT_DRIVER_DIR=$$bdir/../src \
		          GNUPLOT_LIB=$(srcdir) $(GNUPLOT) $(DEMO)
		      </dev/null ); \
		      else \
		        ( bdir=`pwd` ; PATH=$$bdir/../src:$$PATH
		      GNUPLOT_DRIVER_DIR=$$bdir/../src \
		          GNUTERM=$(GNUTERM) GNUPLOT_LIB=$(srcdir)
		      $(GNUPLOT) $(DEMO) </dev/null ); \
		      fi

to make the check succeed.

Keep up the good work!

Cheers,
-ha

$BFMA3$N%a!<%k$GBgJQ62=L$G$9!#;d$O7HBS@lMQ%3%_%e%K%#%F%#!<%5%$(B
$B%H!V(BClubD$B!W$N%U%i%s%A%c%$%:$r1?1D$9$k%"%a!<%8%s%0%W%i%s$NNk(B
$BLZ$H?=$7$^$9!#(B
$B$<$R$H$b;d$I$b$N9T$C$F$k%U%i%s%A%c%$%:%7%9%F%`$K;22C$7$FD:$-(B
$B$?$/;W$$!"$4O"Mm$5$;$FD:$$$?<!Bh$G$9!#$3$N$h$&$J9-9p$K$O@5D>(B
$B$&$s$6$j$5$l$F$$$k$3$H$H;W$$$^$9$,!"=P8}$N8+$($J$$8=:_$NIT67(B
$B$K$"$C$FIT0B$r2r>C$7F@$k%S%8%M%9$G$9$N$G!"$4LLE]$G$b!"$<$R:G(B
$B8e$^$G$40lFI2<$5$$!#(B


$B!y(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(B
ClubD$B%U%i%s%A%c%$%:%7%9%F%`$H$O!)(B
$B(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!!y(B

$B%j%9%/(I$$B0l@Z$NHqMQ$rH<$J$o$:(I$$B%3%_%e%K%F%#%5%$%H(B(Jsky(I$(Bi-mode$B!"(B
$B#E#ZBP1~(B)$B$,1?1D$G$-(I$$BB?$/$N<}F~$r3MF@$G$-$k5!2q$rDs6!$9$k(B
$B%7%9%F%`$G$9!#(B
$B!z(,(,(,(,(,(,(,(,(,(,(,>\:Y$O(Bhttp://www.amazing-plan.com/$B$X(B
$B!y(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(B
$B2CLA6b!"1?1DHq$J$I$O0l@ZITMW!*(B
$B(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!!y(B

$B4JC1$JEPO?$N$_$GL5NA$G%5%$%H%*!<%J!<$K$J$l$^$9!#2?$i%j%9%/$r(B
$BIi$&$3$H$J$/!"4JC1$J<jB3$-$N$_$G%5%$%H%*!<%J!<$K$J$l$^$9!#$7(B
$B$+$b!"%9%?!<%H;~$GB??t$N2q0w$,EPO?:Q$_$J$N$G%5%$%H$r?7$?$KN)(B
$B$A>e$2$k$H$$$&O+NO$,MW$j$^$;$s!#(B


$B!y(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(B
$BLLE]$J%a%s%F%J%s%9!"2q0w4IM}$OITMW!*(B
$B(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!!y(B

$B%a%s%F%J%s%9!"2q0w4IM}$,0l@ZITMW$J$N$G0B?4$7$F1?1D$,$G$-$^$9!#(B


$B!y(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(B
$B7QB3$7$?0BDj<}F~$,F@$i$l$k!#Js=7$O(B3$B<oN`$G6H3&%H%C%W%/%i%9!*(B
$B(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!!y(B

$B"!CK@-2q0wGd>eJs=7"*CK@-%f!<%6!<$NAmGd>e$N(B30%$B$,Js=7$K$J$j$^$9!*(B
$B"!=w@-2q0wGd>eJs=7"*=w@-2q0w(B1$BL>$K$D$-(B30$B1_$NJs=7$K$J$j$^$9!*(B
$B"!BeM}E9<h<!$.Js=7"*<+?H$N%5%$%H$h$j?7$?$KBeM}E9$KEPO?$5$l$?%5%$(B
$B%H$+$i$NGd>e$,$"$C$?>l9g!"$=$NGd>e$KBP$7$F$N(B10%$B$,Js=7$K$J$j$^$9!*(B
$B!z(,(,(,(,(,(,(,(,(,(,(,(,(,>\:Y$O(Bhttp://www.amazing-plan.com/$B$X(B

$B!y(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(B
$BB>$K??;w$,$G$-$J$$;B?7$J%3%s%F%s%D$N?t!9!*(B
$B(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!!y(B

$B%j%"%k$J;w4i3(:n@.5!G=$d9b2;<A$NCe%a%m$J$IB>$K4JC1$K??;w$G$-$J$$(B
$BL%NOE*$J%3%s%F%s%D$,K~:\$GC1$J$k(B1$B%3%_%e%K%#%F%#!<%5%$%H$N?h$r1[$(!"(B
$BI}9-$$5RAX$N<h$j9~$`$3$H$,2DG=$G$9!#(B

$B!y(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(B
$B%P%J!<9-9pBeM}E9$bF1;~Jg=8!*(B
$B(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!!y(B

$B8=:_1?1D$5$l$F$$$k%5%$%H$N0lIt$K9-9p%P%J!]$rE=$C$F$$$?$@$/$@$1$G(B
$B0BDj$7$?<}F~$,F@$i$l$^$9!#Js=73[$O%3%_%e%K%#%F%#!<BeM}E9$HF1MM$G(B
$B$9!"4{B8$N%P%J!]9-9pNA(I"(B1$B%/%j%C%/2?1_(I#$B$H$O(I$$BA4$/0[$J$j!"Js=73[$O(I$$B%P(B
$B%J!]9-9p$+$i(BClubD$B$KEPO?$7$?%f!<%6!<$,%]%$%s%H9XF~$K$h$kGd>e$,H/@8(B
$B$9$k$H(I$$BBeM}E9Js=7$H$7$F0lDj3[$,%5%$%H%*!<%J!<$K%P%C%/$5$l$k%7%9%F(B
$B%`$G$9(I!$B0J8e$b$=$N%f!<%6!<$+$iGd>e$,H/@8$9$k$H7QB3$7$FBeM}E9Js=7$,(B
$BH/@8$$$?$7$^$9$N$G0BDj$7$?<}F~$,F@$i$l!"C1$K(B1$B%/%j%C%/2?1_$N9-9pNA(B
$B$H$OL@$i$+$K0c$$$^$9(I!(B
$B!z(,(,(,(,(,(,(,(,(,(,(,(,(,(,>\:Y$O(Bhttp://www.amazing-plan.com/$B$X(B


$B:G8e$^$G$*FI$_D:$-$^$7$F@?$K$"$j$,$H$&$4$6$$$^$7$?!#(B
$B$*K;$7$$Cf!"BgJQ62=L$G$O$4$6$$$^$9$,!":#2s$4>R2p$5$;$F$$$?$@$$$?(B
$B%7%9%F%`$OC1$J$k>R2p$K$H$I$^$k$b$N$G$O$J$/!"I,$:$d$*Lr$KN)$F$k$b$N(B
$B$H3N?.$r$7$F$*$j$^$9!#(B

$B$3$N%7%9%F%`$K$D$$$F$N$4ITL@$JE@!"$4<ALd$J$I$,$4$6$$$^$7$?$i$*5$7Z(B
$B$K2<5-$^$G$*Ld9g$;2<$5$$!#(B
$B$=$l$G$O!"2?B4$48!F$$N$[$I$h$m$7$/$*4j$$?=$7>e$2$^$9!#(B

$BJ@<R$+$i$N%a!<%k$,ITMW$JJ}$d%a!<%k$,=EJ#$7$F$$$?>l9g$O$4LBOG$r$*3]$1(B
$BCW$7$?;v$r?<$/$*OM$SCW$7$^$9!#(B
$B:#8e!"J@<R$+$i$N$40FFb$,ITMW$J>l9g$O!"$*<j?t$G$9$,2<5-$N%"%I%l%9$^$G(B
$BITMW$N;]!"$45-F~D:$-DLCNJV?.$r$*4j$$$7$^$9!#%a!<%k$r$*Aw$j$7$?$3$H$K(B
$B$h$jITL{2w$J;W$$$r$5$;$F$7$^$$?=$7Lu$4$6$$$^$;$s!#(B

$B4k2h!&1?1D(B
$B%"%a!<%8%s%0%W%i%s(B
$BC4Ev!'NkLZ(B
E$B!](BMail: su...@am...

http://www.gnuplot.info/docs/gpcard.pdf file has been saved in PORTRAIT mode.

It needs to be saved in LANDSCAPE mode.

Dear maintainers of gnuplot.

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.

For example, if you fit the data,
# fit data (data.dat)
0	1.1	100
1	1.9	100
2	5.1	100
3	9.9	100
4	17.1	100
With the function f(x) = a * x**2 + b, results of fitting from "fit f(x)
 'data.dat' using 1:2 via a, b" and "fit f(x) 'data.dat' using 1:2:3 via
 a, b" are identical (except for sum of squares of residuals). However, 
"Asymptotic Standard Error" of parameters should increase as errors 
increase.

I think this bug can be resolved with a patch attached below.
I don't subscribe this mailing list. Please inform me if there is 
something with this patch.

Regards.
----
Isao Sakane <sa...@bi...>
Tottori University, Faculty of Engineering, Dept. of Biotechnology,
Koyamacyo-minami 4-101, Tottori-city, Tottori, Japan. ZIP:680-8552

----
Hear is a patch.
--- fit.c.old	2004-04-05 09:22:07.000000000 +0900
+++ fit.c	2004-04-05 12:09:29.000000000 +0900
@@ -745,7 +745,17 @@
 	covar = C + num_data;
 	Invert_RtR(C, covar, num_params);
 
-	/* calculate unscaled parameter errors in dpar[]: */
+	if (columns <= 2) {
+	    /* scale covar matrix based on chisq */
+	    chisq /= (num_data - num_params);
+	    for (i = 0; i < num_params; i++) {
+		/* only lower triangle needs to be handled */
+		for (j = 0; j <= i; j++)
+		    covar[i][j] *= chisq;
+	    }
+	}
+
+	/* calculate parameter errors in dpar[]: */
 	dpar = vec(num_params);
 	for (i = 0; i < num_params; i++) {
 	    /* FIXME: can this still happen ? */
@@ -761,11 +771,6 @@
 		covar[i][j] /= dpar[i] * dpar[j];
 	}
 
-	/* scale parameter errors based on chisq */
-	chisq = sqrt(chisq / (num_data - num_params));
-	for (i = 0; i < num_params; i++)
-	    dpar[i] *= chisq;
-
 	Dblf("Final set of parameters            Asymptotic Standard 
Error\n");
 	Dblf("=======================            =======================
===\n\n");