akashchamp opened a new pull request, #219: URL: https://github.com/apache/commons-numbers/pull/219
`GeneralizedContinuedFraction` uses `Integer.MAX_VALUE` as the default `maxIterations` for the `value(...)` overloads that don't take an explicit iteration limit (and `ContinuedFraction.evaluate(double,double)`, which delegates to the same default). For a fraction that never converges, this means the `ArithmeticException` is only raised after iterating up to ~2^31 times, which can take many seconds instead of failing fast. This lowers the default to 1,000,000, as suggested in the issue. ## Verification Reproduced with the oscillating, non-converging generator from the issue (`b0 = 1`, then `a = 1, b = 0` on every subsequent call): - Before this change: throws after ~14.8s on this machine (`DEFAULT_ITERATIONS = 2147483647`). - After this change: throws after well under a second (`DEFAULT_ITERATIONS = 1000000`). Added a regression test with this generator that asserts the default-iteration overload throws without exceeding the documented default iteration count, plus a test that the default stays well below `Integer.MAX_VALUE`. Ran `mvn test` for `commons-numbers-fraction` (all 158 tests pass, including the 2 new ones) and for `commons-numbers-gamma` (all tests pass unaffected, since its call sites already pass an explicit `maxIterations` and are not affected by the default). The 4-argument overloads that accept an explicit `maxIterations` are unchanged, so callers who need more than 1,000,000 terms to converge can still opt in explicitly. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
