I tinkered with the same thing. I also made a random generator using md5 with the long seconds as the seed. In that, md5 is applied to previous result, not each, requiring a separate function, but each can be mixed in.
I assume there is nothing weird in a text sort that will affect this. I assume ignoring case (if that is done) will not affect results, but I really don't know. I don't really know the properties of any of these (digests are not made to be randomizers), but I think all have the merits mentioned and the caveats noted. Dar On Jun 4, 2013, at 11:51 AM, Geoff Canyon wrote: > At the risk of beating the decaying equus -- the previously suggested > random() solutions should be fine for all purposes --I found an alternative > that: > > 1. Is faster than sorting by random(999999999) & random(999999999) > 2. Is about as fast as sorting by random(999999999) > 3. Is (I think) less likely to have duplicate sort keys > > The drawback is that it is determinative (albeit random) for any given set > of data, unless you are willing to accept performance equivalent to sorting > by random(999999999) & random(999999999), while providing near-certainty of > a true sort (I think). > > The one-time, as fast as any solution so far, sort is: > > sort lines of myVar by md5digest(each) > > Collisions are highly unlikely in 128 bits. Even random(999999999) & > random(999999999) only provides about 60 bits, which, to be clear, is > *more* than enough, but md5 is (I think) even more certain, and faster. > However, it will always produce the same results. > > sort lines of myVar by sha1digest(each) > > Works roughly the same: 160 bits of guaranteed-no-collision-ness, but it's > a little slower, although still much faster than random(999999999) & > random(999999999). Like MD5, it will always sort the same data the same > (random) way. > > The same-ness for either solution can (I think) be fixed by this: > > put ticks() into T > sort lines of myVar by md5digest(T & each) > > or > > put ticks() into T > sort lines of myVar by sha1digest(T & each) > > That should result in random results each time, and is a little faster > (MD5) or about 1/3 slower (SHA1) than random(999999999) & random(999999999) > > If anyone has thoughts on the collision-or-not-ness of MD5 or SHA1, feel > free to comment. Otherwise, I hope I'm done now ;-) > _______________________________________________ > use-livecode mailing list > use-livecode@lists.runrev.com > Please visit this url to subscribe, unsubscribe and manage your subscription > preferences: > http://lists.runrev.com/mailman/listinfo/use-livecode _______________________________________________ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
