An extremum is found on the function, not on the sampling
An extremum marked on a curve is now a property of the function, not of the
sampling. Reported by a reader of the plugin, and reported precisely.
What was wrong
The engine walks a curve at a finite step and draws the result as a polyline. An
extremum was taken to be a vertex of that polyline - the nearest computed point,
not the extremum itself.
Three things followed, and all three were noticed:
- for
y = x*xthe answer was not zero, and it did not agree with the value the
report printed for that point; - the mark moved when the window or the quality changed, because the grid of
computed points moved with them; - raising the accuracy tightened the grid and brought the answer closer without
ever reaching it.
What it does now
The vertex of the polyline only opens the search. It gives a bracket of three
points, and inside that bracket the extremum is found on the function itself by
ternary search. What comes back is the point on the curve, not the sample that
happened to be nearest to it.
Ternary search rather than a parabola through the three points: a parabola is
tempting and wrong at a cusp, where the derivative does not exist. Ternary search
needs only that the bracket holds a single turn.
Refinement is skipped, and the vertex kept, where there is nothing to refine
against - in polar coordinates, where the parameter is an angle that the stored
point does not carry, and wherever the curve has no formula behind it.
Measured on a shifted parabola, a shifted sine and a cusp: the answer lands
within about a hundred-millionth of the analytic one, and it is the same answer
at two different zooms.
The check that used to pass while this was broken
A parabola tested at a symmetric window passed the whole time. Zero fell exactly
on a grid point, so the right answer came out by alignment rather than by
calculation, and the check could not fail for the reason it existed.
The checks that guard this now place the extremum deliberately off the grid, and
they ask for the same answer at two zooms rather than at one. The second question
is the one that matters: a mark that moves when you zoom is wrong even when it
looks close.
Compatibility
| Delphi | 10.2 Tokyo through 13, win32 and win64 |
| Free Pascal | 3.2.2 and 3.3.1, win32 and win64 and linux64 |