The shift by this type signature should take in arrays of length s and produce arrays of length k. However, in the example, it takes in arrays of length k, and produces them of length k with new starts every s elements. I think this comes from a combination of two concepts: changing amount of parallelism and shifting in parallel. Two options for fixing this are:
(1) adding another parameter so that the input parallelism, output parallelism, and amount of shifting can be tuned separately. The type signature would then be
shift_x p_in p_out s :: {1,T[p_in]} -> {1,T[p_out]}
and an example
shift_x 3 4 2
[1 2 3]
[4 5 6]
[7 8 9]
[10 11 12]
to
[1 2 3 4]
[3 4 5 6]
[7 8 9 10]
[9 10 11 12]
(2) creating a separate operator for changing rates of parallel and including that in the stream type. This would then be composable with the shift operator. I think rates of input and output parallelism are going to be an issue we see frequently. A composable operator may solve the problem more generally.
(still working on how to integrate these ideas into those SDF definitions)
David-Durst
commented
6 years ago
https://github.com/David-Durst/aetherling/blob/26f1b57590cac4f9d8b2a9da7fab295c4eaa8b94/spacetime.txt#L37
The shift by this type signature should take in arrays of length s and produce arrays of length k. However, in the example, it takes in arrays of length k, and produces them of length k with new starts every s elements. I think this comes from a combination of two concepts: changing amount of parallelism and shifting in parallel. Two options for fixing this are:
(1) adding another parameter so that the input parallelism, output parallelism, and amount of shifting can be tuned separately. The type signature would then be shift_x p_in p_out s :: {1,T[p_in]} -> {1,T[p_out]}
and an example shift_x 3 4 2 [1 2 3] [4 5 6] [7 8 9] [10 11 12]
to [1 2 3 4] [3 4 5 6] [7 8 9 10] [9 10 11 12]
(2) creating a separate operator for changing rates of parallel and including that in the stream type. This would then be composable with the shift operator. I think rates of input and output parallelism are going to be an issue we see frequently. A composable operator may solve the problem more generally.
(still working on how to integrate these ideas into those SDF definitions)