Hacktoberfest 2026: những issue maintainer đã đánh dấu cho tháng Mười, đang mở và phù hợp người mới. Xem issue Hacktoberfest

Clarify finite/infinite classification at numerical tolerance boundaries

Đang mở
  • Có gì không ổn?
#960 0 bình luận 0 reaction 0 người được giao Xem trên GitHub

Chưa có ai nhận issue này.

Đánh giá

Độ khó
3/5
Thời gian dự kiến
1-2 ngày
Mức phù hợp với người mới
35/100
Loại issue
Lỗi
Độ rõ ràng
Khá rõ ràng
Mức độ hoạt động
Sôi nổi
Công nghệ
javascript
Lĩnh vực
testing

Hướng nghiên cứu

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.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

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.

Ngôn ngữ chính
Bikeshed
Star
566
Fork
72
Merge trung bình
6 ngày 5 giờ
Pull request đã merge (30 ngày)
1

Chuẩn bị môi trường

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của webmachinelearning/webnn

Tất cả issue của webmachinelearning/webnn

Issue tương tự

Thêm issue về Testing & QA

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.