Re: Bug #1503114

[<br...@ph...>]

Daniel J Sebald wrote:
>> Not really.  You just hid it in a spot where it's harder to trigger.
> 
> I'm still debating with myself if this is the case.

Just think of it this way: at some point, the actual endpoint of the 
range *will* jump from 2.0 to, e.g., 2.5.  With the existing code this 
happens exactly if the end of the data range is larger than 2.0.  That's 
by far the clearest and most simple way of doing it.  With the proposed 
modifications the jump would be elsewhere --- and with all the different 
suggestions being made, it's by now entirely unclear where that is.

So the jump won't magically go away --- it just moves to a different 
position on the input axis.  I refuse to see that as an improvement. 
Especially not if we can't even explain it clearly to each other, much 
less to unsuspecting users, where that new position is actually supposed 
to be, and why it should be exactly there.

>> Floating-point rounding is tricky stuff.  It's completely inevitable 
>> that sometimes, results will surprise people.  All this patch does is 
>> move the surprise from a seemingly obvious place to a less obvious 
>> one.  An axis ending at 2.0000001 has no more business being 
>> artificially cut down to 2.0 than one ending at 2.001.
> 
> I think it does in some cases, and depends on the range.  

It depends on entirely too much, IMHO.

> 1) [1.9999999 : 2.0000001]
> 
> 2) [-2.0 : 2.0000001]
> 
> In the first case, yes definitely, the limits have no business being 
> artificially shrunk.
> 
> However, in the second case I'm saying that cutting the upper limit 
> inward to 2.0 rather than rounding outward to 2.5 is not egregious 
> because its effect is beyond the resolution of the plot.  

Maybe.  But as I said, that just moves the problem elsewhere.  There 
*will* be some threshold for which a data range of

	[-2.0: 2.0+delta]

jumps from an auto-extended axis range of [-2:2.0] to [-2:2.5].  You say 
that delta=1e-7 should be below the threshold --- but that wilfully 
turns a perfectly valid data point into an out-of-bounds one.   And at 
some point between delta=1e-7 and, say, delta=1e-2, the output range 
*will* jump to 2.5.  Maybe that jump is at delta=1e-3 or at 1e-5, it 
doesn't really matter.   It's still a jump, and somebody will have to 
explain to himself or a puzzled user why that range endpoint made such a 
  huge jump.  As is, that explanation is simple: the actual range was 
larger than 2.0, so gnuplot made room for that.  Now you explain why 
your threshold is exactly where it ends up to be --- and why the same 
data, with the same settings, yield a different range endpoint on 
different terminal drivers.

>> The current behaviour may not be free from surprises, but at least it's
>> correct: an autoscaled axis always contains all its inputs.
> 
> Define correct when we are talking that scale of things.  

We're talking about a plotting program.  It's job is to put data onto 
the plot.  Not outside of it.  Not even by a small margin of error --- 
at least not on purpose.  The whole job of autoscaling is to determine 
an axis range that contains all the input data points.  Your proposed 
changes effectively break the single promise 'set autoscale' exists for.