Thor running an experiment with the first 50 problems in Project Euler. Experiment: how does prototyping a solution in a dynamically typed language (Python) then translating to a statically typed language (Rust) affect my efficiency (and vice versa)? Methodology: `shuf -i 0-1 -n1`, heads (1) we start in Rust, tails (0) in Python. Start a timer, and record time to develop the solution in each language Possibly confounding: (1) Thor is more knowledgeable at Rust than Python, and expects to gain relatively more Pythonic skill over time.

Problem

solved in

python (mins)

TOTAL (mins)

runtime r (ms)

runtime p (ms)

time: python solve

time: rust from python

time: python from rust

some time spent fighting type checks

woah. What's eating my rust solution cycles?

had to look up python string substitution and fiddle with lambda

sorta slow runtimes. in review, i could have implemented the sieve more efficiently.

struggled with opening a file in python, converting elements in a list from strings to ints in both. Feeling a bit out of practice.

Starting to run into time efficiency problems

This algorithm ran pretty grossly slow. I should find a better way.

Half the python time was spent debugging, ultimately discovering a transposed line. Only half my time spent debugging? I must be doing great!

Rust: About 12 minutes to derive a multiplicity theorem, another 12 to write a solution, and a final 12 to debug my solution. Python: mostly trying to figure out how to use python dictionaries, and fiddling with the (totally lame) reduce function before eventually finding a way to use accumulators.

Rust: a bit of fiddling with strings. This would be a good problem to review whether I'm using string types efficiently. Python: I could benefit from knowing how to get an array from a map.

Rust: Oh man. Debugging imperative programs is a bitch. Starting to remember why functional programming became a thing. Interestingly, my caching strategy doesn't appear to make any difference in performance. Python: Why was this soln faster to run than my rust soln?

Rust: futzing with bigint crates (num::bigint is a lie), then converting a char to a digit. Python: haha amortized big int type go brrr

Looots of time figuring out where my off by ones were (screw english), looking around until finding I miscounted the number of letters in 40 and 80, when I should have just spelled em out and let the program count for me. Starting to ask myself, how can I implement such that I spend the least possible time debugging. Especially tedious detail problems like this one.

Apparently I'm pretty rusty (eh) at recursion. Took over an hour on the first try, but I was running in the wrong direction. Started again from scratch on a second try, trying to be a bit more thoughtful. This was the hardest problem for me so far, by about 2x, and I'm sure there were more elegant ways to implement. Even just translating my solution from rust to python took an half an hour, even without much debugging to do. This one is one to review.

Removed as outlier

uniformly distributed sundays, not uniformly distributed amount to complete problems

Rust: reasonably easy problem, with a couple of lazy implementation choices. Python: figuring out how to use some functional tools

Both: reasonably straightforward, just cleaning up fiddly details

First tried to use a slow factoring and filtering algorithm, was too slow, thought of a better iterative strategy

Screwed around with implementing my own permutation algorithm before using a library method

The euler gods swore karmic punishment for my getting too used to bigints being the natural solution.

Removed as outlier

Reasonably straightforward, still using a lazy prime algorithm

Turns out, a million values is too many for a recursive algorithm in Rust. makes me a lil sad. ran into a weird python quirk about creating 2d arrays

Easy street compared to the last couple, I may be getting better though

Another straight forward implementation

Surprised this recursive algorithm took so long

Surprisingly many edge cases in my algorithm

Played around with generics in Rust for funsies, was inefficient ofc; otherwise not that complex

Probably much slower if I recalculate the factorials everytime

Straightforward to develop a python algorithm

I must be getting better at pythoning

Starting to feel repetitively easy

Hardest one in a while, Review this one!

Took a longer route than possibly necessary, review

Could have used a prime sive to expedite algorithm, instead of lazy factoring algorithm.

Took a little time to figure out how to check permutations, settled on a slightly incorrect algorithm

about half time spent debugging

tot hours:

It takes about 1.5x as long to develop a rust solution than a python solution

Translating a solution takes about 12.5 minutes on average, in either direction

Problems that would take 35 minutes or more to solve in Rust have a plausible speedup if first solved in python then translated (20m solve +13m translate)

I disincluded the two outliers where I started in Rust and failed to efficiently develop a solution.