Re: Bug #1503114

[Daniel J S. <dan...@ie...>]

Hans-Bernhard Br=F6ker wrote:
> Daniel J Sebald wrote:
>=20
>>> 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.
>=20
>=20
> Just think of it this way: at some point, the actual endpoint of the=20
> range *will* jump from 2.0 to, e.g., 2.5.  With the existing code this=20
> happens exactly if the end of the data range is larger than 2.0.  That'=
s=20
> by far the clearest and most simple way of doing it.  With the proposed=
=20
> modifications the jump would be elsewhere --- and with all the differen=
t=20
> suggestions being made, it's by now entirely unclear where that is.
>=20
> So the jump won't magically go away --- it just moves to a different=20
> position on the input axis.  I refuse to see that as an improvement.=20
> Especially not if we can't even explain it clearly to each other, much=20
> less to unsuspecting users, where that new position is actually suppose=
d=20
> to be, and why it should be exactly there.
>=20
>>> Floating-point rounding is tricky stuff.  It's completely inevitable=20
>>> that sometimes, results will surprise people.  All this patch does is=
=20
>>> move the surprise from a seemingly obvious place to a less obvious=20
>>> one.  An axis ending at 2.0000001 has no more business being=20
>>> artificially cut down to 2.0 than one ending at 2.001.
>>
>>
>> I think it does in some cases, and depends on the range. =20
>=20
>=20
> It depends on entirely too much, IMHO.
>=20
>> 1) [1.9999999 : 2.0000001]
>>
>> 2) [-2.0 : 2.0000001]
>>
>> In the first case, yes definitely, the limits have no business being=20
>> artificially shrunk.
>>
>> However, in the second case I'm saying that cutting the upper limit=20
>> inward to 2.0 rather than rounding outward to 2.5 is not egregious=20
>> because its effect is beyond the resolution of the plot. =20
>=20
>=20
> Maybe.  But as I said, that just moves the problem elsewhere.  There=20
> *will* be some threshold for which a data range of
>=20
>     [-2.0: 2.0+delta]
>=20
> jumps from an auto-extended axis range of [-2:2.0] to [-2:2.5].  You sa=
y=20
> that delta=3D1e-7 should be below the threshold --- but that wilfully=20
> turns a perfectly valid data point into an out-of-bounds one.   And at=20
> some point between delta=3D1e-7 and, say, delta=3D1e-2, the output rang=
e=20
> *will* jump to 2.5.  Maybe that jump is at delta=3D1e-3 or at 1e-5, it=20
> doesn't really matter.   It's still a jump, and somebody will have to=20
> explain to himself or a puzzled user why that range endpoint made such =
a=20
>  huge jump.  As is, that explanation is simple: the actual range was=20
> larger than 2.0, so gnuplot made room for that.  Now you explain why=20
> your threshold is exactly where it ends up to be --- and why the same=20
> data, with the same settings, yield a different range endpoint on=20
> different terminal drivers.

You are making a good point.  Currently, the user sees the big jump and k=
nows right away that his or her data goes beyond the range they may have =
thought.  Even thought they may not be able to see it.  Very predictable =
behavior.

Just to clarify, I'm saying that delta is not chosen as a fixed value.  I=
'm trying to relate that delta to the range.  For example, let's choose T=
OL to be tolerance and set that at 1/1000.  Now, the formula would be

delta =3D TOL * abs(xmax - xmin)

and in this case would be delta =3D abs(2 - (-2)) * 1/500 =3D 0.004.  So =
if the value to be rounded outward is within -2.004 but not above the nex=
t highest tic mark, the value is rounded to -2.  Likewise, the same thing=
 that within 2.004 is rounded down to 2.0.

Now, pick a range like [-1.9999:2.0001].  From the formula above, epsilon=
 now is 2e-7.

There are only two valid concepts in my mind.

1)  What I just described, which is ignore anything within (or beyond, wh=
atever your viewpoint) a small fraction of the total range.  Likely somet=
hing so small it can't be resolved.

2)  Ignore anything within the machine resolution (i.e., epsilon) or some=
 small multiple of machine resolution, what Petr pointed out.

I'm fairly certain case 1 will catch any machine arithmetic rounding prob=
lems.  Case 2?  Probably, but not as assured for some reason.

Case 2 is predictable in the sense all it will catch is some rounding iss=
ues.  Case 1 *is* less predictable, but I think the concept is understand=
able.

Going back to your original point.  The jump tells someone their data ext=
ends beyond a tic, but in a perhaps imperceptable way.  (We could do some=
 examples to test this.)

I don't know what the preference would be, honestly.  But there is a conc=
ept or two there that seems not so confusing.

Dan