Going to get into introductory analysis soon too myself! The one tip that I have been given is to build intuition by taking/relearning the computational part of calculus before diving into the rigorous part of things. Hopefully someone else can weight in on the value of the tip
Proof writing. Sat down with a textbooks and partial solutions at the back. Took a year as I had other priorities. Advice:
1.Regardless of which route you choose to go whether probability theory, algebraic geometry or optimization algorithms, do a course in proof writing. Absolutely do not skip it. It will teach the fundamentals and most importantly patience and persistence
2. If you're a programmer, prepare yourself for a much larger feedback loop. Unlike code which can just be executed and you have the satisfaction of seeing something sorta work at first try, math is a completely different beast. It will punch your expectations in the face, and the progress points you celebrate will be a joke compared to what you are used to with code
3. Screw the videos, just sit down with a hardcopyand work through the theory and most importantly work through the problems.Try to get a textbook with a partial solution set.
4. Practice Practice Practice your fundamentals
5. Have realistic goals and timelines! People trip up here big time
6. Be prepared to dive into things that at first glance may seem unrelated. Don't skip chapters just because you think you don't really need to make progress towards your topic of interest. More often than not, you'll end up coming back
7. Celebrate the small milestone
8. Expect things to get exponentially difficult as you go along.
9. Learn how to manage extreme frustration and learn to keep your promise to come back to a problem you couldn't solve again and again. Nothing ever gets done in one sitting especially if you're learning.
10. Mixup things to make sure things don't get boring!
I sincerely think that the minute you stop thinking that Math cannot be applied to a problem solving situation or Math is too fancy/theoretical, the Tower of Babylon type problems starts
This is what I read in this article. The author has a problem with people thinking that rote-learnt algorithms is the best thing ever, and proceeds to say nope a stash of the most subjective heuristics to produce 'good code' is wayyyy better. All in all the way I see it, the author is proposing to supplant a shittty misconception with a bs idea that is nice short term solution but a complete disaster in the long term which has inculcated into this idea that programming is an Art and not a discipline.
Organization is a mathematical and algorithmic problem regardless of the context. And if you think people go to school so that they mug up algorithms, you're missing the point of school. You go to school to learn how to problem-solve, how to model problems mathematically and incidentally become aware of a repo of solved problems which may help you in your own problem solving adventures.
I don't understand this! Math is a super set of algorithmic wizardry and if you include heuristics in algorithmic wizardry (why would you not?),isn't organizational skills a part of the Algorithmic Wizardry? So he's saying that knowing all skills in the subset is better than knowing all the skills in the set? And that's just the headline
The article states the guy says when you have n objects you have n^2 possible collisions, if you're assuming just one on one interaction and an object cannot collide with itself shouldn't it be n*(n-1)? Am I missing something here?
Resilient in what sense?able to come back and pretend like nothing happened or gloss over and hope things will be alright? Isn't that why we are trying to do away with people?
About the second thing you've surely that cannot be true in all cases. A vote guarded by a mathematically difficult number theory problem can be hard to crack than a ballot box guarded by a grumpy human who feels he/she has better things to do. I believe one must not forget the cost of assembling such problems and maintaining such problems
One, I think the article doesn't underline why a paper based system would be better than a paperless method other than giving examples of hacked paperless system and weird claims like paper methods are bullet proof provided they are marked clearly and properly(what? That is one of the reasons for starting off paperless methods in the first place) A method that relies a lot on human based management and logistics is bound to fail in more ways than methods that use less of the same. Paper based methods involves a lot of human pieces than a paperless method (electronic methods and the likes). I may be wrong, but our shift towards automation clearly highlights the former. Any thoughts anybody?
Quite honestly, I feel if you think Haskell's beauty is somehow in any way associated with masochist mindset , you most likely think Maths is associated with a masochist mindset and (assuming math defines reality) the true nature reality is only viewable to those with a masochist mind. Then friend, I truly am a masochist
Having learnt Haskell as my first programming language, sure it has a high learning curve but it pays off in so many ways. It is without doubt the most beautiful language ever conceived. Without doubt it is the right language to unlearn imperative bs and the right language to learn functional programming principles. Even against the likes the of lispy langs and other ml flava, Haskell reigns supreme with it's purity
Thank you for the reply. I do appreciate the list of thoughts especially how learning new words to help in forming new concepts from math and the likes. I do cook and bake as a hobby though not as actively as I should. Will go down the short story route as you suggested