Long-haired programmer; loves cats and dogs but doesn't have any.

- !!Con
- Trailing zeroes of falling factorials
- Game Mechanics from Shadowrift
- my new filing technique is unstoppable
- Establishing a market for ideas
- Production rules for search (and lex ordering)
- Analogy problems
- Estimating debugging
- Paper and pencil collaborators
- Trying to work
- Linkdump
- Empowerment
- Understanding Ceu using Shenzhen I/O
- Pólya urn
- Little interpreters
- No Man's Sky
- The Secretary Problem
- Newsvendor problem
- Survival games
- Ego lens
- Elm Architecture in C++
- Mission and Space
- A little story engine
- Yet another coupon collector's problem blog post
- Reification
- Spreadsheets
- Underdrawing
- Linkdump
- Race games
- Links that I thought were interesting
- Links that I thought were interesting
- Modeling Shmups in Machinations and Ceu
- Modeling Pipe Dream in Machinations and Ceu
- Context Free Grammars for Learning
- SPSC.py howto
- Viva Pajaro and Wardley Mapping
- Where do objects come from? III
- Where do objects come from? II
- Stardew Valley and figure ground reversal
- Meta II by Val Schorre
- Citations, Elisions, and Arguments
- Where do objects come from?
- Protocol Buffers
- Dataflow Bench in Java
- Abstract nonsense continued
- Abstract nonsense
- A Douche-Free bio
- Wiring Idiom in C++
- Dataflow Bench in C
- Visitor Pattern Generator in C++
- First Post
- Elm Architecture in C++

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.

Opinions expressed are solely my own and do not express the views or opinions of my employer.