[<<][meta][>>][..]
Fri May 24 19:06:10 EDT 2013

A proper map?

Seems that the reason I've used the implicit map and strict fold (no
outputs) approach is that it avoids the necessity for intermediate
arrays.  This might be quite a strong restriction in general, but for
audio it makes sense: everything will be accumulated at some point.

Is it possible to always write code in this style?  This requires
manual fusing.

E.g. can the FDN be implemented like that?

What it has is a map/reduce structure.

Ie.
-f--\
-f-- r
-f--/

It doesn't look like this can express parallelism followed by a mixing
relation like a matrix multiplication.

-f--|--g-
-f--m--g-
-f--|--g-

The advantage of the mapreduce is that it maps directly to vector
operations.  It works nicely for synth voices.

The basic idea for the mixing is that it necessarily requires more
than one pass, unless it is causal and can be expressed as a
"triangular" mixer.


The more general mixing is currently only possible using explicit
indexing.  This is where the FeldSpar idea of symbolic indexing comes
in.

Once map is implemented in such a way, it is probably best to do away
with the mapreduce / autolifting abstraction as a basic building
block.

So what would map look like?

It seems easiest to try to implement it for state i/o first, since
that has no artificial restrictions on arity.


  (define (_map sem fn arr-in)
    (let ((arr-out
           (lambda (i)
             (let ((el (arr-in i)))
               ;; cross-rank unify el and arr-in/arr-out
               (fn el)))))
      arr-out))

What if all nodes are arrays, and can be dereferenced (specialized) at
any time?  When is it time to evaluate?  At some point it will need to
be stored.

This delayed execution will wreck all kinds of havoc on the strict
evalatuation / imperative approach...  Maybe it should be explored as
a side path first.

Maybe this delayed eval is the reason why the "where" clause appears
in FeldSpar?  Or is that nonsense?


To put things in perspective: there is absolutely no problem for
functionality: we can always unroll and use compile-time operations.
The only "problem" there is is one of efficiency for e.g. large
arrays.


Conclusion:
- when does it eval the array?
- how does it interact with fold?
- does it need to memoize?




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