Menu
▾
▴
gnuplot-beta
|
From: <pl...@pi...> - 2012-11-09 10:39:52
|
Hi , recent cvs gnuplot: I've just noticed that mouse scrolling window in wxt causes functions to be replotted full width , not with in the limits of data as in initial plot. Also grid gets calculated to grossly different tic intervals on just one scroll event in either direction. eg my plot auto scales to [-1:+1] and gets 0.2 intervals. Or scroll it gets 0.5 intervals. Autoscale button fixes it , replot button/command, no. I would have expected scroll to do no more that move what is already there. I don't recall seeing either of these before (though the function range may not always be obvious). Previously running prob 6m old CVS. datafile has data in range [-50:50] which autoscales to [-60:60] f(x)=0 plot datafile, f(x) Best regards, Peter. |
|
From: Mojca M. <moj...@gm...> - 2012-11-09 15:45:50
|
On Fri, Nov 9, 2012 at 12:13 AM, <pl...@pi...> wrote:
> Hi ,
>
> recent cvs gnuplot:
>
> I've just noticed that mouse scrolling window in wxt causes functions
> to be replotted full width , not with in the limits of data as in
> initial plot.
Others will be able to answer better, but the functionality has indeed
been changed. If I used
plot [0:] f(x)
in the old version and tried to zoom into some region to see more
details - say, between [3:4] - then gnuplot would zoom into [0:4].
If I then tried to shift, gnuplot would zoom in and out to keep the
condition [0:] valid instead of shifting the data.
I'm not sure if I understood what exactly is going on in your case.
The old functionality was weird, but it is possible that there are
cases when the new functionality also functions wrong.
Mojca
|
|
From: sfeam (E. Merritt) <eam...@gm...> - 2012-11-09 17:17:58
|
On Friday, 09 November 2012, pl...@pi... wrote: > Hi , > > recent cvs gnuplot: > > I've just noticed that mouse scrolling window in wxt causes functions > to be replotted full width , not with in the limits of data as in > initial plot. > > Also grid gets calculated to grossly different tic intervals on just one > scroll event in either direction. eg my plot auto scales to [-1:+1] and > gets 0.2 intervals. Or scroll it gets 0.5 intervals. > > Autoscale button fixes it , replot button/command, no. I am not seeing any of that here. So I really can't say what might be going wrong. > I would have expected scroll to do no more that move what is already > there. Well no, that's not how it works. If it did that it would show blank space in the area that enters your field of view. Instead it adds some incremental amount to the upper/lower axis range and replots. I can see how there may be certain cases for which that could change the tic interval, but I haven't noticed it being a problem in practice. > I don't recall seeing either of these before (though the function > range may not always be obvious). Previously running prob 6m old CVS. I don't see anything much related to scrolling in the ChangeLog for the last 6 months. What "last modified" date is reported when you start the program? > datafile has data in range [-50:50] which autoscales to [-60:60] > > f(x)=0 > plot datafile, f(x) I tried that. Nothing special happened with regard to scrolling. |
|
From: <pl...@pi...> - 2012-11-10 08:01:24
|
On 11/09/12 18:17, sfeam (Ethan Merritt) wrote:
> On Friday, 09 November 2012, pl...@pi... wrote:
>> Hi ,
>>
>> recent cvs gnuplot:
>>
>> I've just noticed that mouse scrolling window in wxt causes functions
>> to be replotted full width , not with in the limits of data as in
>> initial plot.
>>
>> Also grid gets calculated to grossly different tic intervals on just one
>> scroll event in either direction. eg my plot auto scales to [-1:+1] and
>> gets 0.2 intervals. Or scroll it gets 0.5 intervals.
>>
>> Autoscale button fixes it , replot button/command, no.
>
> I am not seeing any of that here.
> So I really can't say what might be going wrong.
OK, I'll try to create a minimalistic test case that reproduces the problem.
>
>> I would have expected scroll to do no more that move what is already
>> there.
>
> Well no, that's not how it works. If it did that it would show blank
> space in the area that enters your field of view. Instead it adds some
> incremental amount to the upper/lower axis range and replots.
> I can see how there may be certain cases for which that could change
> the tic interval, but I haven't noticed it being a problem in practice.
Yes, obviously blank area has to be filled. I meant that the
presentation of the data would remain the same ie the grid does not get
recalibrated and funtions don't start getting rendered with different
end points.
>
>> I don't recall seeing either of these before (though the function
>> range may not always be obvious). Previously running prob 6m old CVS.
>
> I don't see anything much related to scrolling in the ChangeLog
> for the last 6 months.
> What "last modified" date is reported when you start the program?
G N U P L O T
Version 4.7 patchlevel 0 last modified 2012-10-16
Build System: Linux i686
>
>> datafile has data in range [-50:50] which autoscales to [-60:60]
>>
>> f(x)=0
>> plot datafile, f(x)
>
> I tried that. Nothing special happened with regard to scrolling.
>
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
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.
Then I hit the autoscale button (wxt) and got my triangular data line
but the function f(x) was only plotted over its previous x extent of 0:2
and was I tiny segment on the now correct ranges:
set xrange [ * : * ] noreverse nowriteback # (currently
[-60.0000:60.0000] )
set yrange [ * : * ] noreverse nowriteback # (currently
[-1.00000:1.00000] )
No amount of replot, rescale etc seems to correct this, so there is a
difference of behaviour here for in line data rather than a file. (Can't
re-read pipe I guess).
Now if I put the same data in a text file I can reproduce what I
originally reported:
gnuplot> !cat "fx_test.dat"
-50 -1
0 1
50 -1
plot "fx_test.dat" w l , f(x)
That test case plots the function to the width of the data on initial
display and on autoscale button but any scroll event will cause the
function to be plotted full with of x axis.
So it seems that scolling , which implies setting an explicit range
instead of auto, changes the way the function limits are determined.
regards, Peter.
|
|
From: sfeam (E. Merritt) <eam...@gm...> - 2012-11-10 19:03:34
|
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.
>
> 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.
Yes.
> Then I hit the autoscale button (wxt) and got my triangular data line
What's an "autoscale button"? Do you mean the hot-key "a"?
> but the function f(x) was only plotted over its previous x extent of 0:2
> and was I tiny segment on the now correct ranges:
By default if you rescale/refresh a plot created from volatile
(cannot be re-read) data, then it uses the values already stored internally.
In your case this includes the function data sampled over the range [0:2].
> No amount of replot, rescale etc seems to correct this, so there is a
> difference of behaviour here for in line data rather than a file. (Can't
> re-read pipe I guess).
Yes, although actually an input pipe and a file act the same in this case.
It is the difference between "refresh", which re-uses the existing data,
and "replot" which goes back and reexecutes the previous plot command
including reading from the data sources. The program knows that it can't
re-read from "-" so it automatically tries to avoid "replot".
You can force the same behaviour for a data file or input pipe using
set datafile volatile
This can be useful for example if the data source is changing in realtime
but you want to zoom the currently visible display rather than
replacing it with new data.
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.
> 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.
I suppose it might be reasonable to have "refresh" trigger resampling
of 2D functions. It would be computationally intensive in 3D, however,
and hammer the responsiveness of mouse interaction.
Ethan
|
|
From: <pl...@pi...> - 2012-11-10 21:54:45
|
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.
All my commands were as indicated by the prompts.
>
>>
>> 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.
>
> Yes.
>
>> Then I hit the autoscale button (wxt) and got my triangular data line
>
> What's an "autoscale button"? Do you mean the hot-key "a"?
" autoscale button (wxt)" is the button in wxt terminal with the hover
hint "Apply autoscale".
>
>> but the function f(x) was only plotted over its previous x extent of 0:2
>> and was I tiny segment on the now correct ranges:
>
> By default if you rescale/refresh a plot created from volatile
> (cannot be re-read) data, then it uses the values already stored internally.
> In your case this includes the function data sampled over the range [0:2].
>
>> No amount of replot, rescale etc seems to correct this, so there is a
>> difference of behaviour here for in line data rather than a file. (Can't
>> re-read pipe I guess).
>
> Yes, although actually an input pipe and a file act the same in this case.
> It is the difference between "refresh", which re-uses the existing data,
> and "replot" which goes back and reexecutes the previous plot command
> including reading from the data sources. The program knows that it can't
> re-read from "-" so it automatically tries to avoid "replot".
> You can force the same behaviour for a data file or input pipe using
> set datafile volatile
> This can be useful for example if the data source is changing in realtime
> but you want to zoom the currently visible display rather than
> replacing it with new data.
>
> 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.
>
>> 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.
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.
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.
I would expect a scroll operation to do no more than move what I have
and fill in the gaps.
Peter.
>
> I suppose it might be reasonable to have "refresh" trigger resampling
> of 2D functions. It would be computationally intensive in 3D, however,
> and hammer the responsiveness of mouse interaction.
>
> Ethan
>
>
|
|
From: sfeam (E. Merritt) <eam...@gm...> - 2012-11-10 22:59:59
|
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
|
|
From: <pl...@pi...> - 2012-11-11 08:30:13
|
On 11/10/12 23:59, sfeam (Ethan Merritt) wrote:
> 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
>
>
OK, let's start from the top to make sure I'm not misreporting something.
ls ~/.gnuplot
No such file or directory
fresh gnuplot session, repeat my initial erroneous input:
$ gnuplot
G N U P L O T
Version 4.7 patchlevel 0 last modified 2012-10-16
Build System: Linux i686
...
Terminal type set to 'wxt'
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
[NO mouse interaction on graph}
show all
...
set xrange [ * : * ] noreverse nowriteback # (currently
[0.00000:2.00000] )
set yrange [ * : * ] noreverse nowriteback # (currently
[-60.0000:60.0000] )
That is the expected behaviour. Yet the first time I just did this I got
an explicit range again. Now I'm confused :? The wxt window came up
under the cursor on top of my xterm, was I inadvertently doing a mouse
scroll ???
At this point replot command does prompt for input. The replot button in
wxt does not. That is the source of that confusion. I did not say
"replot command" and you assumed I did , I did not say "replot button"
and I should have been more precise. I did not realise that the replot
button did not do a replot command !!
Now repeating the correct data entry as previously reported:
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
Now when scrolling, the function range stays locked to the data range as
I would expect.
This is NOT what I was seeing yesterday and that I repeated a dozen
times to verify what I was seeing , so there must be some other factor
that I had not eliminated.
I'll go back to my real data processing and try to find out what
triggers this defective behaviour.
There is something odd happening in a longer gnuplot session. That could
make it tricky to pin down.
Sorry, this test case was not sufficient.
Peter.
|
