6.001 Structure and Interpretation of Computer Programs. Copyright o 2004 by Massachusetts Institute of Technology Slide 17.5.34 Streams Programming In fact this idea of thinking about these stream structures as infinite sequences of things that are generated as needed relates very nicely to a way of thinking about programming that is different than what we have seen so far. In fact. stream programming looks a lot like traditional signal processing. And what does that mean? Slide 17.5.35 Streams Programming If we were to think about processing an audio signal, for example, the standard approach would be to consider some input signal x as a sequence of values. Then we would generate an output signal y by taking X, delaying that signal by some small amount, amplifying it by some process, then adding th value back into the input signal. This is a standard feedback loop, in which we get an output signal by processing some input signal. Using streams we can capture this idea of signal processing very cleanly Streams Program ming Slide 17.5.36 So we can capture this idea of a feedback loop very nicely in x【n streams. If x is our input stream, we can generate an output stream y by the following. The first element of x will just become the first element of y. To get the next element of y we · Streams mode: will use stream-cdr of x to get the second element of x ( this is equivalent to delaying the stream), map that element through a procedure that amplifies the values, and adds that value to the value of x we just computed. This generates an infinite stream of output values based on an infinite stream of nput values. Why would we like to have this process? It lead to a very common example of a feedback loop6.001 Structure and Interpretation of Computer Programs. Copyright © 2004 by Massachusetts Institute of Technology. Slide 17.5.34 In fact this idea of thinking about these stream structures as infinite sequences of things that are generated as needed relates very nicely to a way of thinking about programming that is different than what we have seen so far. In fact, stream programming looks a lot like traditional signal processing. And what does that mean? Slide 17.5.35 If we were to think about processing an audio signal, for example, the standard approach would be to consider some input signal x as a sequence of values. Then we would generate an output signal y by taking x, delaying that signal by some small amount, amplifying it by some process, then adding that value back into the input signal. This is a standard feedback loop, in which we get an output signal by processing some input signal. Using streams we can capture this idea of signal processing very cleanly. Slide 17.5.36 So we can capture this idea of a feedback loop very nicely in streams. If x is our input stream, we can generate an output stream y by the following. The first element of x will just become the first element of y. To get the next element of y we will use stream-cdr of x to get the second element of x (this is equivalent to delaying the stream), map that element through a procedure that amplifies the values, and adds that value to the value of x we just computed. This generates an infinite stream of output values based on an infinite stream of input values. Why would we like to have this process? It leads to a very common example of a feedback loop