Skip to content

test: migrate math/iter/sequences/continued-fraction to ULP-based assertions - #15406

Draft
kgryte wants to merge 1 commit into
developfrom
kgryte/ulp-math-iter-sequences-continued-fraction
Draft

kgryte wants to merge 1 commit into
developfrom
kgryte/ulp-math-iter-sequences-continued-fraction

Conversation

@kgryte

@kgryte kgryte commented Sep 21, 2026

Copy link
Copy Markdown
Member

Resolves a part of #11352.

Description

What is the purpose of this pull request?

This pull request:

  • Migrates math/iter/sequences/continued-fraction's test/test.js from relative-tolerance (EPS-based) floating-point assertions to ULP-based assertions using @stdlib/assert/is-almost-same-value.
  • Removes the manual delta/tol computations (delta = abs( v - expected ); tol = 1.3 * EPS * abs( expected );) in favor of a single t.strictEqual( isAlmostSameValue( v, expected, 2 ), true, 'returns expected value' ) at each of the four fixture loops.
  • Drops the now-unused abs and EPS requires, and adds the @stdlib/assert/is-almost-same-value require in the same position used by already-converted iterator packages (e.g., simulate/iter/flat-top-pulse, simulate/iter/bartlett-hann-pulse).
  • Uses the minimum required ULP value for every converted site: all four use 2 ULPs.

Preserved behavior

Each converted loop is guarded by if ( v === expected || i === terms.length-1 ). Unlike the simple if ( actual === expected ) guards seen in some sibling conversions, this guard is not redundant with isAlmostSameValue: the i === terms.length-1 clause requires the final convergent to be exactly equal to the reference value. The guard is therefore retained, and only the else (tolerance) branch is migrated, so the assertion semantics are unchanged. This mirrors conversions which keep meaningful guards, such as math/base/special/acsch (if ( expected[ i ] === null ) { ... } else { isAlmostSameValue( ... ) }).

Measured minimum

The bound was not guessed. Each assertion site was instrumented to record the actual @stdlib/number/float64/base/ulp-difference between the returned and expected value across every iteration:

SITE1 maxulp=2
SITE2 maxulp=2
SITE3 maxulp=2
SITE4 maxulp=2

A downward sweep over the suite confirms 2 is the tightest integer bound that passes:

N=0  -> 4170 pass, 36 fail
N=1  -> 4202 pass,  4 fail
N=2  -> 4206 pass,  0 fail

This is consistent with the tolerance it replaces: 1.3 * EPS * abs( expected ) corresponds to roughly 1.3–2.6 ULPs depending on where the expected value falls within its binade, so a 2 ULP budget is no looser than the original assertion.

The suite was run twice at the final bound with identical, fully passing results, confirming there is no FMA/arch-dependent variation.

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.

4206/4206 assertions in test/test.js pass, both before and after the change — the assertion count is unchanged, since the previous if/else branches contributed exactly one assertion per iteration, as do the new ones. test/test.validate.js (48/48) is unaffected and was left alone; this package has no test.native.js.

eslint run against the changed file using etc/eslint/.eslintrc.tests.js reports no errors (the single max-lines warning is pre-existing and this change reduces the file's length). Only test/test.js was changed.

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

This PR was written by Claude Code (an autonomous coding agent), which searched for a qualifying candidate package, studied prior merged conversions for the same idiom, performed the migration, and empirically determined the minimum ULP bound described above by measuring actual ULP differences and confirming determinism through repeated test runs.


@stdlib-js/reviewers

🤖 Generated with Claude Code

https://claude.ai/code/session_01CZ7vpqkikdfeYSUS4DhSWX


Generated by Claude Code

…ssertions

Ref: #11352

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01CZ7vpqkikdfeYSUS4DhSWX
@stdlib-bot stdlib-bot added Math Issue or pull request specific to math functionality. Good First PR A pull request resolving a Good First Issue. labels Sep 21, 2026
@stdlib-bot

Copy link
Copy Markdown
Contributor

Hello! 👋

We've noticed that you've been opening a number of PRs addressing good first issues. Thank you for your interest and enthusiasm!

Now that you've made a few contributions, we suggest no longer working on good first issues. Instead, we encourage you to prioritize cleaning up any PRs which have yet to be merged and then proceed to work on more involved tasks.

Not only does this ensure that other new contributors can work on things and get ramped up on all things stdlib, it also ensures that you can spend your time on more challenging problems. 🚀

For ideas for future PRs, feel free to search the codebase for TODOs and FIXMEs and be sure to check out other open issues on the issue tracker. Cheers!

@stdlib-bot

Copy link
Copy Markdown
Contributor

Coverage Report

Package Statements Branches Functions Lines
math/iter/sequences/continued-fraction $\\color{red}490/494$
$\\color{green}+99.19\\%$
$\\color{red}63/65$
$\\color{green}+96.92\\%$
$\\color{green}9/9$
$\\color{green}+100.00\\%$
$\\color{red}490/494$
$\\color{green}+99.19\\%$

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. Math Issue or pull request specific to math functionality.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants