Sorted-batch evaluators for the remaining piecewise interpolation types (7-13x)

[ChrisRackauckas-Claude]

Summary

Extends the sorted-batch fast path to all remaining piecewise types with a fixed per-segment polynomial form:

• ConstantInterpolation (both :left and :right directions)
• QuadraticInterpolation
• QuadraticSpline
• CubicHermiteSpline
• QuinticHermiteSpline

Pairs with #527 (Linear + CubicSpline) and the earlier #526 (Akima). After both this PR and #527 land, every piecewise interpolation type in DataInterpolations.jl has an O(n+m) batch evaluator for sorted queries.

This PR is stacked on #527 — branched off sorted-batch-linear-cubic. If reviewed first I'll rebase onto master once #527 lands. Order-independent otherwise.

Why a shared helper now

Adds a _sorted_batch_extrapolation_supported(A) predicate used by all five new evaluators (None / Constant / Linear / Extension on each side). The earlier per-type predicates (_akima_eval_fast_applicable, _linear_eval_fast_applicable, _cubicspline_eval_fast_applicable) are left in place to keep this PR's diff focused on the new types; they're all equivalent and can be folded into the shared helper in a 5-line follow-up if desired.

Benchmarks

Julia 1.10, n=256 knots, m=4096 sorted queries, BenchmarkTools minimum:

Type	before	after	speedup
ConstantInterpolation	107 μs	14.6 μs	7.3×
QuadraticInterpolation	166 μs	15.2 μs	10.9×
QuadraticSpline	858 μs	67.5 μs	12.7×
CubicHermiteSpline	167 μs	16.8 μs	9.9×
QuinticHermiteSpline	278 μs	26.9 μs	10.3×

QuadraticSpline gets the biggest absolute win because its per-segment cost is dominated by get_parameters(A, idx) (the segment α, β coefficients) — the lockstep walk amortizes that across all queries in the segment instead of recomputing per query.

What is in this PR

• src/interpolation_methods.jl:
  • Adds the shared _sorted_batch_extrapolation_supported(A) helper near the top.
  • Adds (A::T)(out, tt) callables + the corresponding _*_eval_sorted! inner loops for each of the 5 types, each following the same shape: dispatch on extrapolation type outside the per-region loop, hoist segment-local coefficients once per segment.
  • CubicHermiteSpline and QuinticHermiteSpline use the Hermite property that the slope at each knot equals du[idx], so Linear extrapolation reduces to a single multiply.
  • ConstantInterpolation's eltype constraint is relaxed to <:AbstractVector (not <:AbstractVector{<:Number}) so it works for non-numeric data like ["a", "b", ...] — no arithmetic is performed.
• test/interpolation_tests.jl: "Sorted-batch evaluator" sub-testsets in each type's section. Coverage matches Optimize AkimaInterpolation constructor (3.6-4.1x) and add sorted-batch evaluator (8-9x) #526 and Sorted-batch evaluators for LinearInterpolation and CubicSpline (~9x speedup) #527: all fast-path extrapolation modes paired left × right, knot pass-through, Periodic/Reflective fallback, None throwing, unsorted fallback, DimensionMismatch, plus cache_parameters=true for QuadraticSpline and the non-Number eltype path for ConstantInterpolation.

What is intentionally NOT in this PR

SmoothedConstantInterpolation — its boundary smoothing means adjacent queries within the same segment can fall in either the smoothed region (at the segment edges) or the constant region (in the middle), so the per-segment hoist pattern doesn't apply cleanly. Worth a separate PR if someone wants it.

Test plan

• CI passes
• Pkg.test() all groups pass locally on Julia 1.10 (Core 5036 / Methods 42151 / Extensions 13178 / Misc 11)
• Output matches the per-point path bitwise on all test inputs (verified via max diff check before adding the testset)
• Runic-formatted

Please ignore until reviewed by @ChrisRackauckas.

🤖 Generated with Claude Code