Skip to content

test: migrate constants/float16/ln-two to ULP-based assertions - #16208

Draft
kgryte wants to merge 1 commit into
developfrom
kgryte/ulp-constants-float16-ln-two
Draft

kgryte wants to merge 1 commit into
developfrom
kgryte/ulp-constants-float16-ln-two

Conversation

@kgryte

@kgryte kgryte commented Oct 17, 2026

Copy link
Copy Markdown
Member

Resolves a part of #11352.

Description

What is the purpose of this pull request?

This pull request:

  • migrates the test suite for constants/float16/ln-two from a relative tolerance assertion to a ULP difference assertion.

The export equals lnf(2) test previously computed delta = absf( float64ToFloat16( v - FLOAT16_LN2 ) ) and tol = EPS * FLOAT16_LN2 and asserted with t.ok( delta <= tol, ... ). It now delegates to @stdlib/number/float16/base/assert/is-almost-same-value:

tape( 'export equals `lnf(2)`', function test( t ) {
	var v = float64ToFloat16( lnf( 2.0 ) );
	t.strictEqual( isAlmostSameValue( v, FLOAT16_LN2, 0 ), true, 'returns expected value' );
	t.end();
});

Final ULP constant: 0.

File Call sites ULP bound
test/test.js 1 0

Notes on how the bound was measured:

  • The bound was tightened empirically, starting high and lowering: the suite was run at 64, 8, 1, and 0, and passes at every step, so 0 is the measured minimum and no smaller bound exists.
  • Directly measured, ulpDifference( v, FLOAT16_LN2 ) is exactly 0: the computed value float64ToFloat16( lnf( 2.0 ) ) and the exported constant are both 0.693359375, i.e., bit-identical in half-precision.
  • Note that, per the implementation, maxULP === 0 short-circuits to isSameValue, so the final assertion is an exact (same-value) comparison. This matches the already-merged constants/float16/ln-half (test: migrate constants/float16/ln-half to ULP-based assertions #16173) and constants/float16/pi-squared (test: migrate constants/float16/pi-squared to ULP-based assertions #16170) conversions, which likewise settled on 0.
  • The half-precision variant of the assertion is used here so that the ULP gap is measured in half-precision units, consistent with the other converted constants/float16/* packages (ln-half, ln-ten, half-ln-two, pi-squared). Accordingly, the computed value is rounded to half-precision via float64ToFloat16 before comparison, mirroring those packages (the previous code instead rounded the difference).
  • The suite was run twice at the final bound to confirm determinism; all 4 assertions pass both times.
  • This package has no test.native.js, so there is no JS/C divergence to account for.
  • The two pre-existing exact assertions (typeof and the exact float64ToFloat16( 0.6931471805599453 ) value check) are intentionally left unchanged, as exact comparisons remain correct there.
  • Only the one test file is modified; no source, documentation, or fixture changes.

Related Issues

Does this pull request have any related issues?

This pull request has the following related issues:

Questions

Any questions for reviewers of this pull request?

No.

Other

Any other information relevant to this pull request? This may include screenshots, references, and/or implementation notes.

The structure of the change intentionally mirrors the already-merged constants/float16/ln-half conversion (#16173), which has a near-identical test file in the same family.

The bound is reproducible across architectures: the comparison is between two compile-time-fixed half-precision values and is not subject to FMA-contraction differences.

Note that the local make pre-commit EditorConfig check could not run in this environment (the editorconfig-checker binary download is network-blocked), so the changed file was verified manually for tabs-only indentation, no trailing whitespace on changed lines, LF endings, and a final newline. The JavaScript test lint (make lint-javascript-tests) and the filename lint ran and passed, as did make test for this package.

Checklist

Please ensure the following tasks are completed before submitting this pull request.

AI Assistance

When authoring the changes proposed in this PR, did you use any kind of AI assistance?

  • Yes
  • No

If you answered "yes" above, how did you use AI assistance?

  • Code generation (e.g., when writing an implementation or fixing a bug)
  • Test/benchmark generation
  • Documentation (including examples)
  • Research and understanding

Disclosure

If you answered "yes" to using AI assistance, please provide a short disclosure indicating how you used AI assistance. This helps reviewers determine how much scrutiny to apply when reviewing your contribution. Example disclosures: "This PR was written primarily by Claude Code." or "I consulted ChatGPT to understand the codebase, but the proposed changes were fully authored manually by myself.".

This PR was authored by Claude Code. It studied the already-converted packages in the same family (notably constants/float16/ln-half and constants/float16/pi-squared) to match the established idiom, then measured the minimum ULP bound empirically and verified determinism as described above.


@stdlib-js/reviewers


Generated by Claude Code

Replace the computed relative tolerance comparison with an
`@stdlib/number/float16/base/assert/is-almost-same-value` check using the
minimum required ULP bound of `0`.

Ref: #11352

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01UKvuHN7ztwJb2egVTPev2z
@stdlib-bot stdlib-bot added the Good First PR A pull request resolving a Good First Issue. label Oct 17, 2026
@stdlib-bot

Copy link
Copy Markdown
Contributor

Coverage Report

Package Statements Branches Functions Lines
constants/float16/ln-two $\\color{green}51/51$
$\\color{green}+100.00\\%$
$\\color{green}1/1$
$\\color{green}+100.00\\%$
$\\color{green}0/0$
$\\color{green}+100.00\\%$
$\\color{green}51/51$
$\\color{green}+100.00\\%$

The above coverage report was generated for the changes in this PR.

This branch has not been deployed

No deployments
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Good First PR A pull request resolving a Good First Issue.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants