Bangbangcon is wonderful. Each talk hits hard, motivating me to move in different directions.
For example, after Charles Chamberlain's talk about the jq programming language, I would love to study jq and implement some lovely and/or clever and/or useful code in it. But after Jan Mitsuko Cash's talk about flocking, I want to study flocking, and try bringing other techniques, like Mike Cook's stuff to the problem of setting the parameters of flocking in order to yield distinct effects. But after Scott Vokes's talk about how keyboards work, (and particularly Limor Fried's talk) I want to do more embedded things! But then after talking with Walt Mankowski about COBOL, I want to write COBOL, and really coherently analyze what aspects of COBOL are excellent, what aspects are excellent solutions to problems that are less salient now, and what aspects of COBOL are simply mistakes.
Sigh.
I have been obsessed with bond graphs for a long time, so maybe I could instead work with that.
Bond graphs are a technique for organizing a particular kind of mathematical model of a particular kind of phenomenon.
The type of mathematical model is sometimes called "ODE", or "state space model", or "lumped element model". The type of phenomenon is when there is a locally-conserved quantity that you want to take special care of - usually energy. These sound complicated, but they're REALLY common.
Techniques that sound like they are "bigger" or "better" - like "partial differential equations" or "finite element modeling", tend to assume that you can do ODE modeling. That is, you cannot escape ODEs or state spaces or lumps by fleeing into continuous space.
When you are modeling, you want to "cut at the joints". That is, you want to partition the whole into subparts which are nearly decoupled. The bond graph trick, which is from electronics, is to expect the math to be able to capture the remaining coupling as the conserved quantity (usually energy) traveling, over time from one subpart into the other. That is, if you make a modeling decision (such as to cut component Foo apart from component Bar), then the model should have a variable or formula, which is the power (power is energy per unit time) flowing from Foo to Bar or vice versa.
Moreover, (and this is still the bond graph trick) that power should be expressed by two variables, which multiply to form power - one part determined by the model of Foo and one part determined by the model of Bar. In electronics, these are the voltage and the current.
Two specific examples from electronics:
- If we split off one component, and model it as a resistor, then we might say the rest of the circuit will provide the resistor a voltage, and by Ohm's law, compute the current, which the resistor provides back to the rest of the circuit.
- If we split off a component, and model it as a capacitor, then we might say that the rest of the circuit will provide a current through the capacitor, and the capacitor will integrate that, multiply by a constant, and provide that back to the rest of the circuit.
The bond graph trick is FROM electronics, but it's more broadly applicable. In particular, force and velocity of a point in mechanical engineering work exactly analogously.
Business bond graphs lean on a different conserved quantity - cost. If you divide a business situation into two components, then the flow of cost from one to the other is expressed as a price of some transaction, determined by one component, and a rate of transactions of that type, determined by the other component.