On 11/10/12 23:59, sfeam (Ethan Merritt) wrote:
> On Saturday, 10 November 2012, plotter@... wrote:
>> On 11/10/12 20:03, sfeam (Ethan Merritt) wrote:
>>> On Saturday, 10 November 2012, plotter@... 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.
|