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

Aperta
  • Qualcosa non va?
#82 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
5/5
Tempo stimato
Più di una settimana
Idoneità per principianti
35/100
Tipo di issue
Funzionalità
Chiarezza
Da chiarire
Stato di attività
Tranquilla
Stack tecnologico
julia
Ambito
performance

Direzione di ricerca

Esamina l’implementazione proposta in src/point_eval.jl di ContinuousDPs.jl e il relativo test/test_point_eval.jl, quindi confronta la sua API con le convenzioni di BasisMatrices e con l’issue correlata #60. Il lavoro è considerato completato quando si è raggiunto un accordo sull’API e sulla direzione progettuale prima di prendere in considerazione un PR; i test indicati definiscono le aspettative relative a precisione, valori fuori dominio, dimensioni miste e allocazioni.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

enhancement performance question

(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)

Lingua principale
Julia
Stelle
33
Fork
20
Nessuna PR unita negli ultimi 30g

Preparare l'ambiente

Questo progetto non fornisce container di sviluppo, Dockerfile né guida per i contributori, quindi l'ambiente è a tuo carico: parti dal suo README e consulta la nostra guida al primo contributo per i passaggi generali.

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di QuantEcon/BasisMatrices.jl

Tutte le issue di QuantEcon/BasisMatrices.jl

Issue simili

Altre issue su Julia

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.