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

Abierto
  • ¿Algo no está bien?
#82 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
5/5
Tiempo estimado
Más de una semana
Aptitud para principiantes
35/100
Tipo de issue
Nueva funcionalidad
Claridad
Necesita aclaración
Estado de actividad
Tranquilo
Stack tecnológico
julia
Área
performance

Línea de trabajo

Revisa la implementación propuesta en src/point_eval.jl de ContinuousDPs.jl y el test/test_point_eval.jl correspondiente, y luego compara su API con las convenciones de BasisMatrices y el issue relacionado #60. La tarea se considera terminada cuando se haya acordado la API y la dirección del diseño antes de considerar un PR; los tests referenciados definen las expectativas de precisión, valores fuera de dominio, dimensiones mixtas y asignaciones.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

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)

Lenguaje dominante
Julia
Estrellas
33
Forks
20
Sin PR fusionados en 30 d

Preparar el entorno

Este proyecto no incluye contenedor de desarrollo, Dockerfile ni guía de contribución, así que la configuración corre por tu cuenta: empieza por su README y consulta nuestra guía para la primera contribución para los pasos generales.

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de QuantEcon/BasisMatrices.jl

Todos los issues de QuantEcon/BasisMatrices.jl

Issues similares

Más issues de Julia

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.