This is the second blog post of the “Towards Computational Craft” series.
This part is all about the process of knitting as seen through the lens of a computer scientist.
While the first part was a maifesto for structural rather than procedural knitting instructions, we will now take a look at hand-knitting as computation.
First off we can observe, that hand knitting needles both have a storage and a stitch processing function. For example when knitting socks, three or more needles may be used, only two of which are operated by the bi-manual human, while the other needles only serve to hold the stitches.
While straight needles with caps store and retrieve their stitches according to the principle of LIFO (last in – first out), double pointed and circular needles additionally implement the functions of a queue or FIFO (first in – first out), effectively forming a double ended queue, also known as deque.
While the needles constitute the main memory, there is an immense amount of external memory available. Free memory usually takes the form of the yarn ball, whereas allocated memory is constituted by the finished knitwork. Once a stitch is dropped off the needle it is automatically saved to the external memory. Every stitch can be modeled by a data structure with pointers to the subordinate stitches which it holds together.
There even is an automatic garbage collection accounting for dropped stitches: once the number of superordinate stitches referencing a stitch drops to zero, the whole stitch is dropped altogether, meaning that it is replaced by the null stitch, which only contains references to is neighbors but not to any subordinate stitch. This garbage collection mechanism gives rise to typical avalanche effects, generally known as runs or ladders.
To simulate loop formation and the slip-stitch-over operation, frequently encountered in hand knitting, the stack and dequeue functions are slightly extended by simple flip or “loop through” operator. This operator exchanges two stitches at the top of the stack or the end of the queue with the side effect, that the second stitch which takes over the prime position becomes subordinate to what was previously the first stitch.
The process of knitting is strictly sequential in nature, in contrast to the process of weaving, that may be considered an essentially parallel technique of fabric construction. In this respect knitting is similar to the Von Neumann architecture, but there are substantial differences in terms of the processing units: in the kind of computation performed by hand knitting there is no single CPU. Instead each needle point constitutes a decentralized processing unit, and pairs of such units operate in intimate interaction.
The fact, that straight needles do not have access to their very own working memory, explains the need for at least two needles in straight-needle based computation. The only notable exception to this “one hand washes the other” approach are some casting-on techniques, where the human hand performs functions that may also be taken over by a needle.
Although knitting needles have otherwise random access to the main memory both free and allocated, knitting operations are in practice mostly restricted to stitches that may be retrieved via the interface of the abstract data types and can be immediately released into the external storage.
The default stitch processing operation usually requires four clock cycles:
To allow for variants of the knit stitch, such as purl, twisted knit and twisted purl, the orientation or twisting of the stitch must be part of its data structure.
To construct such stitches, we might either introduce left- and right-handed versions for elementary stitch operations such as push, depending on the side from which the needle enters the stitch.
Alternatively an isolated twist operation can be used, that only changes the orientation of the first stitch on the needle. While the first approach provides a more realistic model of the hand knitting process, the second approach may be preferred from an information processing point of view. In any case this is a matter of taste, since both systems are computationally equivalent.
So far I have introduced a lot of crazy analogies. You may consider some of them adventurous and daring, or you might even wonder why one would go as far as to break down a knitting-stitch into even smaller actions.
The reason is that once we have identified the atoms of the knitting process, we can use them as building-blocks for all kinds of hand-knitting stitches and knitting instructions.
And this is exactly what we will do in the third part of this series.