[<<][meta][>>][..]
Fri Mar 15 15:16:02 EDT 2013

Control rate combinators

Since hoistable expressions don't cover all cases, it's probably best
to split this into two parts: a state normalization / initialization
function, explicitly computed before the loop is executed, (and
possibly looping over a couple of states), and a loop function.

Trouble is: the state initialization function might produce constant
parameters that are not state parameters of the inner loop.  How to
glue these together?

  (s,i)   -> (s,l)  ;; Once
  (s,i,l) -> (s,o)  ;; Multiple times

This is actually not such a bad idea, since it also gives a way to
integrate block processing.

Let's let this ferment a bit more.


On the surface this isn't much more than a single state update, and a
way to push the `l' variables from setup block to loop block.
However, it does need to indicate to the caller where the final state
is stored, e.g. returning t&1.  Otoh, a state init phase could be
mandated for all loops.

This should probably be defined at one place, i.e. ai-lambda-feedback.

Maybe a state post-roll should be defined also, for symmetry's sake.
This would allow some statistics to be gathered as outputs?

EDIT: So, we're there.  A setup method exists and is pushed into
feedback/n.  However, it is not clear yet how to use it.  For
ai-array.rkt this needs to somehow capture all the bindings and push
them outside of the loop.


EDIT: There's a double assignment that shows up in the state setup
code.  This can be split by defining 2 so structs.




[Reply][About]
[<<][meta][>>][..]