|
|
|
|
|
|
by hasmanean
1706 days ago
|
|
|
While I was teaching c++ I would sometimes look at programs from a colleague and try to rewrite them in a more teachable form using c++14. The abstraction capabilities in modern c++ made it more fun and allowed me to condense programs in totally unexpected ways. More abstract code was simpler and sometimes easier to understand. But after a while (usually my version 4 or 5) if I abstracted it too much (Templatized it, made work for Unicode or char types) etc. the complexity would shoot up again. It became incomprehensible even to me even though I had written it. I knew it worked because it gave the same result but it was no longer anchored/rooted in anything real. There is a zone of usefulness that is between the completely abstract and the concrete. Physics lives in this zone…it uses mathematics but they don’t feel the need to generalize to N dimensions or to assume the constants of nature are variable—unless they have to. This is why all good descriptions of mathematics start by showing a concrete problem they want to solve. Gauss invented the FFT algorithm to simplify his calculations of the orbit of Ceres. He had the numbers in front of him and tried to reduce his computational workload by exploiting a repeated pattern in the computations. Teaching the FFT as a fait acompli and showing asteroid orbit as a sample application is ass backwards. |
|
|
(A toy example of the 'square' thing - imagine you have to make 10,000 widgets for 1 dollar each. Making them all by hand for $1 without optimizing the process would be inefficient. So would spending $9,999 to build a machine which could make widgets for $0.0001. But spending $100 to optimize production so you can make the widgets for $0.01 each is a massive win ($200 cost vs. $10,000 for the other alternatives.)