Hi Tallak, Thanks for writing.
Maybe I wasn't clear enough in my original post, but order is *not* important; what is important is that all of the unique "Chunk B" s are counted. I wanted to make sure that, if Flow.chunk were ever implemented and used, it would not behave differently from Enum.chunk/4 or Stream.chunk/4. Yes, my original code does work - I've checked it against the course's test sets and the final test. BTW: I am not looking for anyone to do my homework for me! You are right in suggesting that I use Stream.chunk instead of Enum.chunk. José suggested this as well. You are also right in noting that the same "chunk B" would appear in the next "chunk A" - it does look like duplication. And, perhaps that suggests a way of improving the performance even more. Thanks again, Peter On Mon, Nov 14, 2016 at 2:35 PM, Tallak Tveide <[email protected]> wrote: > > Hi! > > I guess I might make a stab at analyzing this. > > The code will create a list of the short sequences of length k that occur > more than `t` times inside one of the longer sequences of length `l`. The > order of these sequences is i undefined. > > What I read from Jose's reply was that the use of Flow.chunk would shuffle > the order of the computation of each chunk, which would be an issue if > order was important (as I assumed first time I read your post). > > So I must conclude perhaps that your code is working as designed? > > I won't comment on multiprocessing here. But as you are using `Flow` here, > I would assume some kind of optimization is going on, and perhaps the > initial sequence is quite long. > > I am thinking that the first `Enum.chunk(...)` might be very memory > intensive, building lots and lots of lists, that must be copied as they are > not the tail of the list. Perhaps using Stream.chunk would be a better > choice here. > > There is also some kind of duplication going on with regard to "chunk B" > as most of the chunks computed in the second iteration of "chunk A" would > be exactly the same as those for the previous iteration. And they would all > be reallocated. I guess some kind of dynamic programming (the algorithm) > could be useful in this scenario. > > > > -- > You received this message because you are subscribed to a topic in the > Google Groups "elixir-lang-core" group. > To unsubscribe from this topic, visit https://groups.google.com/d/ > topic/elixir-lang-core/Avea6YFZLRQ/unsubscribe. > To unsubscribe from this group and all its topics, send an email to > [email protected]. > To view this discussion on the web visit https://groups.google.com/d/ > msgid/elixir-lang-core/7da27c82-8078-4adf-b8ad- > 75373af08d6a%40googlegroups.com > <https://groups.google.com/d/msgid/elixir-lang-core/7da27c82-8078-4adf-b8ad-75373af08d6a%40googlegroups.com?utm_medium=email&utm_source=footer> > . > > For more options, visit https://groups.google.com/d/optout. > -- Peter C. Marks @PeterCMarks -- You received this message because you are subscribed to the Google Groups "elixir-lang-core" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/elixir-lang-core/CA%2BKdhmjR0%2B9KnmWmfAw%3DCWNtNDWoc2XRJ09jPeC8YZvbEfYf3g%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
