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

Re: few remarks

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

On Wed, 11 Aug 2004, Ethan Merritt wrote:

> On Tuesday 10 August 2004 01:32 am, Hans-Bernhard Broeker wrote:
> > On Tue, 10 Aug 2004 mi...@ph... wrote:
> > 
> > > postscript terminal contains new option "level2". I propose to add (or
> > > rather change to) option "level1" -- I guess it is more natural to restrict
> > > to PS Level 1 printer by saying "set term post level1" rather than
> > > "set term post nolevel2". (Also, it may become confusing whether
> > > "PS Level 3" printer is "level2" or "nolevel2").
> > 
> > Agreed.
> 
> All the names I could think of are mis-leading.  

Hmmm... what about
	
	maxlevel <n>

then, where <n> is the maximum PS Level allowed to be used by post.trm?

> The option does not really turn off all Level 2 features, only some
> related to pattern-fill.

Then indeed it's a misnomer.  Which leaves two ways to proceed:

*) keep the name, but change the implementation so it actually does
cause PS Level 1.0 output to be generated.

*) find a new name. 'ai' might just be right.

> if this option works (under whatever name), do we still need
> a separate driver ai.trm?

I don't think so.  But then, I've never used Illustrator, so I wouldn't be
the right person to ask.  Maybe a user poll is in order.

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

Re: plot ...007

[<mi...@ph...>]

>> 3) keyword-less linetype and pointtype options, for compatibility with
>>   pre-3.7 gnuplot
>
> This has been a headache for me in trying to maintain order-indepence
> of all command options.  I vote for removing this backwards
> compatibility and requiring  "lt" or "pt" keywords.

Ok, fine with me.

---
PM

Re: few remarks

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

On Tuesday 10 August 2004 01:32 am, Hans-Bernhard Broeker wrote:
> On Tue, 10 Aug 2004 mi...@ph... wrote:
> 
> > postscript terminal contains new option "level2". I propose to add (or
> > rather change to) option "level1" -- I guess it is more natural to restrict
> > to PS Level 1 printer by saying "set term post level1" rather than
> > "set term post nolevel2". (Also, it may become confusing whether
> > "PS Level 3" printer is "level2" or "nolevel2").
> 
> Agreed.

All the names I could think of are mis-leading.  The option does not
really turn off all Level 2 features, only some related to pattern-fill.
I thought about making the command
	nopatternfill
but that isn't right either because it can still handle pattern-fill for
simple rectangles using Level 1 code.

This all started as part of an attempt to make the PostScript output
compatible with older versions of Adobe Illustrator. Maybe the option
should just be:

	set term post ai

The documentation can mention that the same work-around
that allows Illustrator to handle the output may also be useful for
some old printers that do not support Level 2 pattern definitions.

Which brings us all the way around to the original question -
if this option works (under whatever name), do we still need
a separate driver ai.trm?


-- 
Ethan A Merritt       merritt@u.washington.edu
Biomolecular Structure Center
Mailstop 357742
University of Washington, Seattle, WA 98195

Re: few remarks

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

Ethan Merritt wrote:

>On Monday 09 August 2004 11:04 pm, mi...@ph... wrote:
>  
>
>>Bug:
>>On x11 (well, I haven't look to other terminals), points in the points and
>>linepoints styles are "handicapped" -- look by a screen magnificator (xmag,
>>kmag) to points obtained by:
>>
>>set size ratio 1
>>plot sin(x)/x w point pt 2
>>    
>>
>
>That is one strange bug you have found.  The odd thing is that it seems
>to be a bug in the X server.   I can run the same gnuplot_x11 executable
>on two different machines and get two different results.  My best guess
>at the moment is that the key difference is which version of X11 is
>running, although it is also possible that it is a difference in the video
>driver rather than the version.  The issue is whether the rendering
>engine does, or does not, draw the final pixel in a line segment that is
>at 45 degrees. Changing the drawing style from CapButt to CapRound
>while drawing points fixes this, at least on the machines I have tested.
>I can't think of any bad effects from this so I will make the change.
>I'm sure someone will speak up if it uncovers some complementary
>bug on other X11 display setups.
>
>Meanwhile I notice that the aspect ratio of the plot symbols
>scales with that of the current x11 window.  This seems ugly to me,
>so I propose to also change the code so that the cross/plus/star/etc
>always has a 1:1 aspect ratio, even if the plot in which it lies does not.
>

I'm seeing the same kind of thing for the + (pluses) as well as the 
crosses.  It appears like the last pixel is not being drawn.  This *is* 
very odd.  How could this have gone unnoticed when who every programmed 
it, programmed it?

Dan

>  
>

Re: few remarks

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

On Monday 09 August 2004 11:04 pm, mi...@ph... wrote:
> Bug:
> On x11 (well, I haven't look to other terminals), points in the points and
> linepoints styles are "handicapped" -- look by a screen magnificator (xmag,
> kmag) to points obtained by:
> 
> set size ratio 1
> plot sin(x)/x w point pt 2

That is one strange bug you have found.  The odd thing is that it seems
to be a bug in the X server.   I can run the same gnuplot_x11 executable
on two different machines and get two different results.  My best guess
at the moment is that the key difference is which version of X11 is
running, although it is also possible that it is a difference in the video
driver rather than the version.  The issue is whether the rendering
engine does, or does not, draw the final pixel in a line segment that is
at 45 degrees. Changing the drawing style from CapButt to CapRound
while drawing points fixes this, at least on the machines I have tested.
I can't think of any bad effects from this so I will make the change.
I'm sure someone will speak up if it uncovers some complementary
bug on other X11 display setups.

Meanwhile I notice that the aspect ratio of the plot symbols
scales with that of the current x11 window.  This seems ugly to me,
so I propose to also change the code so that the cross/plus/star/etc
always has a 1:1 aspect ratio, even if the plot in which it lies does not.






> 
> ***
> 
> "help filledcurves" is not very well understandable.
> I propose the following:
> 
>  The `filledcurves` style is only relevant to 2-d plotting. Three variants
>  are possible. The first two take a function or two columns of input data
>  file, and may be tuned by options (see below). The default is `closed`, which
>  treats the curve itself as a closed polygon. The second variant is to fill the area
>  between the curve and a given axis, a horizontal or a vertical line, or a
>  point. The third variant requires three columns of input data file: the x
>  coordinate and two corresponding y coordinates (two curves); then, the area between the
>  two curves is filled.
> 
>  Syntax:
>  	...
> 
>  where the option (the first two variants only) can be
> 
>  ...
> 
>  Example for the third variant:
>  	plot 'data.dat' using 1:3:4 with filledcurves
> 
>  Note: ...
> 
> ***
> 
> postscript terminal contains new option "level2". I propose to add (or
> rather change to) option "level1" -- I guess it is more natural to restrict
> to PS Level 1 printer by saying "set term post level1" rather than
> "set term post nolevel2". (Also, it may become confusing whether
> "PS Level 3" printer is "level2" or "nolevel2").
> 
> ****
> 
> When "make tutorial" (under Linux): File $HOME/.gnuplot should not be read
> -- it may contain an offending command which breaks the make process.
> 
> Could the particular pieces of tutorial/Makefile[.am?] contain something
> like
> 	HOME=/dev/null gnuplot ...
> ?
> 
> ****
> 
> gnuplot.doc contains an example for using new features "title and
> xticlabels":
> 1.
>   plot 'datafile' using 1:(f($2)/$4) title 2 with lines
> 
>   I guess that a more transparent example could be the same as few lines
>   above:
> 
>   plot 'datafile' using 3:4 title 2 with lines
> 
>   (it is not clear what is f($2), and the result is obviously division, not
>   remainder?)
> 
> 
> 2. In gnuplot.doc, I propose that "help xticlabels" go (reference) to the
>   same entry as "help using xticlabels".
> 
> ***
> 
> 
> Currently I have only web access to internet, so I cannot do any change into
> cvs. Thus I'd like to ask others to submit my proposed features, if
> agreed. Thanks.
> ---
> Petr
> 
> 
> 
> 
> 
> -------------------------------------------------------
> SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media
> 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33
> Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift.
> http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
> 
> 

-- 
Ethan A Merritt       merritt@u.washington.edu
Biomolecular Structure Center
Mailstop 357742
University of Washington, Seattle, WA 98195

Re: plot ...007

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

On Wednesday 11 August 2004 06:54 am, mi...@ph... wrote:
> > 1) `.' all on its own as a valid number, equal to 0.0
>
> I propose that saying "." instead of "0." or ".0" should be an error.
> I don't think this abbreviation is supported by any programming language.
> This would solve the problem with "plot ..."

This is fixed (as an unintentional side-effect) by the string variables
expression parsing code.  If you can live with it for another few weeks,
you will instead get the behaviour:


Terminal type set to 'x11'
gnuplot> plot .
              ^
         invalid expression 

Or if you get more creative in stringing dots together you get:

gnuplot> plot .0..007 
         internal error : STRING operator applied to non-STRING type


> 3) keyword-less linetype and pointtype options, for compatibility with
>   pre-3.7 gnuplot

This has been a headache for me in trying to maintain order-indepence
of all command options.  I vote for removing this backwards compatibility
and requiring  "lt" or "pt" keywords.

-- 
Ethan A Merritt       merritt@u.washington.edu
Biomolecular Structure Center
Mailstop 357742
University of Washington, Seattle, WA 98195

Re: plot ...007

[<mi...@ph...>]

> Not exactly a bug --- just an unusually surprising feature.
> Essentially, the parser at least accepts:
>
> 1) `.' all on its own as a valid number, equal to 0.0
> 2) tokens without whitespace between them
> 3) keyword-less linetype and pointtype options, for compatibility with
>   pre-3.7 gnuplot
>
> Feature 3) could be removed --- it's never been documented, I think,
> and is obsolete.

You mean "plot x with lp 2 3"? Well, I think this abbreviation is still used.

> Feature 2) is actively being used by people --- you sometimes do see
> example commands like
>
> 	plot 'file'u1:2:3

This makes error, correct is
 	plot 'file'u 1:2:3


I propose that saying "." instead of "0." or ".0" should be an error.
I don't think this abbreviation is supported by any programming language.
This would solve the problem with "plot ..."

---
PM

Re: plot ...007

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

On Wed, 11 Aug 2004 mi...@ph... wrote:

> It has been just discovered by Daniel and me that these commands draw a
> plot (at y=0):
> plot .
> plot ..
> plot ...
> plot ...007
> 
> Isn't this a parser bug?

Not exactly a bug --- just an unusually surprising feature.  Essentially,
the parser at least accepts:

1) `.' all on its own as a valid number, equal to 0.0
2) tokens without whitespace between them
3) keyword-less linetype and pointtype options, for compatibility with
   pre-3.7 gnuplot

So the above commands are parsed to be equivalent to

	plot 0.0
	plot 0.0 lt 0
	plot 0.0 lt 0 pt 0
	plot 0.0 lt 0 pt 0.007

Feature 3) could be removed --- it's never been documented, I think,
and is obsolete.

Feature 2) is actively being used by people --- you sometimes do see 
example commands like

	plot 'file'u1:2:3

So killing this would hurt.  As to 1), I really don't know whether we
should do something about it.

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

plot ...007

[<mi...@ph...>]

It has been just discovered by Daniel and me that these commands draw a
plot (at y=0):
plot .
plot ..
plot ...
plot ...007

Isn't this a parser bug?

---
PM

Re: few remarks

[<mi...@ph...>]

>> "help filledcurves" is not very well understandable.
>
> Well, since you wrote that originally, I guess it's yours to fix it up.

Originally yes, later edited by Ethan. Now I have reread the text and
proposed changes, but I cannot commmit them myself :-(
>> When "make tutorial" (under Linux): File $HOME/.gnuplot should not be
>> read -- it may contain an offending command which breaks the make
>> process.
>>
>> Could the particular pieces of tutorial/Makefile[.am?] contain
>> something like
>> 	HOME=/dev/null gnuplot ...
>
> Feels more like there should be a '--no-startup-files' option (like
> emacs' -q one) to gnuplot.  Futzing around with $HOME, even on a
> temporary basis doesn't feel like a good idea.

Probably only --no-startup-file, or --no-gnuplot-ini (there is always only
one gnuplot.ini / .gnuplot read).
---
PM

Re: background color -- Re: Plot placement, revisited

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

On Monday 09 August 2004 11:01 pm, mi...@ph... wrote:
> I have tried to use it by overprinting a label with "textcolor lt -2" over
> a pm3d plot, but it never used the background (white) color --- I tried
> for postscript, png, x11. Do you have a successful example of the feature?

Yes, certainly.
This was the suggested work-around for filling the area between
two curves up through version 4.0.   It is obsolete now that the
filledcurves style supports filling between curves directly, but it
still works:

    set style func filledcurves y1=0
    plot sin(x)**2 lt 1, 0.5*sin(x)**2 lt -2

(works on at least x11, png and post;   png image attached)

As to text printing, I wasn't thinking in terms of writing text in
the background color. Let me try it ....

Ah, I see.   It explicitly does not let you do this:
set.c:
        if (tc->lt <= LT_NODRAW) {
            tc->type = TC_DEFAULT;
            int_warn(c_token,"illegal linetype");
        }

Well, that's easy enough to fix if you think it's a useful feature.
I guess if someone explicitly sets the text color to background
then they can live with the possibly invisible results.
Test output after changing <= to < in the above check is
also attached as a png image.

I will make this 1-line (actually 1-character) change in cvs.



-- 
Ethan A Merritt       merritt@u.washington.edu
Biomolecular Structure Center
Mailstop 357742
University of Washington, Seattle, WA 98195

Re: grid outside border

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

Hans-Bernhard Broeker wrote:

>On Mon, 9 Aug 2004, Daniel J Sebald wrote:
>
>  
>
>>Sure, but it would have to be done inside the freqz.m file.  
>>    
>>
>
>I thought that was exactly what I said: that since it's this octave script
>that is deciding that the xrange is going to be [0:1.99805], it's the
>script's job to fix it up.
>
>  
>
>>to recognize that 1023/512 is very close to 2.0.  That is why I suggest 
>>some code somewhere that rounds the borders outward to the nearest, say, 
>>1% of the overall width.  
>>    
>>
>
>If you make "somewhere" be that octave script, I can agree with that.
>
>gnuplot already has such code, but by setting an explicit xrange, the
>script is disabling it.
>

The algorithm I'm describing is probably more difficult than just 
rounding to the nearest 1%, or whatever.  One really wants to round up 
(for right border) to nearest 10^p, 10^p-1, 10^p-2, where p is the 
power, or exponent, associated with right border.

But the point is mute, in this case, because actually, now that I think 
about it, that Octave script is kind of lame.  The sample rate is an 
argument of the freqz() routines.  So why not just set the range to 
[0:Fs/2], rather than reading the maximum range from the frequency 
vector?  I'll send a note to the Octave list.

Dan

Re: few remarks

[Lars H. <lhe...@us...>]

 
> > When "make tutorial" (under Linux): File $HOME/.gnuplot should not be read
> > -- it may contain an offending command which breaks the make process.
> > 
> > Could the particular pieces of tutorial/Makefile[.am?] contain something
> > like
> > 	HOME=/dev/null gnuplot ...
> 
> Feels more like there should be a '--no-startup-files' option (like emacs'
> -q one) to gnuplot.  Futzing around with $HOME, even on a temporary basis
> doesn't feel like a good idea.
 
 Agreed, except that I don't want to see long options in order to be
 consistent with what is there already.

Re: few remarks

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

On Tue, 10 Aug 2004 mi...@ph... wrote:

[I'll only comment some of the lots of issues...]

> "help filledcurves" is not very well understandable.

Well, since you wrote that originally, I guess it's yours to fix it
up. ;-)

> postscript terminal contains new option "level2". I propose to add (or
> rather change to) option "level1" -- I guess it is more natural to restrict
> to PS Level 1 printer by saying "set term post level1" rather than
> "set term post nolevel2". (Also, it may become confusing whether
> "PS Level 3" printer is "level2" or "nolevel2").

Agreed.

> When "make tutorial" (under Linux): File $HOME/.gnuplot should not be read
> -- it may contain an offending command which breaks the make process.
> 
> Could the particular pieces of tutorial/Makefile[.am?] contain something
> like
> 	HOME=/dev/null gnuplot ...

Feels more like there should be a '--no-startup-files' option (like emacs'
-q one) to gnuplot.  Futzing around with $HOME, even on a temporary basis
doesn't feel like a good idea.

> Currently I have only web access to internet, so I cannot do any change into
> cvs. 

How long is "currently" expected to last?

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

Re: grid outside border

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

On Mon, 9 Aug 2004, Daniel J Sebald wrote:

> Sure, but it would have to be done inside the freqz.m file.  

I thought that was exactly what I said: that since it's this octave script
that is deciding that the xrange is going to be [0:1.99805], it's the
script's job to fix it up.

> to recognize that 1023/512 is very close to 2.0.  That is why I suggest 
> some code somewhere that rounds the borders outward to the nearest, say, 
> 1% of the overall width.  

If you make "somewhere" be that octave script, I can agree with that.

gnuplot already has such code, but by setting an explicit xrange, the
script is disabling it.

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

few remarks

[<mi...@ph...>]

I had a look to changes in gnuplot cvs code over last >month.
I'd to present few comments:

***

There are new features in gnuplot. It would be nice to keep the NEWS
file up-to-date (write new features and list new files added to demo).

Also, a section "What is new in gnuplot 4.1" should be added to gnuplot.doc
(containing a short form of news with links to docs).

***

File ChangeLog.0: I propose it contains the following text on the first
lines saying:

This is ChangeLog for period from 1998 until gnuplot 4.0 release in April
2004==============================================================================
***

Bug:
On x11 (well, I haven't look to other terminals), points in the points and
linepoints styles are "handicapped" -- look by a screen magnificator (xmag,
kmag) to points obtained by:

set size ratio 1
plot sin(x)/x w point pt 2

***

"help filledcurves" is not very well understandable.
I propose the following:

 The `filledcurves` style is only relevant to 2-d plotting. Three variants
 are possible. The first two take a function or two columns of input data
 file, and may be tuned by options (see below). The default is `closed`, which
 treats the curve itself as a closed polygon. The second variant is to fill the area
 between the curve and a given axis, a horizontal or a vertical line, or a
 point. The third variant requires three columns of input data file: the x
 coordinate and two corresponding y coordinates (two curves); then, the area between the
 two curves is filled.

 Syntax:
 	...

 where the option (the first two variants only) can be

 ...

 Example for the third variant:
 	plot 'data.dat' using 1:3:4 with filledcurves

 Note: ...

***

postscript terminal contains new option "level2". I propose to add (or
rather change to) option "level1" -- I guess it is more natural to restrict
to PS Level 1 printer by saying "set term post level1" rather than
"set term post nolevel2". (Also, it may become confusing whether
"PS Level 3" printer is "level2" or "nolevel2").

****

When "make tutorial" (under Linux): File $HOME/.gnuplot should not be read
-- it may contain an offending command which breaks the make process.

Could the particular pieces of tutorial/Makefile[.am?] contain something
like
	HOME=/dev/null gnuplot ...
?

****

gnuplot.doc contains an example for using new features "title and
xticlabels":
1.
  plot 'datafile' using 1:(f($2)/$4) title 2 with lines

  I guess that a more transparent example could be the same as few lines
  above:

  plot 'datafile' using 3:4 title 2 with lines

  (it is not clear what is f($2), and the result is obviously division, not
  remainder?)


2. In gnuplot.doc, I propose that "help xticlabels" go (reference) to the
  same entry as "help using xticlabels".

***


Currently I have only web access to internet, so I cannot do any change into
cvs. Thus I'd like to ask others to submit my proposed features, if
agreed. Thanks.
---
Petr

background color -- Re: Plot placement, revisited

[<mi...@ph...>]

>> However, is there a color number for background? I.e.
>>    set key opaque color lt -2
>> or like that?
>
> Yes, at least partially.
>
> I went through prior to the version 4.0 release and made
> many terminals honor LT_BACKGROUND (-2) when setting
> a color.  But I could not check all the terminals, and I did not add it
> to the documentation because the work was not complete.> Please feel free to go ahead and test this on os2, windows,
> and the various other terminal types I can't test easily.

I have tried to use it by overprinting a label with "textcolor lt -2" over
a pm3d plot, but it never used the background (white) color --- I tried
for postscript, png, x11. Do you have a successful example of the feature?
> I had vague ideas of making "background" or "bkg" a legal
> linetype specifier, since that is more obvious than saying
>    plot 'data' with boxes lt bkg
> than
>    plot 'data' with boxes lt -2

That could be a constant...

---
PM

Re: grid outside border

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

Hans-Bernhard Broeker wrote:

>>>The test case is quite unrealistic, actually --- users would almost
>>>certainly never make such a choice consciously.
>>>      
>>>
>
>  
>
>>But Octave is the one that chooses it; as part of the freqz() command, 
>>and because I chose the number of FFT points to be a power of 2, for 
>>efficiency.
>>    
>>
>
>Well, then I would suggest it's Octave that needs to be fixed.  If 
>it wants to do all the work by itself, rather than letting gnuplot
>help where it can, then it's Octave's responsibility to get it right.
>
>So let me see, that 1.99805 of yours is actually 1023/512, right? 
>Couldn't you use 1024/512, i.e. 2.0 instead?
>  
>
Sure, but it would have to be done inside the freqz.m file.  The reason 
is that freqz.m generates a multiplot, and once it's generated, one 
can't say

set xrange [0:2]
replot

because only the last plot will be redrawn.  What you are proposing is 
to recognize that 1023/512 is very close to 2.0.  That is why I suggest 
some code somewhere that rounds the borders outward to the nearest, say, 
1% of the overall width.  The reason is that if you fix gnuplot's 
algorithm so that the tic and grid line aren't drawn, it will appear odd 
because it seems so close that tic mark should be there (although 
technically it shouldn't).  But expanding out to a "fractional whole", 
for lack of better phrase" would make things hunky dory.

Of course, the same type of "rounding" operation could be done as part 
of the freqz.m script.

I agree "set xrange [0:2]" would be a sufficient solution.  However the 
multiplot problem complicates matters.

Dan

Re: grid outside border

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

> >The test case is quite unrealistic, actually --- users would almost
> >certainly never make such a choice consciously.

> But Octave is the one that chooses it; as part of the freqz() command, 
> and because I chose the number of FFT points to be a power of 2, for 
> efficiency.

Well, then I would suggest it's Octave that needs to be fixed.  If 
it wants to do all the work by itself, rather than letting gnuplot
help where it can, then it's Octave's responsibility to get it right.

So let me see, that 1.99805 of yours is actually 1023/512, right? 
Couldn't you use 1024/512, i.e. 2.0 instead?

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

Re: grid outside border

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

Hans-Bernhard Broeker wrote:

>On Thu, 5 Aug 2004, Daniel J Sebald wrote:
>
>  
>
>>set xrange [0:1.99805]
>>set grid
>>plot sin(x)
>>set xrange [0:2]     
>>replot
>>set xrange [0:1.99805]
>>replot
>>    
>>

<snip>

>SIGNIF is 0.01, and that's the whole story.  It would be tempting to just
>get rid of that line fiddling around with 'end', but I doubt that's a
>smart idea --- I'm quite sure this line was put there for a good reason.
>The test case is quite unrealistic, actually --- users would almost
>certainly never make such a choice consciously.
>

But Octave is the one that chooses it; as part of the freqz() command, 
and because I chose the number of FFT points to be a power of 2, for 
efficiency.

>>If you run gnuplot without the -nofeedback option, the feedback will 
>>slightly readjust the x length and the rounding will behave differently. 
>>    
>>
>
>If so, that's another likely bug.
>

It's not a bug, gnuplot_x11 is being fed a tic position slightly outside 
the border position, it just happens that when quantized, these two 
positions map to the same x-pixel location.

Dan

Re: grid outside border

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

On Thu, 5 Aug 2004, Daniel J Sebald wrote:

> set xrange [0:1.99805]
> set grid
> plot sin(x)
> set xrange [0:2]     
> replot
> set xrange [0:1.99805]
> replot
> 
> You should notice this behavior on the right border toggling back and 
> forth.  So, yes it does seem that the border is being drawn a pixel to 
> the left because of the 1.99805.  

No.  The border is drawn at exactly the same place in all cases.  The bug
here is that there should simply be no tick, and thus no grid line either,
at x==2.0 if the range is [0:1.998].  And yes, that is a rounding problem.
It's the line just above the two comments of mine you already pointed out.
Citing gen_tics(), axis.c:1047:

        /*{{{  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;
        }

SIGNIF is 0.01, and that's the whole story.  It would be tempting to just
get rid of that line fiddling around with 'end', but I doubt that's a
smart idea --- I'm quite sure this line was put there for a good reason.
The test case is quite unrealistic, actually --- users would almost
certainly never make such a choice consciously.  The code may accidentally
run into even narrower misses by numerical inaccuracy though (e.g. in the
case at hand, 2.0 +/- 10 * DBL_EPSILON would be likely), and has to
protect against those.

In other words: this failure of the code to behave properly is largely
caused by the requirements having changed since we added zooming by mouse.  
Before that, users would have known better than to select such a strange
range endpoint, or they would have been using autoscaling, which would
have rounded an endpoint of 1.99805 to 2.0 before it could cause any
trouble.

So, what I guess this means is that mouse zooms should be polished some,
before being used, just like autoscaled data ranges are.

> If you run gnuplot without the -nofeedback option, the feedback will 
> slightly readjust the x length and the rounding will behave differently. 

If so, that's another likely bug.

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

Re: Stupid bug if filename begin with whitespace

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

On Sat, 7 Aug 2004, Ethan Merritt wrote:

> I have removed this "feature" from the two places that used it.
> Is it important enough to remove whitespace that we should have a
> separate, more correct, routine that does so and share it for all
> places that a filename is read in?

As far as I'm concerned, we might just as well exit(EXIT_FAILURE)
immediately as any filename with leading whitespace is entered by the user
--- that's exactly the correct reaction to anybody trying to do such a
silly thing.  Whitespace in the interior of filenames is quite silly
already, but leading (or trailing) whitespace is just *begging* for
punishment.

I guess the original code was trying to be helpful here.  But unless
this was a documented feature, I guess we can safely remove it.

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

Stupid bug if filename begin with whitespace

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

Stupid bugs in set.c:

gnuplot> set output "   outfile"
gnuplot> set output "   die"
Segmentation fault (core dumped)

and similarly for 'set print'.
The code was very sloppy; it allocated a string to hold the filename,
and then advanced the string pointer over the initial whitespace.
When the string is freed, boom!

I have removed this "feature" from the two places that used it.
Is it important enough to remove whitespace that we should have a
separate, more correct, routine that does so and share it for all
places that a filename is read in?

Re: grid outside border

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

I looked into this issue of the grid line and tics to the right of the 
right border.  There is a lot of code for the tics, and I notice a 
comment in the code:

    /* FIXME HBB 20010121: keeping adding 'step' to 'tic' is
     * begging for rounding errors to strike us. */
    /* HBB 20010410: ... and strike they did :-( */

So there is probably an issue having to do with that.  Of course, one 
thing that could be done is a sanity check to make sure no tics are 
drawn if outside xleft, xright, xbot, xtop.  But those variables are not 
in the same C file....  Also, there should be a bit of code that would 
round the border up to 2.0 if [0:1.99805].  What I mean, is that the 
range should probably be rounded to the nearest, oh, 1/2% of the length. 
 That is, when it comes to the final computation of the range, treat 
1.99805 as follows

xmax - xmin = 1.99805

(xmax - xmin)*0.005 = 0.0099903

which means we should round to the nearest 0.01, i.e. 1.99805 rounds to 
2.0.  It is a little bit difficult to imagine an elegant algorithm to do 
this, but it may involve working with the exponents of floats in 
exponential notation.  (Can't think of any C constructs to do that.)  Or 
perhaps working with logarithms.

Not proposing this be done, but I hope you catch my drift.

Dan

Re: grid outside border

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

OK, I think I have narrowed this down.  It has to do with the xrange 
being slightly less than a whole number.  You may or may not feel this 
is gnuplot's problem or Octave should be worrying about this.  I'll just 
describe it.

Launch gnuplot with the -nofeedback option.  Then type the following set 
of commands:

set xrange [0:1.99805]
set grid
plot sin(x)
set xrange [0:2]     
replot
set xrange [0:1.99805]
replot

You should notice this behavior on the right border toggling back and 
forth.  So, yes it does seem that the border is being drawn a pixel to 
the left because of the 1.99805.  So I guess the question is whether a 
grid line should be drawn at all in this scenario.  It probably has 
something to do with rounding.

If you run gnuplot without the -nofeedback option, the feedback will 
slightly readjust the x length and the rounding will behave differently. 
 But if you move your x-window about a bit, in some locations you should 
see the right border shifted slightly to the left.  I guess what I'm 
saying is that on your particular system, if you run "gnuplot 
-nofeedback" and then

set xrange [0:1.99805]
set grid
set term png
set output 'junk.png'
plot sin(x)
set output

You should get a PNG file with the aberration.  Your X11 system may 
behave slightly different depending upon your system settings.

Unless someone wants to tackle this now, I think in the next couple days 
I'll put it in SourceForge bug list along with a couple other items 
before I forget them.

Dan