Re: [ 1004754 ] Tics and grid slightly outside border.

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

I just about have a patch together for this.  I don't think this SIGNIF a=
nd stuff is necessary.  I think this is what you were referring to before=
 about resolution sorts of this propogating about.

The idea here is to overlay a series of tics, major AND minor, to cover t=
he viewable range, or the range specified by the user that is within the =
viewable range.  Because we want to include minor tics, that means we sho=
uld push the minor tics out one further than what is visible on the plot.

>From there, generate the tic (major or minor); if it is in the visible ra=
nge plot it otherwise don't.

There are more elegant ways of dealing with precision problems.  For exam=
ple, rather than doing this:

	if (start > end) {
	    /* put in order */
	    double numtics =3D floor((end * (1 + SIGNIF) - start) / incr);

	    end =3D start;
	    start =3D end + numtics * incr;
	    incr =3D -incr;
	}

how about

	if (start > end) {
	    /* put in order */
	    double numincr =3D floor((end - start) / incr);

	    /* Deal with rounding issues this way */
	    if (start + (numincr + 1) * incr >=3D end)
		numincr++;

	    end =3D start;
	    start =3D end + numincr * incr;
	    incr =3D -incr;
	}


Hans-Bernhard Br=F6ker wrote:

> It would be easy to compute, sure.  Unfortunately, it can just as easil=
y=20
> be way off.  Especially where floating point maths close to its limit o=
f=20
> precision is involved:
>=20
>>   =3D> fabs((start + step) - start) < (step * 0.01)
>>   =3D> fabs(step) < (step * 0.01)
>=20
>=20
> That last line does *not* follow from the one above.  Not where=20
> floating-point arithmetic reigns.

Well, sure the case where start + step =3D start because of loss of resol=
ution.  But is that a situation where there will be a meaningful plot?  I=
t seems a convoluted way of deal with resolution problems.

I think we can get away from having to use such things.  I'll upload the =
patch this evening some time.

Dan