[<<][meta][>>][..]
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[0], 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.

global:
(s,i,p) -> (s,o)

decomposed as:
(s,i[0],p,t) -> (s,l)
(s,i,p,t,l) -> (s,o)

The problem with the current approach is that due to composition, the
i[0] 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[0] 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



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