6 ms·

> I'm guessing they just invented the word coiteration, because if I google it reads like "i don't see any bears so the bear patrol must be working" since wh

> I'm guessing they just invented the word coiteration, because if I google it reads like "i don't see any bears so the bear patrol must be working" since when i google i find plenty: https://scholar.google.com/scholar?hl=en&as_sdt=0%2C14&q=coiteration&btnG= https://scholar.google.com/scholar?hl=en&as_sdt=0%2C14&q=coi... i'm gonna do you a solid since i'm actually a researcher in this area, and spell out something that's actually described/discussed in the paper: co-iteration is about iterating over sparse representations of data that have different sparsity ratios and possibly different representations.

CyberDildonics 4y ago
What part of this needs a new language and couldn't be implemented as a C++ class with a C++ iterator?
CyberDildonics 4y ago
That's usually just called iteration
- klysm 4y ago
  No, iteration doesn’t capture the essence of the problem. Iteration is much more general. Having words for specific problems is a good thing. It gives us a handle on the concept and let’s people talk about it
  - CyberDildonics 4y ago
    That basically boils down to "nu uh". You didn't explain why iterating through something is somehow a different concept than iterating through anything else. In C++ you could define an iterator and it would just decide what the next element is for you then decide when the iteration is done. Whatever is going on underneath doesn't matter and coming up with a different term is completely unnecessary.
    - mathisfun123 4y ago
      >Whatever is going on underneath doesn't matter and coming up with a different term is completely unnecessary. my dismissive friend: 1. who do you think implements those stl iterators whose elegance you so greatly admire? we do. 2. there are no iterators in the stl that iterate over a pair of ragged/jagged collections in parallel. you can approximate with std::transform but this will only work if the collections are of the same size. again: reading is fundamental (as i learned from mr burton way back) and you can very quickly understand what the "co" is conveying if you read the first example in the paper (computing a dot product).
      - CyberDildonics 4y ago
        1. who do you think implements those stl iterators whose elegance you so greatly admire? we do. Anyone can make an iterator, what does this have to do with anything, let alone creating an entire new language for iteration? there are no iterators in the stl that iterate over a pair of ragged/jagged collections in parallel Parallel Iteration: https://en.cppreference.com/w/cpp/algorithm#Execution_policies https://en.cppreference.com/w/cpp/algorithm#Execution_polici... Sparse: https://www.boost.org/doc/libs/1_65_1/libs/numeric/ublas/doc/index.html https://www.boost.org/doc/libs/1_65_1/libs/numeric/ublas/doc... Parallel Iteration: https://www.openmp.org/ https://www.openmp.org/ None of this answers why a new language is needed and you can't just do whatever is in this language in a C++ iterator. The paper is mostly about data structures, this whole thing could be a class in C++, then you could use the entire C++ ecosystem like optimizing compilers, IDEs, other libraries, profiling, static analysis, etc. When someone invents another language, the entire programming ecosystem is wiped out and everyone has to start over.
        mathisfun123 4y ago
        >Parallel Iteration: https://en.cppreference.com/w/cpp/algorithm#Execution_polici https://en.cppreference.com/w/cpp/algorithm#Execution_polici... You're still having trouble reading so let's try socratic method: if I have a vector with 10 elements and a vector with 100 elements, which iterator from stl should I use to take their dot product? >Sparse: https://www.boost.org/doc/libs/1_65_1/libs/numeric/ublas/doc https://www.boost.org/doc/libs/1_65_1/libs/numeric/ublas/doc... Neither will just a sparse representation answer my puzzle for you. >Parallel Iteration: https://www.openmp.org/ https://www.openmp.org/ Lol now I know you're just googling for keyword matches - a parfor has absolutely nothing to do with this. Overall you seem to be very upset about some perceived cognitive burden/imposition at having to learn a few new ideas. Let me free you from that burden: you don't have to understand co-iteration. But it is possible that one day your code will be slower than someone else's that does understand co-iteration.
still_grokking 4y ago
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?
- cgio 4y ago
  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?).
- mathisfun123 4y ago
  > 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.

CyberDildonics 4y ago

What part of this needs a new language and couldn't be implemented as a C++ class with a C++ iterator?

CyberDildonics 4y ago

That's usually just called iteration

klysm 4y ago
No, iteration doesn’t capture the essence of the problem. Iteration is much more general. Having words for specific problems is a good thing. It gives us a handle on the concept and let’s people talk about it
- CyberDildonics 4y ago
  That basically boils down to "nu uh". You didn't explain why iterating through something is somehow a different concept than iterating through anything else. In C++ you could define an iterator and it would just decide what the next element is for you then decide when the iteration is done. Whatever is going on underneath doesn't matter and coming up with a different term is completely unnecessary.
  - mathisfun123 4y ago
    >Whatever is going on underneath doesn't matter and coming up with a different term is completely unnecessary. my dismissive friend: 1. who do you think implements those stl iterators whose elegance you so greatly admire? we do. 2. there are no iterators in the stl that iterate over a pair of ragged/jagged collections in parallel. you can approximate with std::transform but this will only work if the collections are of the same size. again: reading is fundamental (as i learned from mr burton way back) and you can very quickly understand what the "co" is conveying if you read the first example in the paper (computing a dot product).
    - CyberDildonics 4y ago
      1. who do you think implements those stl iterators whose elegance you so greatly admire? we do. Anyone can make an iterator, what does this have to do with anything, let alone creating an entire new language for iteration? there are no iterators in the stl that iterate over a pair of ragged/jagged collections in parallel Parallel Iteration: https://en.cppreference.com/w/cpp/algorithm#Execution_policies https://en.cppreference.com/w/cpp/algorithm#Execution_polici... Sparse: https://www.boost.org/doc/libs/1_65_1/libs/numeric/ublas/doc/index.html https://www.boost.org/doc/libs/1_65_1/libs/numeric/ublas/doc... Parallel Iteration: https://www.openmp.org/ https://www.openmp.org/ None of this answers why a new language is needed and you can't just do whatever is in this language in a C++ iterator. The paper is mostly about data structures, this whole thing could be a class in C++, then you could use the entire C++ ecosystem like optimizing compilers, IDEs, other libraries, profiling, static analysis, etc. When someone invents another language, the entire programming ecosystem is wiped out and everyone has to start over.
      - mathisfun123 4y ago
        >Parallel Iteration: https://en.cppreference.com/w/cpp/algorithm#Execution_polici https://en.cppreference.com/w/cpp/algorithm#Execution_polici... You're still having trouble reading so let's try socratic method: if I have a vector with 10 elements and a vector with 100 elements, which iterator from stl should I use to take their dot product? >Sparse: https://www.boost.org/doc/libs/1_65_1/libs/numeric/ublas/doc https://www.boost.org/doc/libs/1_65_1/libs/numeric/ublas/doc... Neither will just a sparse representation answer my puzzle for you. >Parallel Iteration: https://www.openmp.org/ https://www.openmp.org/ Lol now I know you're just googling for keyword matches - a parfor has absolutely nothing to do with this. Overall you seem to be very upset about some perceived cognitive burden/imposition at having to learn a few new ideas. Let me free you from that burden: you don't have to understand co-iteration. But it is possible that one day your code will be slower than someone else's that does understand co-iteration.

still_grokking 4y ago

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?

cgio 4y ago
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?).
mathisfun123 4y ago
> 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.