-
Notifications
You must be signed in to change notification settings - Fork 18
Open
Labels
enhancementNew feature or requestNew feature or requestlibrary:collectionsstatus:pendingThis enhancement request lacks consensus on whether or not to include itThis enhancement request lacks consensus on whether or not to include it
Metadata
Metadata
Assignees
Labels
enhancementNew feature or requestNew feature or requestlibrary:collectionsstatus:pendingThis enhancement request lacks consensus on whether or not to include itThis enhancement request lacks consensus on whether or not to include it
Type
Projects
Milestone
Relationships
Development
Select code repository
Activity
NthPortal commentedon Nov 1, 2020
What do you mean by logarithmic
reduce
?Do you mean that it reduces pairs of elements, and the pairs those results and reduces them, until you have a single result? If so, that ends up being n-1 anyway. And even if I'm wrong on that, the first round is n/2, which is O(n) anyway.
I'm pretty sure you can't do better than O(n) for a reduce - it has to touch all of the elements.
soronpo commentedon Nov 2, 2020
Oh, yes you're right, I'm sorry, I was looking at it from a concurrent perspective where I build a balanced tree of operations to run later. So a regular reduce will be a left/right-side biased. A logarithmic reduce will create a balanced construction of the tree, LogN in height, so with N/2 workers at most each execution unit takes in LogN steps to complete.
NthPortal commentedon Nov 2, 2020
I think that's more of a parallel collections thing (although it might be doable just with
Stepper
?)soronpo commentedon Nov 2, 2020
There is nothing parallel in the reduce itself. The traversal just needs to be logarithmic.
NthPortal commentedon Nov 4, 2020
I guess I'm not understanding the value of a method that creates a balanced construction (which inevitably takes up more memory) for O(log(n)) steps if there's no way to parallelise it
Sciss commentedon Nov 6, 2020
you mean like a finger tree?