ryanvarick.com

Location: ryanvarick.com » Capstone » Analog Configuration Language (edit)

Right now, this page is just a place for me to collect my thoughts. I have this nagging thought that genetic algorithms are only one part of the analog development experience. Coming up with good fitness functions is hard, and it's only going to get harder as the low hanging fruit is picked. I wonder what an "analog programming language" looks like. More to come!

Things to do


Core thoughts:


More points:

  1. The notion of an analog configuration language seems to have shifted toward Bryce's command language; we need a new term
  2. This may be related to the notion of genetic programming

Preliminary Notes

Motivation: Digital programming does not map cleanly to analog. Analog machines are configured to solve problems. Their operation, post-configuration, is essentially fixed [tangent: what are the implications of dynamic analog configurations?]. Thus development relies on the discovery of configurations sufficient to the task at hand.

Current techniques: Right now, we think evolutionary algorithms are the way to go (any search algorithm will likely do though): enumerate the set of possible configurations (large) and smartly evaluate candidates until suitable configurations are discovered. This is not unlike techniques used for neural networks, etc.

Fitness functions: Implementing a genetic algorithm and EAC-interaction layer are rather trivial tasks. The real meat of analog development is in the fitness function. Writing good fitness functions is hard. This is the motivation for a configuration language.

Conflict: Configuration language seems to an emerging term to describe the control sentences used to configure the EAC/uEAC. Perhaps fitness language would be a better choice?

Questions

Language Elements