Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

Clarify finite/infinite classification at numerical tolerance boundaries

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

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
3/5
Tempo stimato
1-2 giorni
Idoneità per principianti
35/100
Tipo di issue
Bug
Chiarezza
Abbastanza chiara
Stato di attività
Attiva
Stack tecnologico
javascript
Ambito
testing

Direzione di ricerca

Start with assert_array_approx_equals_ulp in webnn/resources/utils.js, which loads alongside testharness.js, and trace how it measures ULP distance between finite maximums and infinities for float16 and float32. Run the four assertions quoted in the issue to confirm they pass. The open question is the intended contract, so a newcomer should first ask maintainers whether finite/infinite/NaN classification should be checked before tolerance. Done means an agreed contract plus regression helper tests covering both signs and directions.

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

Descrizione

While qualifying language models (tinystories, Mamba, SmolLM2) across Apple devices (multiple generations of iPhone, Apple Watch, Apple TV, and iPad), I found a test-oracle boundary that might be worth clarifying: WPT’s ULP helper considers maximum finite and same-sign infinity one ULP apart.

With testharness.js and webnn/resources/utils.js loaded, all four assertions currently pass:

assert_array_approx_equals_ulp([0x7bff], [Infinity], 1, 'float16');
assert_array_approx_equals_ulp([0x7c00], [65504], 1, 'float16');
assert_array_approx_equals_ulp([3.4028234663852886e38], [Infinity], 1, 'float32');
assert_array_approx_equals_ulp([Infinity], [3.4028234663852886e38], 1, 'float32');

Could we require matching finite/infinite/NaN classification before applying numerical tolerances, after converting the reference to the output dtype? If approximate overflow permits exceptions, those should be explicit in the operation’s error model, right?

Our RustNN strict comparator already tests this as an additional safeguard, and when I searched wider to see if other toolchains/runtimes had run into something similar, I found ONNX Runtime #31761. ONNX fixed a related finite-versus-infinite comparator problem. I'm not saying it always makes sense to pull in ONNX problems/solutions, but it seemed close to me in this case.

If the intended contract is agreed, I can contribute WPT helper regressions covering both signs, both directions and adjacent finite controls. Nearly all of which came up in my multi-model work in RustNN when pinning down accuacy/precision problems that compounded in recurrent graphs.

Lingua principale
Bikeshed
Stelle
566
Fork
72
Merge medio
6g 5h
PR unite (30g)
1

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 webmachinelearning/webnn

Tutte le issue di webmachinelearning/webnn

Issue simili

Altre issue su Testing & QA

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.