Hacktoberfest 2026:メンテナが10月に向けて印を付けた、オープンで初心者向けの issue。 Hacktoberfest の issue を見る

NaN propagation: `nans_N` side condition and deterministic-profile sentence regressed

オープン
#2,265 コメント 0 件 リアクション 0 件 担当者 0 名 GitHub で見る

メンテナーはふだん 1 日以内に返信

まだ誰も着手していません。

評価

難易度
4/5
見積もり時間
3〜5日
初心者へのやさしさ
54/100
issue の種類
バグ
明瞭さ
明確に書かれている
活発さ
活発
技術スタック
wasm
領域
documentation

調査の方向性

Start with document/core/exec/numerics.rst, especially the nans_N side condition and deterministic-profile sentence cited in the issue; compare them with the formal definition and profile appendix. Then check test/core/f32.wast at the cited lines for the expected canonical-NaN behavior. Done means the wording and conditions agree with the intended semantics and the cited tests remain consistent.

索引モデルが issue の本文から書いたものです。

説明

In NaN Propagation, two changes from the relaxed-SIMD merge make the section inconsistent.

1. Non-NaN operands in nans_N

#1799 (acb599c4a) changed the side condition of nans_N from

∀ ±NAN(n) ∈ z*, n = canon_N

to

{z*} ⊆ {+NAN(canon_N), −NAN(canon_N)}

The old condition is also the one in Wasm 2.0 (∀ NAN(n) ∈ z*, n = canon_N), so this is a regression from 2.0.

The operators also pass their non-NaN operands in z* (e.g. fadd_N(±NAN(n), z_2) = nans_N{±NAN(n), z_2}), so the new condition is false whenever such an operand is present. For fadd_N(+NAN(canon_N), 1.0):

  • prose and the old condition: ±NAN(canon_N)
  • current condition: any arithmetic NaN

With the current condition, only nans_N{} produces a canonical payload.

The test suite assumes the old meaning: f32.wast L217 and L377 expect nan:canonical from add of nan and 0x1p+0. The fdiv prose also returns nans_N{z_1, z_2} for two zeros, which now yields any arithmetic NaN for 0/0, while f32.wast L1222 expects nan:canonical.

2. Deterministic-profile sentence

The merge commit 3f0bd84d8 changed this sentence from

In the deterministic profile, only positive canonical NaN outputs are produced.

to

In the deterministic profile, however, a positive canonical NaNs is reliably produced in the latter case.

"The latter case" is the case with a non-canonical input, so the new sentence leaves the sign nondeterministic when all inputs are canonical. The formal definition and the profile appendix still say that every generated NaN is positive and canonical.

Suggested fix

I think the suggested fix is to restore the earlier text:

  1. the ∀ ±NAN(n) ∈ z*, n = canon_N condition and its counterpart ∃ ±NAN(n) ∈ z*, n ≠ canon_N

  2. line 1054:

    * In the :ref:`deterministic profile <profile-deterministic>`, only positive canonical NaN outputs are produced.
    

@rossberg
Both changes come from the relaxed-SIMD merge. Could you confirm whether the old meaning is still intended?

主要言語
WebAssembly
スター
3.5k
フォーク
539
平均マージ
10時間 24分
マージ済み PR(30日)
11

環境構築

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

WebAssembly/spec のほかの issue

WebAssembly/spec の issue をすべて見る

似ている issue

Documentation の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。