Re: Bug #1503114

[Ethan M. <merritt@u.washington.edu>]

May I propose that we just drop this patch [*], and put the
effort into discussion of more serious issues?

At a minimum, we need to resolve:

  - Reconciling the docs and the code with regard to the various
    flavors of missing/undefined data points

  - Does Windows truly require the PostScript prolog files to
    be moved back into the driver source?

  - Finalize and include the "user-available GPVAL_*" patch,
    #1488448, which I think is waiting on Hans-Bernhard's offer
    to identify the appropriate variables for export from=20
    fitting.

  - The Makefiles and config files for the non-autobuild
    platforms need to be checked for correctness and inclusion
    of the newer configuration options.

And then there's the nuts-and-bolts requirement to go over the
full manual and make sure it is up to date in referring to=20
version numbers, available features, syntax examples, and so on.

It would also be nice if someone familiar with the fitting code
would comment on  #1445064 "Gnuplot fitting improvements".
The description sounds reasonable, but I have not looked at
the patch itself, and I am not at all familiar with that part
of the code base.


	Ethan

[*] The truth is, I already dropped it last week on the basis of=20
unfavorable comments on the mailing list.

	Ethan


On Tuesday 20 June 2006 03:45 pm, Daniel J Sebald wrote:
> Hans-Bernhard Br=F6ker wrote:
> > 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.=20
> > 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].=20
> > You say that delta=3D1e-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=3D1e-7 and, say, delta=3D1e-2,
> > the output range *will* jump to 2.5.  Maybe that jump is at
> > delta=3D1e-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.
>
> You are making a good point.  Currently, the user sees the big jump
> and knows 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 TOL 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
> next 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, whatever your viewpoint) a small fraction of the total range.
>  Likely something 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
> problems.  Case 2?  Probably, but not as assured for some reason.
>
> Case 2 is predictable in the sense all it will catch is some rounding
> issues.  Case 1 *is* less predictable, but I think the concept is
> understandable.
>
> Going back to your original point.  The jump tells someone their data
> extends 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
> concept or two there that seems not so confusing.
>
> Dan
>
>
>
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> https://lists.sourceforge.net/lists/listinfo/gnuplot-beta

=2D-=20
Ethan A Merritt
Biomolecular Structure Center
University of Washington, Seattle WA