Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

Clarify finite/infinite classification at numerical tolerance boundaries

Open
#960 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty
3/5
Estimated time
1-2 days
Newbie friendliness
35/100
Issue type
Bug
Clarity
Mostly clear
Activity status
Active
Tech stack
javascript
Domain
testing

Research direction

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.

Written by the indexing model from the issue text.

Description

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.

Dominant language
Bikeshed
Stars
566
Forks
72
Avg merge
6d 5h
Merged PRs (30d)
1

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from webmachinelearning/webnn

All issues in webmachinelearning/webnn

Similar issues

More Testing & QA issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.