Skip to content

Fix low precision for BigFloats in ExpMethodGeneric (Issue #44)#205

Merged
ChrisRackauckas merged 2 commits intoSciML:masterfrom
ChrisRackauckas-Claude:fix-issue-44-bigfloat-precision
Jan 12, 2026
Merged

Fix low precision for BigFloats in ExpMethodGeneric (Issue #44)#205
ChrisRackauckas merged 2 commits intoSciML:masterfrom
ChrisRackauckas-Claude:fix-issue-44-bigfloat-precision

Conversation

@ChrisRackauckas-Claude
Copy link
Contributor

Summary

  • Fix the low-precision issue for BigFloats in ExpMethodGeneric (Fixes exp_generic has low precision for BigFloats #44)
  • Add pade_order_for_type(T) to compute the minimum Padé order needed for machine-precision accuracy
  • Automatically detect high-precision types (BigFloat, etc.) and use appropriate Padé order
  • Add tests verifying machine-precision accuracy for BigFloat with various precision settings

Problem

The ExpMethodGeneric exponential implementation was using a fixed (13,13) Padé approximant regardless of the floating-point precision. This is only appropriate for Float64 (~53 bits). For BigFloat with default 256-bit precision, this resulted in errors of ~10^42 eps instead of machine precision.

Solution

The fix computes k based on the error bound for (k,k) Padé approximants:
(x/2)^(2k+1) / (2k+1)! < 2^(-precision_bits)

Results:

  • Float64: k=13 (unchanged, ~10 eps error)
  • BigFloat 128-bit: k=15
  • BigFloat 256-bit: k=25
  • BigFloat 512-bit: k=43
  • BigFloat 1024-bit: k=76

Test plan

  • Verified that Float64 behavior is unchanged
  • Verified BigFloat scalar accuracy is now within machine precision
  • Verified BigFloat matrix accuracy is within machine precision
  • Tested with different BigFloat precisions (128, 256, 512 bits)
  • All existing tests pass

cc @ChrisRackauckas

🤖 Generated with Claude Code

claude added 2 commits January 7, 2026 12:21
The `ExpMethodGeneric` exponential implementation was using a fixed
(13,13) Padé approximant regardless of the floating-point precision,
which is only appropriate for Float64 (~53 bits). For BigFloat with
default 256-bit precision, this resulted in errors of ~10^42 eps
instead of machine precision.

Changes:
- Add `pade_order_for_type(T)` to compute the minimum Padé order k
  needed for machine-precision accuracy for a given floating-point type
- Automatically detect high-precision types (BigFloat, etc.) and use
  the appropriate Padé order when `ExpMethodGeneric()` is called
- Add `ExpMethodGeneric(k)` constructor to manually specify order
- Add `ExpMethodGeneric(T)` constructor to select order based on type
- Add tests verifying machine-precision accuracy for BigFloat with
  various precision settings (128, 256, 512 bits)

The fix computes k based on the error bound for (k,k) Padé approximants:
(x/2)^(2k+1) / (2k+1)! < 2^(-precision_bits)

Results:
- Float64: k=13 (unchanged, ~10 eps error)
- BigFloat 128-bit: k=15
- BigFloat 256-bit: k=25
- BigFloat 512-bit: k=43
- BigFloat 1024-bit: k=76

Fixes SciML#44
cc @ChrisRackauckas

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
- Create test/jet directory with its own Project.toml for JET dependencies
- Move JET tests from qa.jl to test/jet/jet.jl
- Add activate_jet_env() function to runtests.jl following GPU pattern
- Remove JET from main Project.toml extras, compat, and test targets
- JET tests now run with GROUP=JET environment variable

This follows the same pattern as GPU tests, allowing JET to have its own
dependency resolution separate from the main test suite.

Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
@ChrisRackauckas-Claude
Copy link
Contributor Author

JET Test Separation

Added commit to split JET tests into a separate test group with its own environment, following the same pattern as GPU tests.

Changes:

  • Created test/jet/ directory with its own Project.toml for JET dependencies
  • Moved JET tests from qa.jl to test/jet/jet.jl
  • Added activate_jet_env() function to runtests.jl following the GPU pattern
  • Removed JET from main Project.toml (extras, compat, and test targets)
  • JET tests now run with GROUP=JET environment variable

How to run JET tests:

GROUP=JET julia --project -e 'using Pkg; Pkg.test()'

This follows the pattern from OrdinaryDiffEq.jl and DelayDiffEq.jl for separating heavy analysis tools like JET into their own test environments.

@ChrisRackauckas ChrisRackauckas merged commit 44b7162 into SciML:master Jan 12, 2026
19 of 28 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

exp_generic has low precision for BigFloats

3 participants