gnuplot-beta

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: 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:

>>>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...>]

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.

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: 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