Yup, that’s pretty much what the code is doing – just to add:

The encoder get’s the whole sequence at once, while the decoder generates tokens/values time step by time step.
The decoder also gets some inputs x_i but x_1 is some fixed start value (0.0 in the code but can technically be anything), and x_(i+1) = output_i – that is, the input for time step i+1 is the last prediction of the decoder at time step i. That’s the input = output.unsqueeze(0) line. So strictly speaking the input for the decoder shouldn’t be opaque, but I get your point.
An extension of this model would be to use “teacher forcing” in the decoder, where for some examples in the data, not the predicted output is used as next input but the true values. You can read up on this in the PyTorch Seq2Seq tutorial, but it’s not important right now.

This figure makes it very clear how the decoder works by taking the last output as next input, and starting with a defaut token <START> (which is the 0.0 in the code since deal with single values)

seq2seq.png1585×477 46.1 KB