Bug 105900 - Is random really random? If so, couldn't it guarantee better coverage?
Summary: Is random really random? If so, couldn't it guarantee better coverage?
Status: RESOLVED DUPLICATE of bug 102238
Alias: None
Product: juk
Classification: Applications
Component: general (show other bugs)
Version: 2.1.2
Platform: unspecified Linux
: NOR wishlist
Target Milestone: ---
Assignee: Scott Wheeler
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2005-05-18 19:48 UTC by Marcin Kasperski
Modified: 2005-05-18 21:58 UTC (History)
0 users

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Marcin Kasperski 2005-05-18 19:48:49 UTC
Version:           2.1.2 (using KDE 3.3.2,  (3.1))
Compiler:          gcc version 3.3.5 (Debian 1:3.3.5-12)
OS:                Linux (i686) release 2.6.8

(it could be partially dupe of bug 56459 but I am not sure)

I use juk to play fairly large collection of songs (~5000). And I have the feeling that something is not truly/enough random here. Why? There are a few songs which I listened to for a lot of times while plenty of songs were not played ever. Maybe it is just the normal effect while utilizing random search but I would recommend taking a look whether it really covers everything (I suspect there could be something like rounding effect which eliminate some songs).

Whether there is such problem or not, juk could try to prefer songs not played to those already played (this is probably dupe of 56459 but I would like to point that this information should be preserved between juk runs).
Comment 1 Michael Pyne 2005-05-18 21:58:49 UTC
OK, I promise to add code to test the coverage of the random number generator one of these days. =D

If it's b0rken I'll find a better way to do it, right now we just use KApplication::random().

One possibility is that the list of unplayed songs (we do actually maintain such a list. ;) ) is getting out of sync with the current playlist.

*** This bug has been marked as a duplicate of 102238 ***