Previously Alex Altair and I published a post on the applications of chaos theory, which found a few successes but mostly overhyped dead ends. Luckily the comments came through, providing me with an entirely different type of application: knowing you can’t, and explaining to your boss that you can’t.
Knowing you can’t
Calling a system chaotic rules out many solutions and tools, which can save you time and money in dead ends not traveled. I knew this, but also knew that you could never be 100% certain a physical system was chaotic, as opposed to misunderstood.
However, you can know the equations behind proposed solutions, and trust that reality is unlikely to be simpler[1] than the idealized math. This means that if the equations necessary for your proposed solution could be used to solve the 3-body problem, you don’t have a solution.
[[1] I’m hedging a little because sometimes reality’s complications make the math harder but the ultimate solution easier. E.g. friction makes movement harder to predict but gives you terminal velocity.]
I had a great conversation with trebuchet and math enthusiast Hastings Greer about how this dynamic plays out with trebuchets.
Note that this was recorded in Skype with standard headphones, so the recording leaves something to be desired. I think it’s worth it for the trebuchet software visuals starting at 07:00
My favorite parts:
If a trebuchet requires you to solve the double pendulum problem (a classic example of a chaotic system) in order to aim, it is not a competition-winning trebuchet.
Trebuchet design was solved 15-20 years ago; it’s all implementation details now. This did not require modern levels of tech, just modern nerds with free time.
The winning design was used by the Syrians during Arab Spring, which everyone involved feels ambivalent about.
The national pumpkin throwing competition has been snuffed out by insurance issues, but local competitions remain.
Learning about trebuchet modeling software.
Explaining you can’t
One reason to doubt chaos theory’s usefulness is that we don’t need fancy theories to tell us something is impossible. Impossibility tends to make itself obvious.
But some people refuse to accept an impossibility, and some of those people are managers. Might those people accept “it’s impossible because of chaos theory” where they wouldn’t accept “it’s impossible because look at it”?
As a test of this hypothesis, I made a Twitter poll asking engineers-as-in-builds-things if they had tried to explain a project’s impossibility to chaos, and if it had worked. The final results were:
36 respondents who were engineers of the relevant type
This is probably an overestimate. One respondee replied later that he selected this option incorrectly, and I suspect that was a common mistake. I haven’t attempted to correct for it as the exact percentage is not a crux for me.
6 engineers who’d used chaos theory to explain to their boss why something was impossible.
5 engineers who’d tried this explanation and succeeded.
1 engineer who tried this explanation and failed.
5⁄36 is by no means common, but it’s not zero either, and it seems like it usually works. My guess is that usage is concentrated in a few subfields, making chaos even more useful than it looks. My sample size isn’t high enough to trust the specific percentages, but as an existence proof I’m quite satisfied.
Conclusion
Chaos provides value both by telling certain engineers where not to look for solutions to their problems, and by getting their bosses off their back about it. That’s a significant value add, but short of what I was hoping for when I started looking into Chaos.
I don’t think it’s a value-add, because this sort of proof-by-intimidation abuse is how chaos theory gets used in many places, such as here on Lesswrong as well, not just engineers fighting their managers. Remember the proof that humans can’t get high scores playing pinball because ‘chaos theory’? It’s just an indiscriminate rhetorical weapon. It is not true in the case of playing pinball, it is probably not true of trebuchets in general (as opposed to cheap simple trebuchets constructed for contests or the Third World), and I would be surprised if all of those 6 successful manipulations were the valid exceptions. It is similar to the pervasive abuse of Godel or the Halting theorem; you doubtless could successfully convince some managers to not bother with things like typechecking or unit-tests or formal proofs because “Turing proved it is impossible to prove things about arbitrary programs” etc, but that is not a good thing, it is a bad thing.
Ah, this is not quite the takeaway- and getting the subtlety here right is important for larger conclusions. If a simulating a trebuchet requires solving the double pendulum problem over many error-doublings, it is not a competition-winning trebuchet. This is an important distinction.
If you start with a simulator and a random assortment of pieces, and then start naively optimizing for pumpkin distance, you will quickly see the sort of design shown at 5:02 in the video, where the resulting machine is unphysical because its performance depends on coincidences that will go away in the face of tiny changes in initial conditions. This behaviour shows up with a variety of simulators and optimizers.
An expensive but probably effective solution is to perturb a design several times, simulate it several times, and stop simulation once the simulations diverge.
An ineffective solution is to limit the time of the solution, as many efficient and real-world designs take a long time to fire, because they begin with the machine slowly falling away from an unstable equilibrium.
The chaos-theory motivated cheap solution is to limit the number of rotations of bodies in the solution before terminating it, as experience shows error doublings tend to come from rotations in trebuchet-like chaotic systems.
The solution I currently have implemented at jstreb.hgreer.com is to only allow the direction of the projectile to rotate once before firing (specifically, it is released if it is moving upwards and to the right at a velocity above a threshold) which is not elegant, but seems mostly effective. I want to move to the “perturb and simulate several times” approach in the future.
I do want to note that a lot of the claimed unpredictability from chaos only works if you can measure stuff to a finite precision only, and while this is basically always true in practice, it is worth noticing, because if you did have the ability to have an infinite memory and infinite FLOP/s computer with infinitely precise measurement, like in Newtonian physics, chaos theory doesn’t matter, because in a deterministic system, if you get the exact same input, it will always have the same output, so chaos doesn’t matter.
To be clear, this isn’t a practical way to beat chaos, but it is an exception to the rule that chaos makes a system unpredictable.