Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

You may have mathed over my head, but I’m not seeing how it avoids playing already-played songs when the list is expanded.

Say I have a 20 song list, and after listening to 15 I add five more. How does this approach only play the remaining 10 songs (5 that were remaining plus 5 new)?



> Say I have a 20 song list, and after listening to 15 I add five more. How does this approach only play the remaining 10 songs (5 that were remaining plus 5 new)?

It doesn't. If you add 5 more songs, then the algorithm as presented will just treat it as if you're starting a new shuffle.

If you genuinely need to keep track of all the songs you've already played and/or the songs that you have yet to play, then I'm not sure you can do much better than keeping a list of the desired play order, randomized via Fisher-Yates shuffle each time you want a new shuffled ordering -- new songs can be appended to said list and shuffled in with the as-yet-unplayed songs.


One way to do it without retaining additional state would be to generate the initial shuffle for N > current song list. If the new songs' indices come up, they get played. You skip any indices that don't correspond to a valid song when it's time to play them.

This has some obvious downsides (e.g. an empty slot that was skipped when played and filled by a later insert won't be played), but it handles both insertion and deletions without replaying songs and you only need to store a single integer.


> It doesn't. If you add 5 more songs, then the algorithm as presented will just treat it as if you're starting a new shuffle.

You probably shouldn't have quoted "detecting additions and updating the list, etc." then.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: