Adopt the array API standard for the multi-backend numeric core

Aperta
#132 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
5/5
Tempo stimato
Più di una settimana
Idoneità per principianti
35/100
Tipo di issue
Refactoring
Chiarezza
Specificata chiaramente
Stato di attività
Tranquilla
Stack tecnologico
numpy, python, pytorch

Direzione di ricerca

Start by reading the existing ArrayBackend abstraction and the CRPS family entry points, then inspect how array-api-compat infers a namespace from input arrays. Phase 1 is complete when CRPS uses the shared inferred namespace and special-function layer, native arrays are tested across the listed frameworks, and unsupported torch special functions raise NotImplementedError; the remaining phases span all score families and backend removal.

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

Descrizione

Background

scoringrules runs every score across numpy, numba, jax, and torch through a hand-written ArrayBackend abstraction — an ABC with one concrete subclass per framework (~1400 lines). It works, but it's a maintenance burden: every new numeric primitive has to be added to the ABC and re-implemented in each backend, and users must explicitly select or register a backend.

The Python array API standard (via array-api-compat) now provides a portable, framework-agnostic surface that covers most of what we hand-rolled. Adopting it lets us infer the framework directly from the input arrays, drop most of the custom backend code, and return results in the caller's own framework with no configuration.

Goals

  • Infer the array framework from input arrays instead of a global/registry selection.
  • Replace the ArrayBackend ABC with array-api-compat plus a thin extension layer for special functions the standard doesn't cover (erf, gamma, betainc, …).
  • Keep numba's compiled gufuncs as an explicit, opt-in fast path (backend="numba").
  • Deprecate registry-based backend selection; long-term, remove the backend= argument entirely.

Approach

This touches all ten score families, so we're doing it in phases — family by family — with the shared infrastructure landing alongside the first pilot family.

  • Phase 1 — Foundation + CRPS pilot. Add the array-api-compat dependency; build the inference and augmented-namespace layer plus the native-first special-function extension layer; migrate the entire CRPS family end-to-end as the pilot. Deprecate backend="numpy"/"jax"/"torch" and register_backend / set_active for array-API frameworks; mixed-framework inputs now raise. Tests exercise native arrays per framework and assert the inferred backend so a misrouted score can't silently fall back to numpy.
  • Phase 2 — Migrate the remaining families. Port the other nine families (energy, logs, brier, kernels, variogram, dss, interval, quantile, error_spread) and their weighted variants onto the same infrastructure, folding the parallel _xp helper modules back into the shared core as each family moves over.
  • Phase 3 — Remove the old abstraction. Once every family is migrated, delete the ArrayBackend ABC, the per-framework subclasses, and the backend registry.
  • Phase 4 (long-term) — Remove backend= entirely. Explore transparent auto-numba so the compiled fast path is selected automatically for numpy inputs, removing the need for the backend argument at all.

Behavior changes from Phase 1

  • The default no longer routes through numba. interval_score and crps_quantile previously defaulted to gufuncs and now require backend="numba" to opt in.
  • torch has no native betainc / hyp2f1 / expi; scores needing those raise NotImplementedError for torch inputs (pass numpy or jax instead).
Lingua principale
Python
Stelle
108
Fork
15
Merge medio
1h 42m
PR unite (30g)
9

Preparare l'ambiente

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 frazane/scoringrules

Tutte le issue di frazane/scoringrules

Issue simili

Altre issue su Python

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.