Re: Trouble using r/fold to optimise a reduce

Thanks a lot for taking the time out to explain this stuff in detail! Will go through your solution shortly. On Sunday, April 3, 2016 at 12:02:48 PM UTC+5:30, Francis Avila wrote: > > I had some fun with playing around with faster solutions. > https://gist.github.com/favila/0573e3f644dea252bdaae

Re: Trouble using r/fold to optimise a reduce

I had some fun with playing around with faster solutions. https://gist.github.com/favila/0573e3f644dea252bdaaed5be9d1519f The biggest speedup comes from avoiding set creation in expanded-range (i.e., the function that produces the collection of affected coordinates) and ensuring that the ops ru

Re: Trouble using r/fold to optimise a reduce

Even stranger - the parallel version seems to at least produce an output > (not sure how correct) if run for the first 50 commands instead of 300. > I forgot to mention: the reason why r/fold sometimes seems to still work is because there is only one chunk (i.e., no parallelism), so the combin

Re: Trouble using r/fold to optimise a reduce

You misunderstand how r/fold works. My understanding is that reducers preserve the order of operation, so it > should give the correct answer. This is not quite true. There are two fundamental principles behind reducers. The first is that the process of reduction, stripped of all non-essentia

Re: Trouble using r/fold to optimise a reduce

Updated code here . -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - plea

Re: Trouble using r/fold to optimise a reduce

Just verified - it works and gives the correct answer for shorter collections. No performance boost though. And fails (?) on larger collections. Not sure what's happening. The foldvec implementation is also pretty hard to understand. On Sunday, April 3, 2016 at 2:38:26 AM UTC+5:30, Francis Avil

Re: Trouble using r/fold to optimise a reduce

Even stranger - the parallel version seems to at least produce an output (not sure how correct) if run for the first 50 commands instead of 300. On Sunday, April 3, 2016 at 2:38:26 AM UTC+5:30, Francis Avila wrote: > > Your input collection to r/fold is provided by cmds-from-input which > return

Re: Trouble using r/fold to optimise a reduce

Thanks a lot, Francis! I've made the changes you suggest - replaced map with mapv and modified apply-cmd to take/return a vector instead of a set (it converts to set internally). My understanding is that reducers preserve the order of operation, so it should give the correct answer. Instead, the

Re: Trouble using r/fold to optimise a reduce

Your input collection to r/fold is provided by cmds-from-input which returns a lazy-seq (from map) which is not a parallel-foldable type. You can try mapv instead: vectors are parallel-foldable. (Note only PersistentVector and PersistentHashMap have useful coll-fold implementations: all other o

Trouble using r/fold to optimise a reduce

Hi! I'm solving the problem described here . I've got the solution , but it takes ~50 s to compute. I tried optimising it by replacing the main reduce operation with r/fold, but it doesn't s