There are tons of test suites so if the tests pass then that provides a reasonable guarantee of correctness. Although it would be nice if there was also proof of correctness for the compilation from CUDA to AMD.
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
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.
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?
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.
Free software is a value prop, not a law. And it is counter to the value prop that one entity is entirely responsible for all of the software (even if Apple doesn’t write every line of code, they are responsible for every bit that ships).
Not everyone cares about the bits. It’s true that the vast majority of consumers prefer having a single supplier to having freedom to run their own bits.
By that same logic consumers can't replace the os on PCs so consumers don't own PCs either. Customizing things manually is not always easy and user friendly. Easy customization is another feature products can offer.
What's going on under the hood with that authentication example?
Is the server holding onto some state in memory that this specific client has already authenticated? Or is the API key somehow stored in the new AuthenticatedSession stub on the client side and included in subsequent requests? Or is it something else entirely?
The server constructs a new AuthenticatedSession implementation each time authenticate() is called, and can store the key (or just the authenticated user info) in the server-side object.
This does mean the server is holding onto state, but remember the state only lasts for the lifetime of the particular connection. (In HTTP batch mode, it's only for the one batch. In WebSocket mode, it's for the lifetime of the WebSocket.)
Ah, the bit about it only lasting for the lifetime of the connection was the part I missed. That makes a lot of sense. As does the bit about the state staying on the server side.
Companies are always going to lay people off, because they can and it is in their financial interest to do so when the shareholders or investors demand cutbacks. AFAIK, Amazon even has a formalized stack ranking system where a certain percentage will be laid off every year to make room for new talent. This has nothing to do with visas or immigrants. If you want to stop that, you need better worker protections, but that's a separate discussion.
There's a lot of handwaving in this "just use AI" approach. You have to figure out a way to guarantee correctness.