Skip to content

Latest commit

 

History

4 Commits

Folders and files

NameName
Last commit message
Last commit date
 
 
 
 
 
 

Repository files navigation

Gamma(1/5) to 300 Billion Decimal Digits

Independent high-precision computation and verification of Gamma(1/5) to 300,000,000,000 decimal digits.

Precision Platform y-cruncher


This repository documents my computation of Gamma(1/5) to:

300,000,000,000 decimal digits

The result was computed twice on the UPES high-performance computing cluster using two computationally independent algorithms in y-cruncher:

  • Vidunas–Lamprecht (2024)
  • Incomplete Gamma Approximation

Both computations completed successfully, passed y-cruncher's output verification stages, and produced identical decimal and hexadecimal results.

Record status: The result has been submitted to and acknowledged by the y-cruncher records maintainer. The public leaderboard update is currently pending.


Result at a Glance

Constant Gamma(1/5)
Decimal precision 300,000,000,000 digits
Hexadecimal precision 249,144,607,117 digits
Software y-cruncher v0.8.7 Build 9547
Compute platform UPES HPC cluster
Processor Intel Xeon Platinum 8470
System topology 104 physical cores, 2 sockets, 2 NUMA nodes
Usable system memory ~0.98 TiB
Number of independent runs 2
Run 1 Vidunas-Lamprecht (2024)
Run 2 Incomplete Gamma Approximation
Run 1 computation time 18.866 days
Run 2 computation time 13.256 days
Combined computation time ~32.1 days
Cross-verification Matching hexadecimal and decimal outputs
Submission status Acknowledged; leaderboard update pending

At the time of submission, the public y-cruncher records page listed the verified Gamma(1/5) record at 270,000,000,000 decimal digits.

This computation extends that precision to 300,000,000,000 digits, an increase of 30 billion decimal digits.


What Is Gamma(1/5)?

The Gamma function extends the factorial function to complex and non-integer arguments.

For positive integers,

Gamma(n) = (n - 1)!

This project concerns the value:

Gamma(1/5)

whose decimal expansion begins:

4.59084371199880305320475827592915200343410999829340...

The objective here was not simply to calculate a prefix of the constant, but to produce and independently verify 300 billion decimal digits of it.


Why Two Computations?

For record-scale high-precision computations, simply completing one computation is not enough.

The important question is not only:

Did the software finish?

but also:

How do we know that hundreds of billions of generated digits are actually correct?

The y-cruncher record process requires independent verification. For a normal constant record, this means computing the same value using two computationally independent methods, enabling output verification, saving the generated digits, and checking that the results agree.

For this project I therefore performed two separate 300-billion-digit computations:

Run 1 — Vidunas-Lamprecht (2024)

Gamma(1/5)
Algorithm: Vidunas-Lamprecht (2024)
Precision: 300,000,000,000 decimal digits

This was the first full-scale computation.

Detailed information:

runs/01-vidunas-lamprecht.md

Run 2 — Incomplete Gamma Approximation

Gamma(1/5)
Algorithm: Incomplete Gamma Approximation
Precision: 300,000,000,000 decimal digits

This was the independent verification computation.

Detailed information:

runs/02-incomplete-gamma.md

The two methods have substantially different computational paths, providing an independent check against errors in the primary calculation.


Verification

Verification happened at multiple levels.

1. y-cruncher internal verification

Both computations were performed with:

Verify Output: Enabled
Digit Output: Plain Text File

At the end of each run, y-cruncher performed its output verification stages, including:

Verifying Base Conversion
Verifying Binary Output
Verifying Decimal Output
Verifying Hexadecimal Output

Both runs completed these stages successfully.

The logs also reported:

Spot Check: Good through 270,000,000,000

The complete logs are preserved in this repository.


2. Hexadecimal output comparison

Both independent computations produced:

249,144,607,117 hexadecimal digits

The hexadecimal files were compared directly using cmp.

Result:

Hex files IDENTICAL, byte-for-byte

This means that the two independently generated hexadecimal output streams were exactly identical.


3. Decimal digit comparison

The decimal output files contain formatting such as whitespace and line breaks, so I also compared their actual digit streams after removing formatting.

Conceptually, the comparison was:

cmp -s \
    <(tr -cd '0-9.' < run1-decimal.txt) \
    <(tr -cd '0-9.' < run2-decimal.txt)

Result:

All significant digits IDENTICAL between the two independent formulas

Thus the two independent algorithms agreed across the generated decimal expansion as well.


Why This Verification Matters

A checksum or file comparison by itself does not prove that a result is mathematically correct.

It proves that two files agree.

The strength of the verification here comes from combining several independent checks:

  1. Run 1 completed with y-cruncher's internal verification enabled.
  2. Run 2 completed independently with a different algorithm.
  3. Run 2 also passed y-cruncher's internal verification.
  4. The hexadecimal outputs matched byte-for-byte.
  5. The decimal digit streams matched after removing formatting.

For two computationally independent algorithms to produce the same hundreds of billions of digits while also passing their internal verification stages provides a strong cross-check against computational, storage, or algorithm-specific errors.


Hardware

Both computations were performed on the UPES high-performance computing cluster.

The system reported:

Processor(s): Intel(R) Xeon(R) Platinum 8470
Topology:     104 threads / 104 cores / 2 sockets / 2 NUMA nodes
Usable RAM:   1,081,392,922,624 bytes (~0.98 TiB)

The two runs did not use identical memory/thread configurations.

That distinction is important when comparing their execution times.

Run 1

Run 1 used a y-cruncher push-pool configuration reported as:

52 / ? / 104

with approximately:

99.9 GiB working memory

and an explicitly configured far-memory/swap path.

Run 2

Run 2 used:

52 / ? / 52

with:

300 GiB working memory

using node interleaving.

Its configuration estimated:

1.78 TiB logical disk required
+ 511 GiB for output

Because the resource configuration differs substantially between runs, the raw wall-clock times should not be treated as a clean benchmark comparison between the two algorithms.

The purpose of the second run was verification, not benchmarking.


Computation Summary

Run 1

Algorithm: Vidunas-Lamprecht (2024)

Start: Tue Jun 23 00:52:39 2026
End:   Mon Jul 13 03:31:20 2026

y-cruncher reported:

Gamma(1/5) computation:
1,496,872.325 seconds
17.325 days

Including output generation and verification:

Total Computation Time:
1,630,020.408 seconds
18.866 days

Start-to-End Wall Time:
1,737,521.209 seconds
20.110 days

This computation was resumed from a y-cruncher checkpoint during the run.

Full breakdown:

runs/01-vidunas-lamprecht.md


Run 2

Algorithm: Incomplete Gamma Approximation

Start: Wed Jul 15 00:43:27 2026
End:   Tue Jul 28 07:47:13 2026

y-cruncher reported:

Gamma(1/5) computation:
1,142,609.527 seconds
13.225 days

Including output generation and verification:

Total Computation Time:
1,145,316.161 seconds
13.256 days

Start-to-End Wall Time:
1,148,626.062 seconds
13.294 days

Full breakdown:

runs/02-incomplete-gamma.md


Some Scale

A computation at this size stops behaving like an ordinary CPU benchmark.

The second run alone required y-cruncher to plan for approximately:

300 GiB logical memory
1.78 TiB logical disk
511 GiB additional output space
646 GiB maximum checkpoint size

Its primary series contained:

1,877,722,566,189 terms

and that single phase ran for:

1,000,509.834 seconds
11.580 days

The subsequent powering stage alone took another:

112,870.802 seconds
31.353 hours

At this scale, memory topology, swap configuration, storage throughput, checkpointing, and I/O behavior become as important as raw CPU performance.


Final Digits

Both runs reported the same final decimal digits:

...5598491507 5531639138 3041683937 8082050161 6823203270
   4931471956 5394413255 3966390157 3379777564 4119934832

ending at decimal digit:

300,000,000,000

The repository does not contain the complete 300-billion-digit decimal or 249-billion-digit hexadecimal output files.

Those files are far too large for GitHub and are not necessary to inspect the computation metadata or validation process.


Record Submission Status

The completed two-run result was submitted to Alexander Yee, the maintainer of y-cruncher and its public records list.

The submission has been acknowledged and is in the queue for a future leaderboard update.

At the time of submission, the public leaderboard listed:

Gamma(1/5)
270,000,000,000 decimal digits

This project computed and independently verified:

Gamma(1/5)
300,000,000,000 decimal digits

Until the public records page is updated, I describe the result as:

300-billion-digit Gamma(1/5) computation, independently verified using two algorithms; record submission acknowledged and official leaderboard update pending.

This wording will be updated once the public leaderboard is refreshed.


Timeline

23 Jun 2026
Run 1 started
Vidunas-Lamprecht (2024)

13 Jul 2026
Run 1 completed

15 Jul 2026
Run 2 started
Incomplete Gamma Approximation

28 Jul 2026
Run 2 completed

28 Jul 2026
Cross-algorithm output comparison completed

29 Jul 2026
Completed result and validation material submitted

Aug 2026
Submission acknowledged
Leaderboard update pending

Software

The computations were performed using:

y-cruncher v0.8.7 Build 9547

The cluster selected the Intel-oriented 18-CNL ~ Shinoa binary/tuning path, with the final logs reporting:

Linux/18-CNL ~ Shinoa => Miyuki (20241023)

This repository does not redistribute y-cruncher itself.


Acknowledgements

Thanks to:

  • Alexander Yee for developing y-cruncher and maintaining its records list,
  • the researchers behind the algorithms used for the two independent computations,
  • and UPES for providing access to the HPC infrastructure used for the project.

Author

Nitya Naman

Computer Science student at UPES, Dehradun.

This repository documents my 2026 computation and independent verification of Gamma(1/5) to 300 billion decimal digits.