gnuplot-beta — Developers and beta testers of new gnuplot code

Re: Build problem

[Hardy G. <nt...@ma...>]

Timothée Lecomte wrote:
:

> This appears because of a problem with pkg-config, or the absence of it. 
> Here is a relevant quote I found with google :

Dear Timothée,

thanks for the hint.  I've installed pkg-config, but the problem still 
remains (BTW "type -a pkg-config" shows "pkg-config is 
/usr/local/bin/pkg-config"):

checking how to run the C++ preprocessor... g++ -E
./configure: line 13465: syntax error near unexpected token `CAIRO,'
./configure: line 13465: `    PKG_CHECK_MODULES(CAIRO, cairo >= 0.9.0,'

Also the previous prepare shows the problem Jürgen already reported:

configure.in:243: error: possibly undefined macro: AC_MSG_WARN
       If this token and others are legitimate, please use m4_pattern_allow.
       See the Autoconf documentation.

I start to think, that the autoconf/automake-and-so-on-installation is 
somehow broken in cygwin or gnuplot uses some tricks and tweaks which 
would need special handling for cygwin.

Hardy


PS: perhaps somebody could post the lines in question of the configure 
script so I could compare my broken and a working version!?

converting the plot

[Laurence A W. <la...@ge...>]

I'm using gnuplot 4.0 and I am having a terrible time trying to convert
and save the plot as a png image file.  I managed to do it once by
setting the terminal to png and saving the file with a .png script on
it.  However I am not able to repeat the procees for another plot.  The
tutorial and help sites have not given adequate explanation for this.
Could you please send an answer with an example in syntax to solve this.

Thank you,

Lance Williams

Re: [ 1004754 ] Tics and grid slightly outside border.

[Daniel J S. <dan...@ie...>]

I've placed a patch under bug report [ 1004754 ] on SourceForge that is a cleanup of the tic generation.  I think it would be worth considering for 4.2, because it does fix the bug and it is much friendlier computer math and programming wise in my opinion--very clean.  I think I've covered everything, such that there is a good chance any outstanding tic placement bugs should have been addressed by this.  Please take a look at the patch and see what you think.  I've put detailed comments at the key points.  It should be clear in the patch why things are done the way they are.  There really isn't too much changed.  Now is the best time to work on this, since it is fresh and I will soon get busy on other projects.

The reason I think what this patch is an improvement is that it handles rounding artifacts in several different places where they crop up rather than trying to solve them all with a single conditional test right before the tic-placement in the for-loop.  This patch does not have any type of SIGNIF and tolerance based upon the range.  It only deals with rounding effects at the level of DBL_EPSILON or order thereof.

Furthermore, the tic placement is done more in an integerized fashion, i.e., an integer start and integer end corresponding to the start and end values after factoring out the step increment are computed.  We then know before entering the loop what the number of intervals, N_int, should be.  (An interval is the major tic with the group of potential minor tics to its positive side.)

Being more accurate with respect to the integer equivalents, the code address any roundoff problem with the major tic end point as:

	    /* Address rounding issues in the following way */
	    if (i_tic == (N_int - 1))
		tic = end;
	    else
		tic = start + i_tic * step;

to avoid losing a tic at the end range.

I've checked every example in 'all.dem' for consistency before and after the patch and that the patch fixes the bug of grid lines sometimes landing outside the borders.  In fact, 'all.dem' helped a great deal for debugging.

Dan

Re: Build problem

[<tim...@en...>]

Hardy Griech wrote:
> James R. Van Zandt wrote:
> :
>  =20
>> That will show you the first versions found in PATH.  But the
>> configure/build scripts might not respect the PATH.  I think it's
>> easiest to check for multiple versions directly.  If there are none,
>> then there is nothing to worry about. =20
>>    =20
> :
>
> For my installation all different paths does show the same version.
>
> BTW configure is being generated, but (for me) it fails with
>
> checking dependency style of g++... gcc3
> checking how to run the C++ preprocessor... g++ -E
> ./configure: line 13470: syntax error near unexpected token `CAIRO,'
> ./configure: line 13470: `    PKG_CHECK_MODULES(CAIRO, cairo >=3D 0.9.0=
,'
>
> Any ideas?
>
> Hardy
>  =20
Dear Hardy,

This appears because of a problem with pkg-config, or the absence of it.=20
Here is a relevant quote I found with google :

___________
/    When configuring EVAS, why do I see this:/

	checking whether directfb backend is to be built... ./configure: line 92=
43:=20
	   syntax error near unexpected token `PKG_CHECK_MODULES(DIRECTFB,'
	./configure: line 9243: `          PKG_CHECK_MODULES(DIRECTFB, directfb =
>=3D 0.9.16)'

    You don't have pkg-config installed, or setup properly. To correct=20
this, download, build, and install pkg-config=20
<http://www.freedesktop.org/software/pkgconfig/>. If this error still=20
shows up after you install  pkg-config, it is because aclocal isn't=20
finding the pkg.m4 and using it. Make sure that pkg.m4 is in your=20
aclocal share (usually: /usr/local/share/aclocal). If it isn't there,=20
find out whats wrong and get it there. If it is there, re-run=20
./autogen.sh and the new m4 will be used and the problem won't reappear.
___________

But this raises an interesting point : pkg-config is only needed if you=20
want the wxWidgets terminal. So I guess I should add a non-fatal test=20
for pkg-config, and call the PKG_CHECK_MODULES macro only if possible,=20
otherwise disable the wxWidgets termina.

Timoth=E9e

Re: Build problem

[Hardy G. <nt...@ma...>]

James R. Van Zandt wrote:
:
> That will show you the first versions found in PATH.  But the
> configure/build scripts might not respect the PATH.  I think it's
> easiest to check for multiple versions directly.  If there are none,
> then there is nothing to worry about.  
:

For my installation all different paths does show the same version.

BTW configure is being generated, but (for me) it fails with

checking dependency style of g++... gcc3
checking how to run the C++ preprocessor... g++ -E
./configure: line 13470: syntax error near unexpected token `CAIRO,'
./configure: line 13470: `    PKG_CHECK_MODULES(CAIRO, cairo >= 0.9.0,'

Any ideas?

Hardy

Re: Build problem

[Hardy G. <nt...@ma...>]

Juergen Wieferink wrote:
> ============================================================================
> configure.in:243: error: possibly undefined macro: AC_MSG_WARN

Although this might seem to be outdated, I have the same problem on a 
cygwin installation with the same versions of automake and automake like 
Jürgen.

Has anybody found a solution?

Hardy

Re: integration approximation demo in bivariat.dem

[James R. V. Z. <jr...@co...>]

Daniel J Sebald <dan...@ie...> wrote:
>   James R. Van Zandt wrote:
>   > Daniel J Sebald <dan...@ie...> wrote:
>   > 
>   >>  Paging through all.dem, something caught my eye in the bivariat.dem demo.  
>   >>  ...
>   >>  The first example is of approximating integration of a function.
>   >>  Unfortunately it appears to be a bad approximation.
>   > 
>   > 
>   > I looked the integration demo some time ago.  Attached are some
>   > suggested changes.  It might be worth while including two versions -
>   > one to show the basic approach, and the other to show possible
>   > refinements that improve the results at the cost of some obscurity.
>
>   Not following what you mean.  Do you mean use a lower order
>   approximation such as trapezoidal to compare against Simpson's
>   rule?

I'm just thinking it would be easier for the user to study the
original program first, then the more sophisticated one.
...
>   Very nice.  Could add a note about the accuracy of the third order
>   Simpson's for approximating a second order function at the sample
>   points, i.e., exact.  Is that the kind of thing you meant?

Yes.

             - Jim Van Zandt

Re: [ 1004754 ] Tics and grid slightly outside border.

[Daniel J S. <dan...@ie...>]

I just about have a patch together for this.  I don't think this SIGNIF a=
nd stuff is necessary.  I think this is what you were referring to before=
 about resolution sorts of this propogating about.

The idea here is to overlay a series of tics, major AND minor, to cover t=
he viewable range, or the range specified by the user that is within the =
viewable range.  Because we want to include minor tics, that means we sho=
uld push the minor tics out one further than what is visible on the plot.

>From there, generate the tic (major or minor); if it is in the visible ra=
nge plot it otherwise don't.

There are more elegant ways of dealing with precision problems.  For exam=
ple, rather than doing this:

	if (start > end) {
	    /* put in order */
	    double numtics =3D floor((end * (1 + SIGNIF) - start) / incr);

	    end =3D start;
	    start =3D end + numtics * incr;
	    incr =3D -incr;
	}

how about

	if (start > end) {
	    /* put in order */
	    double numincr =3D floor((end - start) / incr);

	    /* Deal with rounding issues this way */
	    if (start + (numincr + 1) * incr >=3D end)
		numincr++;

	    end =3D start;
	    start =3D end + numincr * incr;
	    incr =3D -incr;
	}


Hans-Bernhard Br=F6ker wrote:

> It would be easy to compute, sure.  Unfortunately, it can just as easil=
y=20
> be way off.  Especially where floating point maths close to its limit o=
f=20
> precision is involved:
>=20
>>   =3D> fabs((start + step) - start) < (step * 0.01)
>>   =3D> fabs(step) < (step * 0.01)
>=20
>=20
> That last line does *not* follow from the one above.  Not where=20
> floating-point arithmetic reigns.

Well, sure the case where start + step =3D start because of loss of resol=
ution.  But is that a situation where there will be a meaningful plot?  I=
t seems a convoluted way of deal with resolution problems.

I think we can get away from having to use such things.  I'll upload the =
patch this evening some time.

Dan

Re: [ 1004754 ] Tics and grid slightly outside border.

[<br...@ph...>]

Daniel J Sebald wrote:
> Daniel J Sebald wrote:
>> To make bug 1004754 work properly and remove the grid line from outside the plot, I commented out the following lines of code from gen_tics() in axis.c:
> 
> Taking another look at this routine, let's "decode" this code.  First--well let's enumerate
> 
> 1) The following code
> 
> 	for (tic = start; tic <= end; tic += step) {
> 	    if (anyticput == 2)	/* See below... */
> 		break;
> 
> would work better as
> 
> 	for (tic = start; tic <= end, anyticput != 2; tic += step) {

No, it wouldn't.  The comma operator is quite wrong for a conditional 
expression.  It would have to be replaced by &&, which would leave you 
with code exactly equivalent to the original one.


> so that the for loop exits right away once it is determined that the
> tics should not be plotted. 

That's exactly what the 'break' already does.

> 2) I think this method of determining when to not plot the tics,
> i.e., setting anyticput = 2 is silly.  

It's not.  It's complicated because it has to be.  We learned that the 
hard way, years ago.  The code looks the way it does because it was the 
simplest approach we found that actually worked reliably, even in 
extreme cases.

 > That could be easily done
> BEFORE even executing the for loop.  

No, it can't.  Numerical maths on an optimizing compiler is trickier 
than you know.  Things that look they should be mathematically 
equivalent, rather often aren't.

 > First, a more appropriate method
> of computing the tic should probably be to increment an integer index
> and compute from that, as pointed out in last email.  It would be
> easy to compute the number of tics there are supposed to be before
> this foor loop.  

It would be easy to compute, sure.  Unfortunately, it can just as easily 
be way off.  Especially where floating point maths close to its limit of 
precision is involved:

>   => fabs((start + step) - start) < (step * 0.01)
>   => fabs(step) < (step * 0.01)

That last line does *not* follow from the one above.  Not where 
floating-point arithmetic reigns.

Re: Is there a way of converting plot coords to graph coords?

[<br...@ph...>]

Ethan Merritt wrote:
> Do we have a utility routine somewhere that would convert 
> plot coordinates to graph or screen coordinates?

No.  axis.h:AXIS_MAP() and AXIS_MAPBACK transform from data 
('first'/'second') coordinates to terminal coordinates and back.
Going from terminal to 'screen' is trivial (just divide by term->xmax).
Transforming to 'graph' from data coordinates is quite easy: it's a 
direct linear transformation using the axis_array[].min and .max
values.

The X11-specific one you would want to look at is mouse_to_axis.
But the real key to this is in mouse.c:MousePosToGraphPosReal().
It's based on macros from axis.h

Re: Can I use gnuplot in java?

[<br...@ph...>]

Jun Guo wrote:

[nothing but the subject...]

Yes, you can.  About as easily as you can use any other native program.

Can I use gnuplot in java?

[Jun G. <ju...@ta...>]

=20

Re: [ 1004754 ] Tics and grid slightly outside border.

[Daniel J S. <dan...@ie...>]

Daniel J Sebald wrote:
> To make bug 1004754 work properly and remove the grid line from outside the plot, I commented out the following lines of code from gen_tics() in axis.c:

Taking another look at this routine, let's "decode" this code.  First--well let's enumerate

1) The following code

	for (tic = start; tic <= end; tic += step) {
	    if (anyticput == 2)	/* See below... */
		break;

would work better as

	for (tic = start; tic <= end, anyticput != 2; tic += step) {

so that the for loop exits right away once it is determined that the tics should not be plotted.  That would be good, because "step" could be very small and could go through the loop many, many times.

2) I think this method of determining when to not plot the tics, i.e., setting anyticput = 2 is silly.  That could be easily done BEFORE even executing the for loop.  First, a more appropriate method of computing the tic should probably be to increment an integer index and compute from that, as pointed out in last email.  It would be easy to compute the number of tics there are supposed to be before this foor loop.  Second, look at this test:

	    if (anyticput) {
	      if (NearlyEqual(tic, start, step)) {
		/* step is too small.. */
		anyticput = 2;	/* Don't try again. */
		tic = end;	/* Put end tic. */

"tic" starts out as "start".  The test isn't perform the first time through.  Second time through:  tic = start + step, the closest that "tic" will ever be to "start".  And NearlyEqual(x,y,tic) checks

fabs((tic)-(start)) < ((step) * SIGNIF))

  => fabs((start + step) - start) < (step * 0.01)
  => fabs(step) < (step * 0.01)

Which I believe is never true.  Now, the only other intent here I can see is that perhaps it was meant to limit the number of tics to 100 per plot.  But that can be done before the for loop and tested there.  Bottom line, I think this is useless code.

This line of code looks similar:

	      } else if (NearlyEqual(tic, end, step)) {

but I think what this does is attempt to catch the rounding effects that might produce a "double tic" right at the end.  This goes back to the fact that an integer index should be used, and in all likelihood this artifact can be avoided.

3) OK, let's say the intention of the first test in (2) was meant to limit the number of tics per plot to 100.  I'm going to raise the question Why?  I really don't care, but Hans made a valid point the other day about assuming some resolution of the plot and how any tiny overrun of the tic value should not be ignored.  Presumably some plotting device could  zoom in close enough that it could be important.  Isn't the same sort of resolution restriction assumed by limiting the number of tics?

Dan

[ 1004754 ] Tics and grid slightly outside border.

[Daniel J S. <dan...@ie...>]

To make bug 1004754 work properly and remove the grid line from outside the plot, I commented out the following lines of code from gen_tics() in axis.c:

	/* {{{  a few tweaks and checks */
	/* watch rounding errors */
//	end += SIGNIF * step;
	/* HBB 20011002: adjusting the endpoints doesn't make sense if
	 * some oversmart user used a ticstep (much) larger than the
	 * yrange itself */
//	if (step < (fabs(lmax) + fabs(lmin))) {
//	    internal_max = lmax + step * SIGNIF;
//	    internal_min = lmin - step * SIGNIF;
//	} else {
	    internal_max = lmax;
	    internal_min = lmin;
//	}


Now I see what you were talking about, Hans.  This SIGNIF is derived analogous to what I had proposed for TOL the other day.  I think what I had proposed--which I'm now happy to do without--made a bit more sense than whatever this is attempting to do.  Why (rhetorical question) would there be a need to tweak in any way the tic marks in such a visible way?

This should be straightforward x_i = tic * i + x_start and range check.  [It also could have been done as x_i = ((last_tic - first_tic) * i) / num_tics.]

Note the use of an integer i to compute a tic location.

gen_tics() should be re-examined.  I don't know if that should be done before 4.2 though.

Dan

Is there a way of converting plot coords to graph coords?

[Ethan M. <merritt@u.washington.edu>]

Do we have a utility routine somewhere that would convert 
plot coordinates to graph or screen coordinates?

What I want to do is take a mouse-click location,
which is reported in plot coords, and keep track of
where that was on the screen.

The closest I can find is this routine in gnuplot_x11:
 
  /* Convert X-window mouse coords to coordinate system of plot axes */
  static void
  mouse_to_coords(plot_struct *plot, XEvent *event,
                double *x, double *y, double *x2, double *y2)

but it's the wrong direction, and not visible in the core code
anyhow.


-- 
Ethan A Merritt
Biomolecular Structure Center
University of Washington, Seattle WA

gnuplot ChangeLog misprint (no.21)

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

shige 06/22 2006
----------------

In ChangeLog, ChangeLog.0, I found some reverse date orders that 
seems to be misprints. I send the unified diff file for them.

Some reverse orders still remain, but they does not so differ 
from neighbours or I don't know how I modify. They are the 
following lines:

  ChangeLog.0:
    2533, 2631, 2737, 2951, 3802, 5478, 6180, 7085, 8004, 8151
  ChangeLog:
    4386, 5632

----- From here -----
diff -u ChangeLog.0.ORG ChangeLog.0
--- ChangeLog.0.ORG	Tue Oct  4 00:55:22 2005
+++ ChangeLog.0	Thu Jun 22 20:07:45 2006
@@ -105,7 +105,7 @@
 	it's worth.  To re-enable this, manually #define the
 	USE_OWN_WINSYSTEM_FUNCTION macro.
 
-2003-04-10  Hans-Bernhard Broeker  <br...@ph...>
+2004-04-10  Hans-Bernhard Broeker  <br...@ph...>
 
 	* INSTALL: Include a notice about the demise of 16-bit versions on
 	MS-DOS and Windows.  Updated the paragraph about the history of
@@ -2766,7 +2766,7 @@
         * NEWS, docs/gnuplot.doc: Add reference to current `set style fill`
 	and `set style line` commands.
 
-2002-09-21  Harald Harders  <h.h...@tu...>
+2002-10-21  Harald Harders  <h.h...@tu...>
 
 	* NEWS demo/all.dem demo/arrowstyle.dat demo/arrowstyle.dem
 	docs/gnuplot.doc src/axis.c src/axis.h src/gadgets.c src/gadgets.h
@@ -2776,7 +2776,7 @@
 	New 'set style arrow' and back angles for arrow head (see Patches:
 	[587056] arrow styles via 'set style arrow').
 
-2002-09-21  Harald Harders  <h.h...@tu...>
+2002-10-21  Harald Harders  <h.h...@tu...>
 
 	* docs/psdoc/Makefile docs/psdoc/ps_fontfile_doc.tex: This patch
 	improves the documentation for ps type1 font embedding. A table
@@ -4745,7 +4745,7 @@
 	* term/README: Corrected type of last argument of term->arrow()
 	Re-indented a bit.
 	
-2001-02-01  Hans-Bernhard Broeker  <br...@ph...>
+2002-02-01  Hans-Bernhard Broeker  <br...@ph...>
 
 	* src/win/pgnuplot.c: Added comment about -mno-cygwin option to be
  	used to avoid GPLification of pgnuplot by use of Cygwin's DLL.
@@ -4930,7 +4930,7 @@
 
 	* src/command.c: Fix for "history !load".
 
-2001-01-22  Hans-Bernhard Broeker  <br...@ph...>
+2002-01-22  Hans-Bernhard Broeker  <br...@ph...>
 
 	* src/graphics.c (boundary): Moved calls to set the axis endpoints
  	up here.  Fixes bug in key placement caused by uninitialized
@@ -10648,7 +10648,7 @@
 
 	* docs/ps: Renamed docs/psdoc.
 
-1999-03-08  Hans-Bernhard Broeker  <br...@ph...>
+1999-03-18  Hans-Bernhard Broeker  <br...@ph...>
 
 	* term/pslatex: Hopefully complete fix for off-by-one segmentation
 	fault.
@@ -11078,7 +11078,7 @@
 
 	* lisp/*: Updated to newest revision.
 
-1998-02-01  Dick Crawford  <u6...@ga...>
+1999-02-01  Dick Crawford  <u6...@ga...>
 
 	* graphics.c: Bugfix for failing 'set lmargin' command.
 
diff -u ChangeLog.ORG ChangeLog
--- ChangeLog.ORG	Thu Jun 22 13:06:56 2006
+++ ChangeLog	Thu Jun 22 20:02:55 2006
@@ -55,7 +55,7 @@
 	then the axis scaling may fail.
 	Bug #1490699.
 
-2006-05-18  Bastian Maerkisch  <bma...@we...>
+2006-06-18  Bastian Maerkisch  <bma...@we...>
 
 	* src/win/wtext.c: Add mouse wheel scroll support for text window.
 
@@ -414,7 +414,7 @@
 	and *background so that the default remains the same as having no
 	app-defaults file.
 
-2006-02-23  Timothee Lecomte  <tim...@en...>
+2006-05-23  Timothee Lecomte  <tim...@en...>
 
 	* term/wxt.trm (TERM_HELP): Fix typos, thanks to Shigeharu Takeno.
 
@@ -1647,7 +1647,7 @@
 	not. Therefore test index against firstpoint before trying to parse
 	it as a number.
 
-2005-01-23  Daniel Sebald  <dan...@ie...>
+2006-01-23  Daniel Sebald  <dan...@ie...>
 
 	* src/graphics.c (plot_image_or_update_axes): Fix for
 	"plot [from:to] [from:to] ... with image".
@@ -1707,7 +1707,7 @@
 	* src/plot3d.c (get3d_data):  Fix initialization code for 3D plot
 	style `with vectors`.
 
-2005-01-07  Mike Sutton  <mw...@us...>
+2006-01-07  Mike Sutton  <mw...@us...>
 
 	* term/gd.trm: New terminal option {rounded|butt} controls line caps.
 
@@ -1715,7 +1715,7 @@
 	the colorbox extend the full height of the y axis by default. Placement
 	in 3D plots is not affected. This was the old (pre-4.0) behaviour.
 
-2005-01-07  Daniel Sebald  <dan...@ie...>
+2006-01-07  Daniel Sebald  <dan...@ie...>
 
 	* term/gd.trm: Addtional processing of animated gifs to bring
 	output file into compliance with the Gif89a standard.
@@ -1729,7 +1729,7 @@
 	* src/term.c (term_end_multiplot): Free title string and clear
 	multiplot title.
 
-2005-01-07  Daniel Sebald  <dan...@ie...>
+2006-01-07  Daniel Sebald  <dan...@ie...>
 
 	* src/gplt_x11.c (record):  Incorrect nesting of parentheses.
 
@@ -3377,7 +3377,7 @@
 	* demo/stringvar.dem docs/gnuplot.doc src/eval.c: Rename substring
 	built-in function to substr(string,beg,end).
 
-2005-01-15  Bastian Maerkisch  <bma...@we...>
+2005-06-15  Bastian Maerkisch  <bma...@we...>
 
 	* term/pm.trm src/os2/gclient.c src/os/pm_msgs.h: Move definition of
 	message codes for communication between gnuplot (pm.trm) and gnupmdrv
----- To here ----- 

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

Re: Compiler bug????

[Daniel J S. <dan...@ie...>]

Ethan A Merritt wrote:

>>Reading specs from /usr/lib/gcc/i386-redhat-linux/3.4.2/specs
>>gcc version 3.4.2 20041017 (Red Hat 3.4.2-6.fc3)
> 
> 
> Ah, Redhat. They have a very bad track record for shipping
> bleeding-edge compiler versions that are, in fact, quite broken.

Well, that solves that issue.  Really set off a debate, didn't it?  Sorry about all that confusion.

Dan

Compiler bug????

[Daniel J S. <dan...@ie...>]

Hans-Bernhard Br=F6ker wrote:
> Daniel J Sebald wrote:
>=20
>> That is what I'm suggesting.  Below is an example of something for the=
=20
>> longest time I couldn't understand, i.e., why the yrang here is as it=20
>> is.  The y range could be forced to make it look better.
>=20
>=20
> Well, guess what: I just tried that example myself (OpenWatcom build fo=
r=20
> MS Windows, terminal windows), and got nothing like what you got in
> that PNG.  The yrange I got was [1:2], exactly as expected.
>=20
>> What is happening there?
>=20
>=20
> Whatever it is --- it's not happening here where I sit and type this ;-=
)
>=20
> You'll have to debug that yourself, I think.

I still can't believe what I'm seeing.  Coming into the round_outward() f=
unction, the following two lines of code:

fprintf(stderr, "FLOOR %d\n", (int)floor(input / tic));
fprintf(stderr, "FLOOR %d\n", (int)floor(input / tic));

produce:

FLOOR 4
FLOOR 5

I assume most people are using a more recent version of gcc than I am:

Reading specs from /usr/lib/gcc/i386-redhat-linux/3.4.2/specs
Configured with: ../configure --prefix=3D/usr --mandir=3D/usr/share/man -=
-infodir=3D/usr/share/info --enable-shared --enable-threads=3Dposix --dis=
able-checking --wiith-system-zlib --enable-__cxa_atexit --disable-libunwi=
nd-exceptions --enable-java-awt=3Dgtk --host=3Di386-redhat-linux
Thread model: posix
gcc version 3.4.2 20041017 (Red Hat 3.4.2-6.fc3)

Dan

Re: Please confirm whether or not image.dem works on Windows

[<br...@ph...>]

Ethan Merritt wrote:
> Binary files in cvs are supposed to be tagged with a special 
> marker so the download to Windows is performed correctly.
> Was this done for bluetux.rgb?   

As a matter of fact, it wasn't.

 > (And how does one check this?)

Sticky option '-kb' must be set.  The state of sticky options is 
displayed by 'cvs status' (or whatever your CVS client's equivalent of 
that happens to be).

Re: integration approximation demo in bivariat.dem

[Daniel J S. <dan...@ie...>]

Ah!  Very nice.  Thank you.  This should be moved into CVS as soon as possible.  Developers are probably being overwhelmed with patches, so perhaps place in SourceForge if it isn't attended to in the near future.

Dan


James R. Van Zandt wrote:
> Daniel J Sebald <dan...@ie...> wrote:
> 
>>  Paging through all.dem, something caught my eye in the bivariat.dem demo.  
>>  ...
>>  The first example is of approximating integration of a function.
>>  Unfortunately it appears to be a bad approximation.
> 
> 
> I looked the integration demo some time ago.  Attached are some
> suggested changes.  It might be worth while including two versions -
> one to show the basic approach, and the other to show possible
> refinements that improve the results at the cost of some obscurity.

Not following what you mean.  Do you mean use a lower order approximation such as trapezoidal to compare against Simpson's rule?


>                - Jim Van Zandt
> 
> These are the changes:
>  - Adjusting the step size so the range of integration is an integral
> number of steps.
>  - Using Simpson's rule rather than just taking the function value at
> one end of each step.
>  - Define the first integrand immediately before the plot command.
>  - Add points from the real erf(x) to the first plot, for comparison.

Very nice.  Could add a note about the accuracy of the third order Simpson's for approximating a second order function at the sample points, i.e., exact.  Is that the kind of thing you meant?


>  - For the second plot, define the integrand f(x)=cos(x).  That way,
> the integral is sin(x) instead of being offset by a constant of
> integration.

I didn't go much beyond the first, but studying it, that jumps out now.


>  - For the last plot, use "with points" to make the patterns more
> apparent, and because the function is only defined over the integers.

Much better.

Dan

Re: integration approximation demo in bivariat.dem

[James R. V. Z. <jr...@co...>]

Daniel J Sebald <dan...@ie...> wrote:
>   Paging through all.dem, something caught my eye in the bivariat.dem demo.  
>   ...
>   The first example is of approximating integration of a function.
>   Unfortunately it appears to be a bad approximation.

I looked the integration demo some time ago.  Attached are some
suggested changes.  It might be worth while including two versions -
one to show the basic approach, and the other to show possible
refinements that improve the results at the cost of some obscurity.

               - Jim Van Zandt

These are the changes:
 - Adjusting the step size so the range of integration is an integral
number of steps.
 - Using Simpson's rule rather than just taking the function value at
one end of each step.
 - Define the first integrand immediately before the plot command.
 - Add points from the real erf(x) to the first plot, for comparison.
 - For the second plot, define the integrand f(x)=cos(x).  That way,
the integral is sin(x) instead of being offset by a constant of
integration.
 - For the last plot, use "with points" to make the patterns more
apparent, and because the function is only defined over the integers.
 - Update the "set key" command to the current syntax


--- demo/bivariat.dem.orig	2006-03-21 21:33:02.000000000 -0500
+++ demo/bivariat.dem	2006-06-21 19:57:40.000000000 -0400
@@ -9,35 +9,42 @@
 # integral2_f(x,y) approximates the integral from x to y.
 # define f(x) to be any single variable function
 #
-# the integral is calculated as the sum of f(x_n)*delta 
-#   do this x/delta times (from x down to 0)
+# the integral is calculated using Simpson's rule as 
+#          ( f(x-delta) + 4*f(x-delta/2) + f(x) )*delta/6
+# repeated x/delta times (from x down to 0)
 #
-f(x) = exp(-x**2)
 delta = 0.2
 #  delta can be set to 0.025 for non-MSDOS machines
 #
 # integral_f(x) takes one variable, the upper limit.  0 is the lower limit.
 # calculate the integral of function f(t) from 0 to x
-integral_f(x) = (x>0)?integral1a(x):-integral1b(x)
-integral1a(x) = (x<=0)?0:(integral1a(x-delta)+delta*f(x))
-integral1b(x) = (x>=0)?0:(integral1b(x+delta)+delta*f(x))
+# choose a step size no larger than delta such that an integral number of
+# steps will cover the range of integration.
+integral_f(x) = (x>0)?int1a(x,x/ceil(x/delta)):-int1b(x,-x/ceil(-x/delta))
+int1a(x,d) = (x<=d*.1) ? 0 : (int1a(x-d,d)+(f(x-d)+4*f(x-d*.5)+f(x))*d/6.)
+int1b(x,d) = (x>=-d*.1) ? 0 : (int1b(x+d,d)+(f(x+d)+4*f(x+d*.5)+f(x))*d/6.)
 #
 # integral2_f(x,y) takes two variables; x is the lower limit, and y the upper.
-# claculate the integral of function f(t) from x to y
-integral2_f(x,y) = (x<y)?integral2(x,y):-integral2(y,x)
-integral2(x,y) = (x>y)?0:(integral2(x+delta,y)+delta*f(x))
+# calculate the integral of function f(t) from x to y
+integral2_f(x,y) = (x<y)?int2(x,y,(y-x)/ceil((y-x)/delta)): \
+                        -int2(y,x,(x-y)/ceil((x-y)/delta))
+int2(x,y,d) = (x>y-d*.5) ? 0 : (int2(x+d,y,d) + (f(x)+4*f(x+d*.5)+f(x+d))*d/6.)
 
 set autoscale
 set title "approximate the integral of functions"
 set samples 50
 
-plot [-5:5] f(x) title "f(x)=exp(-x**2)", 2/sqrt(pi)*integral_f(x) title "erf(x)=2/sqrt(pi)*integral_f(x)"
+f(x) = exp(-x**2)
+
+plot [-5:5] f(x) title "f(x)=exp(-x**2)", \
+  2/sqrt(pi)*integral_f(x) title "erf(x)=2/sqrt(pi)*integral_f(x)", \
+  erf(x) with points
 
 pause -1 "Hit return to continue"
 
-f(x)=sin(x)
+f(x)=cos(x)
 
-plot [-5:5] f(x) title "f(x)=sin(x)", integral_f(x)
+plot [-5:5] f(x) title "f(x)=cos(x)", integral_f(x)
 
 pause -1 "Hit return to continue"
 
@@ -78,7 +85,7 @@
 set yrange [-10:10]
 set isosamples 10
 set samples 100
-set key at 4,-3
+set key 4,-3
 set title "Min(x,y) and Max(x,y)"
 
 #
@@ -104,7 +111,7 @@
 
 set title "Greatest Common Divisor (for integers only)"
 
-plot gcd(x, 60)
+plot gcd(x, 60) with points
 pause -1 "Hit return to continue"
 
 reset

Re: Please confirm whether or not image.dem works on Windows

[Ethan M. <merritt@u.washington.edu>]

On Wednesday 21 June 2006 03:15 pm, Hans-Bernhard Br=F6ker wrote:
> Ethan Merritt wrote:
> > Binary files in cvs are supposed to be tagged with a special
> > marker so the download to Windows is performed correctly.
> > Was this done for bluetux.rgb?
>
> As a matter of fact, it wasn't.
>
>  > (And how does one check this?)
>
> Sticky option '-kb' must be set.  The state of sticky options is
> displayed by 'cvs status' (or whatever your CVS client's equivalent
> of that happens to be).

OK. So none of the binary files in .../demo were marked as such.

I've now marked added the flags, and hopefully this will fix the
problem.  Could you Windows guys please give it time to propagate
to the anonymous server, and then update the contents of .../demo
and try again?

=2D-=20
Ethan A Merritt
Biomolecular Structure Center
University of Washington, Seattle WA

Re: Please confirm whether or not image.dem works on Windows

[Daniel J S. <dan...@ie...>]

Ethan Merritt wrote:

> Binary files in cvs are supposed to be tagged with a special 
> marker so the download to Windows is performed correctly.
> Was this done for bluetux.rgb?   (And how does one check this?)

Good question.  I've been searching the CVS documentation for just that.  I recall reading something about this long ago.  I thought maybe it put a little "b" next to the file when it transfers.  But since I don't know that is supposed to happen, I'm not sure.

Could have something to do with that SF server shut down and the transfer of files.  Maybe they lost the binary flag or something?

Dan

Re: Bug #1503114

[Daniel J S. <dan...@ie...>]

Hans-Bernhard Br=F6ker wrote:
> Daniel J Sebald wrote:
>=20
>> That is what I'm suggesting.  Below is an example of something for the=
=20
>> longest time I couldn't understand, i.e., why the yrang here is as it=20
>> is.  The y range could be forced to make it look better.
>=20
>=20
> Well, guess what: I just tried that example myself (OpenWatcom build fo=
r=20
> MS Windows, terminal windows), and got nothing like what you got in
> that PNG.  The yrange I got was [1:2], exactly as expected.
>=20
>> What is happening there?
>=20
>=20
> Whatever it is --- it's not happening here where I sit and type this ;-=
)

Good grief.  I just looked at the "reference", i.e.,

http://gnuplot.sourceforge.net/demo_4.1/pm3d.html

and that too looks correct.  (However, the 3D example right after those, =
with the title "pm3d explicit mode" doesn't have the range [-3:3] [-3:3] =
as I think it should.)

I've seen this on my machine for at least a year, if not years!


> You'll have to debug that yourself, I think.

Sounds CPU dependent; I'll locate an oscilloscope.

Dan

Re: Please confirm whether or not image.dem works on Windows

[Ethan M. <merritt@u.washington.edu>]

On Wednesday 21 June 2006 01:45 pm, Hans-Bernhard Br=F6ker wrote:
> Ethan A Merritt wrote:
> > On Wednesday 21 June 2006 08:29 am, Daniel J Sebald wrote:
> >> I'm fairly certain that this bug has to do with the fact that in
> >> Windows, with the CR/LF, the following may be dogdy in some way:
> >>
> >>     if (!i_line) {i_line =3D ASCII_PER_LINE; *encoded_image_ptr++ =3D
> >> '\n';}
>
> Only if the file was opened in the wrong mode.  I'm reasonably sure
> gnuplot doesn't get this so spectactularly wrong.
>
> The most likely explanation is that the binary data files got mangled
> on the way from CVS to Mojca's Windows box, because some tool though
> it had to convert Unix to Microsoft style linebreaks (cygwin CVS to a
> text-mode mounted file system, or similar).

Binary files in cvs are supposed to be tagged with a special=20
marker so the download to Windows is performed correctly.
Was this done for bluetux.rgb?   (And how does one check this?)


=2D-=20
Ethan A Merritt
Biomolecular Structure Center
University of Washington, Seattle WA