fix: avoid cancellation for small p in stats/base/dists/geometric/cdf

[Abhist17]

Description

What is the purpose of this pull request?

This pull request:

• evaluates stats/base/dists/geometric/cdf as -expm1( (x+1) * log1p(-p) ) instead of 1 - pow( 1-p, x+1 ) (JS, factory and C).

Forming 1 - p rounds away the low-order bits of p, and subtracting (1-p)^(x+1) from 1 then cancels. For p < 2^-53 the CDF is 0 at every x, and for small p only a few digits are right:

var cdf = require( '@stdlib/stats/base/dists/geometric/cdf' );

cdf( 0.0, 1.0e-20 );
// develop: 0.0
// this PR: 1.0e-20

cdf( 9.0, 1.0e-10 );
// develop: 1.000000082740371e-9
// this PR: 9.9999999955e-10

planck/cdf already uses the same -expm1(...) form.

Fixtures and tests:

• runner.jl now evaluates the textbook formula 1 - (1-p)^(floor(x)+1) in 2048-bit BigFloat instead of calling Distributions.cdf, which computes in double precision and had the same cancellation. Distributions is dropped from REQUIRE. small_p.json and large_p.json are regenerated with the same input ranges.
• Against the exact values, develop is off by up to 7,134 ULP on small_p.json (p < 0.5). With this change, every fixture passes at 1 ULP in JS and native, so the small_p tolerance goes from 20 to 1.
• There's a new tiny_p.json with p log-spaced over [1e-300, 0.1] and x in [0, 100], tested at 1 ULP.
• On develop, 1,192 of the 3,012 assertions in test.cdf.js fail. With this change they all pass.

Related Issues

Does this pull request have any related issues?

None. It's the same 1 - p loss as #15762, #15763 and #15764.

Questions

Any questions for reviewers of this pull request?

geometric/logcdf computes log1p( -pow( 1.0 - p, x + 1.0 ) ) and has the same problem. I'll send it separately.

Other

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

No.

Checklist

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

• Read, understood, and followed the contributing guidelines.

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 written primarily by Claude Code. I found the bug by reading the stats/base/dists functions for 1 - p cancellation.

---

@stdlib-js/reviewers

[stdlib-bot]

Coverage Report

Package	Statements	Branches	Functions	Lines
stats/base/dists/geometric/cdf	$\\color{green}293/293$ $\\color{green}+0.00\\%$	$\\color{green}27/27$ $\\color{green}+0.00\\%$	$\\color{green}4/4$ $\\color{green}+0.00\\%$	$\\color{green}293/293$ $\\color{green}+0.00\\%$

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

[0PrashantYadav0]

Non-blocking: with x <= 100, every tiny_p case with p < 2^-53 gives a result below 1e-14, so results of order 1 aren't tested (e.g. cdf( 1e20, 1e-20 ) is 0.632, develop gives 0). Worth adding a few cases with x near 1/p? x = rand( 1000 ) .* 3.0 ./ p passes at 1 ULP.

[Abhist17]

@0PrashantYadav0 good idea, added in 9149c8b: tiny_p_large_x.json with p over [1e-300, 0.1] and x = floor( rand * 3/p ), plus a block in each test file at 1 ULP. cdf( 1e20, 1e-20 ) gives 0.6321205588285577. test.cdf.js / test.factory.js / test.native.js pass 4,012 / 4,016 / 4,012.

[0PrashantYadav0]

LGTM