Re: Bug #1503114

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

Hans-Bernhard Br=F6ker wrote:
> Daniel J Sebald wrote:
>=20
>=20
>>There are only two valid concepts in my mind.
>>
>>1)  What I just described, which is ignore anything within (or beyond,=20
>>whatever your viewpoint) a small fraction of the total range.  Likely=20
>>something so small it can't be resolved.
>=20
>=20
> And the trouble with that is that "can't be resolved" is a criterion=20
> that by its very definition depends on information that the autoscaling=
=20
> algorithm can't have.  The actual resolution of the eventual output=20
> device of a plot may not even be known at 'plot' time, much less can=20
> autoscaling be allowed to depend on it.

Well, I'm not sure on that.  Set the resolution to 20000 by 20000.  Then =
a ticmark will be 1/20000?  If so, that is not viewable.  You'd have to f=
orce a tic mark to be five or more pixels.  I mean, sure perhaps there is=
 a reason for such a high resolution, say a person wants to create a conf=
erence poster and be able to resolve something in a little corner of the =
plot.

My point here is that I think there is an inherent amount of visual plott=
ing information that a person can view.  I'm confortable with the idea of=
 limits on resolution.


> BTW: gnuplot has a parameter like your proposed "tolerance":  set zero.
> But it's being used less and less in the actual code, and I think that'=
s=20
> a good thing.
>=20
>=20
>>2)  Ignore anything within the machine resolution (i.e., epsilon) or=20
>>some small multiple of machine resolution, what Petr pointed out.
>=20
>=20
> Machine resolution is quite certainly the wrong way of doing this.=20
> That's the smallest value for your "TOL" parameter that's=20
> distinguishable from zero at all, effectively --- the only useful=20
> application of it would be sanity-check a 'set tolerance'.

The idea would be to reasonably catch the situation where the tic interva=
l is computed as 1/3 =3D 0.33333333333 and then the round outward test do=
es something (after arithmetic) like deciding  0.999999999999 < 1.0 becau=
se of rounding.


> I still hold that
>=20
> 3) zero tolerance --- keep it small and simple
>=20
> is the right way to go.
>=20
>=20
>>Going back to your original point.  The jump tells someone their data=20
>>extends beyond a tic, but in a perhaps imperceptable way.  (We could do=
=20
>>some examples to test this.)
>=20
>=20
> ... and if that really bothers some user, he can always easily fix that=
=20
> range manually (or, if he dislikes this jumpiness altogether, put 'set=20
> autoscale xfix' in his ~/.gnuplot).

I know.


>>I don't know what the preference would be, honestly. =20
>=20
>=20
> Let me put it this way: that behaviour, and those demos, have been=20
> around for years, some of them decades.  IIRC, we've had a total of=20
> about one complaint about that, in all that time.

OK.  Did you want to change the demos and set the ranges in a few cases? =
 I mean, I have wondered in the past why some of the pm3d demos have a wh=
ite area near the bottom of them.  They do look better without the gap in=
 this case.

Dan