Re: wxt mouse scrolling anomalies

[sfeam (E. Merritt) <eam...@gm...>]

On Saturday, 10 November 2012, pl...@pi... wrote:
> On 11/10/12 20:03, sfeam (Ethan Merritt) wrote:
> > On Saturday, 10 November 2012, pl...@pi... wrote:
> >
> >> Actually,I'm getting some very odd things happening here.
> >>
> >> Firstly , being still half asleep it typed in some data with commas and
> >> did not get what I intended (so not bug yet)
> >>
> >> gnuplot> f(x)=0
> >> gnuplot> plot "-" w l , f(x)
> >> input data ('e' ends) > -50,1
> >> input data ('e' ends) > 0, 1
> >> input data ('e' ends) > 50, -1
> >> input data ('e' ends) > e
> >>
> >>           set xrange [ 0.00000 : 2.00000 ] noreverse nowriteback
> >>           set yrange [ -60.0000 : 60.0000 ] noreverse nowriteback
> >
> > OK. So you have set explicit ranges.
> 
> No. That was the output from "show all" command, showing what gnuplot 
> had selected automatically.

I am mystified.
That output indicates that you somehow set an explicit range.
If it were in autoscale mode, the output would look like this:

        set xrange [ * : * ] noreverse nowriteback  # (currently [-60.0000:60.0000] )
        set yrange [ * : * ] noreverse nowriteback  # (currently [-1.00000:1.00000] )

> All my commands were  as indicated by the prompts.

Can't be.  
Did you maybe have commands in ~/.gnuplot ?
Did you perform a zoom operation with the mouse?

> >> Then I entered what I intended.
> >>
> >> gnuplot> plot "-" w l , f(x)
> >> input data ('e' ends) > -50 -1
> >> input data ('e' ends) > 0 1
> >> input data ('e' ends) > 50 -1
> >> input data ('e' ends) > e
> >>
> >>
> >> However , this did not rescale, I got what appeared to be two flat lines
> >> with the ranges still as shown above.
> [snip]
> >> No amount of replot, rescale etc seems to correct this
> [snip]
> >
> > Did you really mean to say that the "replot" command does not prompt you
> > to type in the data from "-" again?  That would be a bug.
> 
> No, that's not what I meant to say, but it would be accurate to say that 
> I was not prompted to re-enter the data.

I guess I'm still not understanding.
You typed "replot" but it did not prompt you to re-enter the data?
I go back to being mystified as to how this could happen given
the command sequence you described.


> >> So it seems that  scolling , which implies setting an explicit range
> >> instead of auto, changes the way the function limits are determined.
> >
> > No, or at least I don't think of it that way.
> > The hot-keys, scrolling, and rotation in 3D all try to use "refresh"
> > rather than "replot" to avoid triggering a full re-read of all input on
> > each event. For large input files or for substantial computation made on
> > the input values, this can make a huge difference in responsiveness.
> > And of course for input from the command line via "-" it is not possible
> > to reread.
> >
> > You can always force a full "replot" including reevaluation of the
> > input data if you want to.  That would also cause it to resample any
> > functions using the current active domain on X.
> 
> The problem I was seeing here was not that I wanted to resample the 
> funtion but that when it did so, it was not in a consistent way with the 
> initial plot command.
> 
> Because the data was [-50:50] the function was plotted over the same 
> range as the data and autoscale (during the initial plot command) 
> created [-60:60] xrange.

That's what I would have expected, but that's not what is indicated
by the output you showed above.

> 
> Recalculation of the grid, implicit as result of the scoll, then caused 
> the function to be plotted over the full  [-60:60] xrange.
> This was a) inconsistent; b) problematic since the function was 
> ill-defined outside the intended range and was not suitable to be plotted.

I agree that a function with domain restrictions could be an issue. 
But in general if the function is not defined at a sample point it just
causes a gap in the plotted line, which is harmless other than wasting
some of the sampling resolution on portions of the domain that do not
contribute to the plot.

> I would expect a scroll operation to do no more than move what I have 
> and fill in the gaps.

That's exactly what it does if the data comes from '-'.
On the other hand if the same data comes from a file, and you have not
done 'set datafile volatile', then yes, the scrolling operation 
triggers both a re-read of the data file and resampling of the function
to span the current domain on x.  For your test case with f(x)=0 I think
that is the expected behaviour.  It means that the line at y=0 is
always present even if the data from the file has scrolled out of range.
Picking a function with domain restrictions, e.g. f(x)=log(x) means
that as you scroll off to negative x the function disappears also.
That also is as expected, no?

> It seems untidy and unhelpful that , when I do the smallest scroll, 
> functions get plotted over a different range and the grid starts jumping 
> about and changing the tic internal.

You mean if you zoom?  
I have never noticed that happen on a pure scroll event.
As I said before, I can imagine tripping over a pathological case
where the change in range causes such an effect, but I'd need a
reproducible test case to investigate further.

Do you see the same in current CVS?
I apologize for having to ask, since I generally hate responding to bug
reports with "please try the latest version" unless I already know that
something relevant has been fixed.  And in this case I don't know of any
relevant change since Feb/Mar 2012, when there was indeed a change to
the wxt terminal code handling horizontal scolling events.  But that
change is in the 4.6.1 release also, so if there is a difference between
4.6.1 and what you are seeing then it must lie somewhere else.

	Ethan