Would you mind to explain shortly what co-iteration is?
Usually "co-things" are "things backwards". But I can't imagine any "inversion" of iteration.
Besides maybe something akin to "generators"—where you put some computation in and get a, possibly infinite, stream of things out; in contrast to iteration, where you put a sequence of things in and get the result of applying some computation to individual things out.
But the description above doesn't sound like anything related to generators.
Also, does the "different representations" part imply that it's possible to generalized over iterating for example arrays-of-structures and structures-of-arrays? Is sparse data an inherent part of co-iteration?
There is such a thing as coiteration in the category theory sense. It's related to the data/codata and recursion/corecursion distinction. To take a couple examples from the `free` package [1] for Haskell:
iter :: Functor f => (f a -> a) -> Free f a -> a
coiter :: Functor f => (a -> f a) -> a -> Cofree f a
Like (formal) recursion, `iter` depends on having a base case to work upward from. Like corecursion, `coiter` generates steps from the top down (towards a base that may never come).
As is often the case, terminology is overloaded and multiple overloads are attested in the real world.
Co- comes from Latin and is short for "together, with, joint, common". Think co-operation: working together. If you really want to remember the difference, think of co-itus. Itus comes from ire (to go), and the expression doesn't mean "going backwards".
> Would you mind to explain shortly what co-iteration is?
it's funny how allergic hn is to reading. it's literally completely/succinctly/adequately illustrated in the Figure 1; you have a sparse array that's represented using csr format (compressed sparse row) and another that's represented using what they call "sparse band" format (basically just the start and stop of a contiguous run of nonzero values) and you want to take the dot product between them. so you iterate through both of them at the same time using one loop and you want to do this efficiently. that's the "co-ness" of it - stepping through both using one loop efficiently. that's what distinguishes it as a paradigm from just iteration - doing both at the same time better than if you just iterated over the first using conventional techniques and also iterated over the second using conventional techniques.
> Usually "co-things" are "things backwards". But I can't imagine any "inversion" of iteration.
this has nothing to do with categories or cocategories or monads or whatever - this is about expressive representations and codegen of efficient code.
all this and more available for the low low price of "just reading the paper" instead of guessing.
But frankly one does not always have time for a paper.
A quick online search didn't yield any useful results so I've asked here.
Given the answers the topic seems confusing anyway. There are at least two quite different interpretations of "co" here in play. So I think I didn't ask anything obvious, and the answers are likely also of interest to other people who didn't had time to read the paper.
Thanks for the summary. Now I don't need to read the paper, as your summary is clear and concise, while jumping to figure 1 and trying to understand that without reading the 2.5 pages before it was not possible for me.
So just loose the snark and keep working for free for us!
I associate co-things with things that happen in parallel (e.g. collaboration) and it feels like that's closer to the intended meaning based on a cursory read of the abstract (i.e. it looks like the focus is on iterating on two data structures at the same time when they have different structural properties?).
Usually "co-things" are "things backwards". But I can't imagine any "inversion" of iteration.
Besides maybe something akin to "generators"—where you put some computation in and get a, possibly infinite, stream of things out; in contrast to iteration, where you put a sequence of things in and get the result of applying some computation to individual things out.
But the description above doesn't sound like anything related to generators.
Also, does the "different representations" part imply that it's possible to generalized over iterating for example arrays-of-structures and structures-of-arrays? Is sparse data an inherent part of co-iteration?