Mark H. Patten
Links
These are some random links that I find interesting and want to keep handy. I only just started this page, so I will be adding to this occasionally...
NUMERICAL RECIPES
I've found this book Numerical Recipes (formerly Numerical Recipes in C) more than just a source for code---it's been a reference for learning and understanding numerical methods. It covers both mathematically intensive methods and more mundane topics (such as data sorting). I more throughly understood many algorithms such as the FFT after reading this, and learned about interesting non-deterministic numeric methods (such as simulated annealing to solve NP hard problems such as the Traveling Salesman problem). It's also fun to read, with puns---I remember one admonishment to good coding practice: "All programmers that continue to [write grossly bad code] will be executed, and their programs won't be!"
BEAMFORMING AND DOA
This is a pretty good coverage of the concepts of beamforming, direction-of-arrival (DOA), and phased arrays in general. Techniques such as MVDR/Capon and MUSIC are introduced and demonstrated using Python simulation examples. I find the "Beamforming Taxonomy" chart especially useful."
THE UNEXPECTED COMPLICATIONS OF MINOR FEATURES
Often we get suggestions for what sound like small, quick features or tweaks. These can be things like adding a new parameter, or tweaking some user interface to be easier to use. These are often nice because a small amount of work turns in to a quick win, and users like seeing the changes they want happen. However during the process of actually doing the necessary work, it can turn out to be much more work than originally expected.
ALWAYS DO EXTRA
Assume there's a reasonable amount of work you need to do to fulfill the base expectations for your job (i.e. your Normal Work) and then there's a little time left over. In this remainder time you have a choice: you can do More, Extra, or Nothing (i.e. surf the interwebs). And it's with this decision that every reasonably happy, veteran developer distinguishes themselves. They all choose Extra.
SOFTWARE ESTIMATION IS HARD. DO IT ANYWAY.
It’s well-established that estimating software projects is hard. One study by HBR found that one in six IT projects had cost overruns of over 200% and were late by almost 70%. Another study by McKinsey found that IT projects are on average 45% over budget and 7% over schedule. They found large software projects were particularly bad: software projects with budgets over $15M went over budget by an overage of 66% and had schedule overruns averaging 33%.
HOW TO LEARN ADVANCED MATHEMATICS WITHOUT HEADING TO UNIVERSITY
How to go about learning the necessary mathematics for getting a job in quantitative finance or data science if it isn't possible to head to university? This article is a response to that question---it discusses how to become a mathematical autodidact using nothing but a range of relatively reasonably priced textbooks and resources on the internet. While it is far from easy to sustain the necessary effort to achieve such a task outside of a formal setting, it is possible with the resources (both paid and free) that are now available.
CHESTERTON'S FENCE: A LESSON IN THINKING
“Do not remove a fence until you know why it was put up in the first place.”
The lesson of Chesterton’s Fence is what already exists likely serves purposes that are not immediately obvious.
BOUNCING BLOCKS TO CALCULATE PI
This video is amazing: The number of collisions between blocks and a wall, sliding on an imaginary frictionless table, and bouncing off each other and a wall with perfect elasticity, predicts the value of Pi!
ORACLE OF BACON
I'm fascinated by the math behind the "Bacon Number" calculation, particularly in the idea of the "Center of Hollywood Universe," defined as the actor with the lowest average number for himself to every other actor---although Kevin Bacon is indeed close to the "center", he's not at the very center!
I occasionally post my thoughts on platforms like Medium, Substack
and other groups etc., participate in various learning/programming events and
sometimes even speak at one!
“Engineering is achieving function while avoiding failure.”
– HENRY PETROSKI
MARK H. PATTEN
MARK H. PATTEN
Electrical Engineer/Embedded Programmer