[cbarrick]

Same algorithm in Rust finds 2172315626468283465 in about 3 seconds on my M1 Pro.

    $ time cargo run --release
        Finished `release` profile [optimized] target(s) in 0.02s
         Running `target/release/p45`
    0
    1
    40755
    1533776805
    57722156241751
    2172315626468283465
    cargo run --release  2.95s user 0.04s system 98% cpu 3.029 total

Runs on the Rust Playground too: https://play.rust-lang.org/?version=stable&mode=release&edit...

[throwaway81523]

Changing the Integer to Int in the Haskell program (use machine integers instead of bignums) speeds the 6 minutes to 35 seconds, fwiw. But that was only ok to do after knowing that the result would fit in a machine int. This is on an i5-3570 which is a bit over half the speed of the M1 Pro (Passmark score 2042 vs 3799). So it scales to around 18 sec on similar hardware. Not too bad given the list-based implementation, I guess.

[wenderen]

Neat! I translated my code to Rust line-for-line and the iterator approach significantly outperforms it.

Rust newbie q - why use `x.wrapping_sub()` instead of regular old `x - 1`? Seems like we're never going to underflow `usize` for any of the 3 formulae?

[throwaway81523]

I don't use Rust at all, but if compiler warnings are set to maximum, I'd want subtracting anything from a usize to give a warning unless the compiler can verify that the result is a valid usize. BTW, OEIS A014979 gives a linear recurrence for triangular-pentagonal numbers, so filtering for hexagonals gives a much faster way to do this problem. There may be a recurrence that does all three at once, not sure.

[cbarrick]

> why use `x.wrapping_sub()` instead of regular old `x - 1`?

Because I coded it to start at x=0, which will underflow and will panic in debug mode.