> How often do you have to derive novel algos? I have done what you could call deriving novel algorithms, and in a commercial context no less[1]. What is or i

> How often do you have to derive novel algos? I have done what you could call deriving novel algorithms, and in a commercial context no less[1]. What is or is not an algorithm not very well defined. There was a famous paper which defined an algorithm as "logic + control", which could really describe any code that we write. I think what the experience taught me (where a CS education might help) was how to think algorithmically. The point of algorithmic thinking and algorithmic code is to be able to prove (formally or informally) that certain undesirable states are impossible. Algorithms focused around performance have proofs that unnecessary computations are not performed, cryptographic algorithms have proofs that secrets are not revealed during the computation, concurrency algorithms prove that data races do not occur, and so on. It's actually quite easy to apply this sort of thinking to highly problem-specific code. The more specific the code is, the stronger the guarantees you can prove. What becomes more difficult is writing code that is both generic and is able to make interesting guarantees about the state space of it's execution. It's the code that kind of code (generic with strong guarantees) that are what people typically mean by "algorithms". [1] Not really as bad as this https://xkcd.com/664/ https://xkcd.com/664/