|
|
|
|
|
by vikiomega9
2529 days ago
|
|
What you're describing is not optimization the math field, and second _some_ of the example do have basis in mathematics. > Discovering some API I'm using is particularly slow and finding an alternate one that's faster.
On it's own it has nothing to do with Math, but writing code as components/services/abstract layers with well-defined boundaries/interfaces/types mean it's easier to reason about the code and avoid bugs. Implicitly here I'm saying we should use a language that has strong type support. > Adding caching.
This is memoization and without the basis that general code functions should behave like their math counterparts this is hard to reason about. > Reorganizing code to take advantage of vector instructions
These are mapping operations that are well defined in functional languages. The vectorized interface numpy provides is an abstraction of maps. > Making objects smaller to put less pressure on the GC
This is orthogonal to the actual math basis for the code. For example using enums over strings is a localized change. |
|