Fri Mar 29 19:19:19 EDT 2013
BUG: dependency problem
It's possible to pass parameters defined inside the time loop into
setup routines, which are executed before the time loop.
EDIT: Let's see what happens if this is fixed in the ai-array.rkt module.
Using a straightforward approach: if it's in the setup loop, the type
is scalar, and if it's in the update loop, the type is time-indexed.
Another approach: keep everything virtually in the same loop (all
time-indexed), but allow time-indexed values to be subsampled.
Essentially lifting stuff out of the main loop?
Maybe what this means is that each operation has 2 instances: one
outside of the time loop, referenced as t, and one inside.
Alternatively, unroll the time-loop such that at t=0 some setup code
executes, and at time=1...t_endx the rest will run.
It's too complicated / to ad-hoc.
This needs to be split into two parts: the dual sample-rate operation
should be constructed as a composition of two state machines, both
operating on the same state type.
(s,i,p) -> (s,o)
(s,i,p,t) -> (s,l)
(s,i,p,t,l) -> (s,o)
The problem with the current approach is that due to composition, the
i can actually be streams represented as temporary, scalar nodes
inside the time loop.
So basically, for any computation that depends on i, there should be 2
versions: one based on i to be included in setup calculations, and
one based on i[t] to be included in the main loop.
So maybe, this should just evaluate the program two times. Combined
with lazy nodes, this will also take care of unused intermediates.
Problem solved. Roadmap:
- implement lazy network construction
- implement 2-step evaluation