>>15016
>Though in some cases, mostly comparisons, its important to be able to clearly model the relationships between different functions.
Exactly, but the specifics should be encapsulated in a way that the rest of the system can just pull the information it needs without needing to worry about how each module models its relationships. If something does need to be explicitly exposed to the rest of the system, like which volume that can be quickly grasped by a hand, it should be exposed as an optional value for other system modules to consume. Special functions and variables should never be required to predict common things, like the trajectory of a module.
For this particular book, the Hamiltonian is the "one equation" that each module needs to expose. It takes in a momentum, position, and potential field as input, and it returns total energy. Assuming something is keeping track of positions and momenta, this is enough to calculate how any module will change over time, and what candidate changes need to be applied to get a module to change in a particular way.
One unintuitive aspect of this is that it's not quite appropriate to try to control a system using forces directly. The problem with using forces directly is that every time something doesn't go exactly as expected, you need to recalculate how much force to apply. The "right" way to control a system seems to be through a potential field. A potential field tells you how much force to apply for every position that an object can be in. This lets you control things more smoothly, and as long as you don't end up creating some really chaotic dynamics, it should get you to the end state you want without requiring you to recalculate your trajectory every time something goes slightly wrong. The amount of force to apply should be calculated from the Hamiltonian: it's the partial derivative of the Hamiltonian with respect to position. So if you want to move the hand to a particular location, you should create some function that with a minimum at that location. From that function, you can caculate what for the apply no matter what position the hand is in, and that function can remain unchanged until the objective changes.
There are a plenty of frameworks that do automatic differentiation, some numerically and some symbolically, and implementing it should be relatively easy on the small chance that we need to do it ourselves.
I still need to spend more time thinking about how to make this more concrete and how to support all of the sorts of flexibility we would want in a dancing robowife, but the big picture that this book paints seems compelling.
>Derivatives are a vital concept and can't tell if you meant 1/2(v*Gv) or if you meant it to be another ^ sign.
You got it right. Sorry, I forgot that ' (apostraphe) usually means "derivative" and * (asterisk) usually means "transpose". The meaning of the symbols changes across fields, and it's hard to keep track of sometimes. The dot-over-the-variable-for-derivative in
>>15002 comes from the book, and it seems common in physics. The cross-(dagger)-for-transpose comes from a particular branch of math. I think the apostrophe-for-derivative and asterisk-for-transpose notation was much more common when I studied physics and calculus in school. If that makes my summaries easier to read, I can switch my notation to that.
>You might have heard of vectors and matrices.
>Yes I have. Though they were not really featured all that heavily at all. Its more helpful when programming a robowaifu's spatial recognition than anything.
I think the first time I used them in practice was for game development. Matrices and vectors show up there because it's much easier to model parts of an object from their own relative positions and have the parent object keep track of their reference frames. To render a parent object, the parent "switches" to the reference frame of each child object in turn and has the child render itself. This is possible because the game engine keeps track of a matrix that's used to automatically transform every vector the child uses. When any object multiplies the game engine's matrix with its own matrix, it's effectively changing the perspective used for rendering. So for a parent to switch to the child's perspective, it only needs to change the matrix that the game engine uses while rendering the child.
The same thing is going on here. The g and G matrices in
>>15002 play a very similar role to the game engine's matrix.