3 ms·
There are two different problems actually : what you write, and the quantitative aspects of your code. What you write may or may not have a strong maths compo
by Agingcoder 6y ago
There are two different problems actually : what you write, and the quantitative aspects of your code.
What you write may or may not have a strong maths component ( game engine vs crud app say, or PDE solver vs typical 'plumbing' app).
However, the moment you start having performance issues (and this is everywhere), maths comes in very handy : big o, back of the envelope calculations, orders of magnitude, etc. You may call it engineering (and to a large extent it is), but I tend to lump quantitative reasoning on the math side and not on the compsci/engineering side. It's not necessarily extremely sophisticated, but having a 'quantitative view' of your code can help a lot.
I remember many many years ago developing a sudden interest in algorithmic complexity (and what quadratic meant..) after having used a bubble sort to sort polygons in my 3d engine. Needless to say, log became a fairly interesting function after reading a bit more on sorting!
- wendello 6y agoI'm self-taught with minimal maths and this is something I've used. I started re-learning some basic math for fun and now I find it helpful now to visualize mathematical models of some basic runtime characteristics of my programs. A simple example is that I will visualize X number of users firing Y number of requests, and I'll actually imagine this as a live system with various statistical properties (% of errors and the like). It's not typically strictly mathematical—I don't write down many (if any) numbers or symbols—but I'm creating a quantitative model in my mind to think through the behavior of my program when actually in use as opposed to a sequence of logical commands like I usually do.
- Agingcoder 6y agoIndeed! I very much agree with the model vs sequence opposition. Another useful side of the model / math approach is that it allows you to formalize your problem and derive hard bounds, ie know in advance what's achievable and what's not (the 'let' s derive a bound' approach being another standard method in maths).