I've written simulators as a career for more than a decade, and I'm stunned at what a good job you've done. The simulation engine is excellent and the visualization is prettier (and more intuitive!) than any I've ever seen.
Growing up in Cincinnati, the Omnimax at the museum center was a huge influence. The light tunnel intro (one of many adapted from the Graphic Films Corporation logo [1]) absolutely blew my mind and gave me a lifelong obsession with computer graphics.
Apple | Senior simulation software engineer | C++ | Hybrid (3 days per week in office) | San Diego CA or Austin TX | Full-time
We're seeking an experienced software engineer to build simulations for the Satellite Communications Group. The job requires excellent geometric intuition and fluency in C++, but prior experience in satcomm is not necessary. We've had successful applicants with backgrounds in physics, graphics, FEM, control systems, and hardware. We get to work on really cool stuff and build systems that provide essential off-grid connectivity to users around the world!
This appears to be by Kenta Cho, a.k.a. ABA games, who has a long history of writing wonderful small games in D. His work is well worth checking out. https://www.asahi-net.or.jp/~cs8k-cyu/
Power conversion losses account for about 60% of the energy that goes into electricity generation in the US [1]. Superconducting generators and transformers could take that figure down to a fraction of that.
These algorithms work best on smooth functions with mid-to-low 100's of variables. They are very sample efficient, often obtaining superlinear convergence using just a linear number of evaluations of the objective function.
I'm very glad to see these algorithms get the maintenance they deserve. I pulled them apart and used lots of their pieces and theory for my PhD; MJD Powell's original code was subtle and difficult to understand. Hats off to those doing to the hard work of keeping them alive. These algorithms are the absolute best in their domain, and should be more widely known.
You raise a very good point in that the "formulate the problem the way the solver wants" step is legitimately difficult and full of pitfalls. Simply figuring out the translation can be hard, and even then there are many ways to formulate a problem which are mathematically equivalent but have drastically different performance when fed to the solver.
It really feels like a tools or language problem. Heck, we used to have to manually work out derivatives for continuous optimization problems, but nowadays programming languages with performant built-in autodiff often make this trivial. Removing the manual derivation hassle let loose a flood of cool ideas and applications, even though there was no technical hurdle preventing them in the first place.
Alternate problem specifications is a well-explored area (what is Prolog if not a way of describing problems for a constraint satisfier?), but I wonder how many other neat things are dammed up behind usability problems.
Both companies are huge and contain multitudes; they can easily do praise-worthy and scorn-worthy things at the same time. It's worth calling them out separately rather than trying to unilaterally love or hate the whole mess at once.
That said, with FB/Google these days the bad weighs more than the good.
> Is it? Some of my friends went on to start successful companies after getting their PhDs. I'm a bit envious of them actually, I didn't have that option as my research was on an obscure topic with zero commercial potential.
Agreed, a PhD is absolutely not useless in this industry, even if you don't end up in the research community. Understanding where the research frontiers of various fields are and being able to quickly find / digest relevant technical papers feels like a superpower. The gap between an undergrad education and a research frontier is enormous, and only working on a PhD really gives you the time and incentive to cross it. Having done it once, it gets easier to do it again.
For me, it has turned a huge volume of "unknown unknowns" into "known unknowns" and equipped me with the tools to then convert those into "knowns". Without it I'd be a fine coder, sure. With it I can work on a different tier of projects, and direct my career much better.
The costs are very real, though. Giving up ~6 years of early career earnings in a high-paying industry is utterly insane; you will never, ever make it up short of your startup lottery ticket number coming up. It's a meat grinder for mental health. Dozens of things outside of your control can go wrong and torpedo your aspirations. It is the right choice only for a vanishingly small minority.
You're correct, autonomous vehicles are absolutely not to the point where highway robbery is a prime concern. But even if they were, the spoofing issue isn't just another tough problem to solve. It's a potential arms race.
Faking out machine learning systems is rapidly progressing from a few "fun proof-of-concept" examples to a serious area of study, and we've already seen it (gently) applied to autonomous vehicles [1] (ignore the overblown headline, it's just a piece of tape on a sign).
I competed in the DARPA Urban Challenge, back in 2007. While we were watching the finalists trying to sort out the world's first fully-automated traffic jam, the conversation turned to how easy it is to manipulate these vehicles.
Imagine a remote stretch of highway frequented by automated 18-wheelers. All that's required to bring the truck to a screeching halt is a bedsheet and some decent timing, at which point the vehicle has no way to prevent a robbery. The truck could put in a remote distress call, but it will still be some time before a human can get there. It's a new era for railroad heists!
We're no closer to solving this problem than in 2007; everybody is still trying to manage the long tail of merely safe driving. Handling humans in adversarial situations like the above is still completely off the map.