Proposal: non-allocating single-point evaluation (funeval fast path)

(Text generated by Claude Fable 5)

Problem

funeval has no fast path for a single point: the scalar method wraps the point in a matrix and constructs a full BasisMatrix. For code that evaluates an interpolant point-wise inside a loop (optimizers, solvers, simulations), this dominates runtime and allocations.

Proposal

Add non-allocating single-point evaluation. A working implementation exists in QuantEcon/ContinuousDPs.jl — see src/point_eval.jl (short and largely self-explanatory) and QuantEcon/ContinuousDPs.jl#94, which collects the full details (API sketch, benchmark numbers, design decisions on record, planned extensions such as derivative orders and an Interpoland fast path). In brief:

• API: PointEvalCache(p::BasisParams) per-dimension caches with specialized kernels for ChebParams, SplineParams, and LinParams; FunEvalCache(basis::Basis{N}) and funeval_point!(cache, c, x) -> Float64 for N-dimensional tensor-product evaluation.
• Agrees with funeval to machine precision, including for points outside the interpolation domain.
• Impact downstream: cut the memory footprint of a value function iteration from 700 MiB to 434 KiB (5.8M to 5.4K allocations) and halved wall-clock time (QuantEcon/ContinuousDPs.jl#93).
• The implementation is self-contained, written against BasisMatrices conventions with no DP-specific types, so it can move here mostly as-is.
• Tests: test/test_point_eval.jl — 260 agreement cases across basis families, mixed 2-D/3-D tensor bases, and out-of-domain points, plus zero-allocation assertions; they would transplant as-is.
• Related: #60 requests in-place batch updates at a fixed set of nodes; this proposal covers the complementary point-wise case where the points change every call. A design accommodating both may be worth considering.

Ask

Before opening a PR here, we would like feedback on whether this is welcome and on the API naming/shape.

🤖 Drafted with Claude Code (Claude Fable 5)

Review the proposed implementation in ContinuousDPs.jl's src/point_eval.jl and the accompanying test/test_point_eval.jl, then compare its API with BasisMatrices conventions and related issue #60. Done means agreeing on the API and design direction before considering a PR; the referenced tests define precision, out-of-domain, mixed-dimensional, and allocation expectations.