How would lazy lists allow that?
You would still have to sort the whole array before you can perform the slice, because the last value in the array could be the highest.
Examine what is said, not who speaks.
Silence betokens consent.
Love the truth but pardon error.
| [reply] |

lazy sort
-- All code is 100% tested and functional unless otherwise noted.
| [reply] |

Oh! A bubble sort. That's essentially what I did in my first attempt 427046, but it didn't fair very well. It would reasonable for very small N, but it very rapidly gets overtaken.
And you'll notice, it still has to process the whole list on the first pass, so lazy *lists* don't really come into play.
Examine what is said, not who speaks.
Silence betokens consent.
Love the truth but pardon error.
| [reply] |

I don't understand. If you were to extract the largest element of the list, you'd make one pass and find it, even if the largest element is at the end. No need to sort the entire array here.
The same with finding the topN. Instead of keeping track of the largest element so far, you keep track of the largest N elements so far. If you do it in a heap, you can add an element, or remove the smallest element in O(log N) time. Still need one pass through the array. Don't have to sort the array. Note that if N equals the size of the list, you perform a sort in O(N log N) time. Which is optimal.
| [reply] |

If you read the rest of the thread, you'll see that I (a) know that; (b) implemented that.
In this subthread, the discussion (started by another monk) centers around using a lazy sort/lazy lists in P6 to produce the subset--which I was countering.
But read the whole (sub)thread if your really interested.
Examine what is said, not who speaks.
Silence betokens consent.
Love the truth but pardon error.
| [reply] |