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

Control rate

Where to insert the (s,i)->s function?

This should probably be done at a fairly deep level, i.e. when
defining feedback functions.

Doing this in the ai-lambda-feedback form, passing an extra `setup'
argument to ai-feedback/n

This gives implementations access to the function body of the state
setup function.


Using a special-cased approach: doesn't work.
It should really be a composition of two functions:
- One feedback processor run at control rate
- One .. at sample rate

The beef is in how parameters are passed between the two.



Still confused about the approach to take

1. Implicit: don't change semantics, but just depend on loop
hoisting[1] to take care of the efficiency issues.

2. Explicit: allow for control-rate state machines


If an approach based on hoisting is used, it might be good to just
leave it entirely to the low-level compiler (GCC / LLVM).

The good thing here is that I can focus on semantics now, and focus on
implementation/optimization later.

This means the only missing parameter is N, the current block size.
This will be a semantics extension to the feedback/n code.

What about this: add an extra set of parameters to feedback functions,
expresing the time loop index and block size.

The subtle but nice thing here is that the time invariance /
block-based properties are implicit: using/not-using t (current time)
or T (max time == block size) fully determines this.

One problem though: this does not work for state normalization
operations.  It might be best to include those in the operations.


Conclusion: control rate ops split into 2 cases:
 - hoistable, no effect on state (just expose t and T)
 - performed on state


[1] http://en.wikipedia.org/wiki/Loop-invariant_code_motion



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