Beefy Boxes and Bandwidth Generously Provided by pair Networks
Clear questions and runnable code
get the best and fastest answer

RE: Random number

by BBQ (Deacon)
on Jul 09, 2000 at 19:42 UTC ( #21702=note: print w/replies, xml ) Need Help??

in reply to Random number

Well Moshambo, there are those that argue that you shouldn't use randomness at all! I guess it just depends on what the purpose of the randomness is. For a random quote, or image, or anything else that is a bit more trivial, I see no problem at all in generating random results for display through rand. But, if you are trying to keep track of data, or generating unique strings to insert into a database, I would never use randomness. Regardless of the language used to generate it.

Just my R$ 0.02 worth.

# Trust no1!

Replies are listed 'Best First'.
RE: RE: Random number
by PipTigger (Hermit) on Jul 10, 2000 at 02:09 UTC
    But, if you are trying to keep track of data, or generating unique strings to insert into a database, I would never use randomness. Regardless of the language used to generate it.

    Could you please elaborate as to why not and what alternatives there are? Thanks. TTFN.


    p.s. A Tale of Soul and Sword Eternally Re-told!

      As a matter of fact, I can, but I should warn you this can turn into an essay very quickly. :)

      1. Uniqueness of data
        There are two good reasons why one should never rely on randomness to keep track of data: luck and track.

        Lets take luck first, just think of the lottery. If you play games of fortune, you count on good fortune to keep you on the positive, winning, et al. When you rely on luck to generate unique strings, or cryptic information you rely on the same luck, only directed in the opposite direction.

        It would be like playing the slots in Las Vegas hoping that you never get a triple seven, or consecutive bells, or whatever it is that slots reward you with. You are counting on being rewarded with the lack of matches. If your application deals with sensitive data, luck should never be a factor to consider. After all, there's as much good luck as there is bad luck in this world (only Murphy would find an algorithm to prove that it can be worse).

        The second reason, track, is actually more obvious. Its just very hard to keep track of something if you are being random about it! It would be like counting cars, except instead of numbering them, you could (off of the top of my head) interview people on the street asking them what their favorite TV show is instead. You would come out with results like:
        South Park VW Bug
        Pinky & The Brain Porsche 911
        X-Files 72' Land Rover
        The Daily Show Cowboy Neal

        I've actually heard of people that use this sort of technique to memorize data for long periods of time, but for storing them in a database, it really doesn't seem to be very effective. (And on a side note, that isn't being random either) If you have hundreds of thousands of records, I bet you you'll start getting duplicate favorite shows, and even if you didn't, it would be hard as hell to tell what the car you had counted was in the 1st place.

      2. Track of Data
        I have (in contrast) two methods for keeping track of my data, and neither of them are the best there are, but they have been useful nonetheless. The first, and I believe most used method is by auto-incrementing an ID field. Defining it with a unique constraint in a database, and then auto-incrementing it as you add more info. This is pretty obvious, but just for the sake of it, lets say:
        1 VW Bug
        2 Porsche 911
        3 72' Land Rover
        4 Cowboy Neal

        The second method, which I use most frequently is a combination of time and process ID. The combination of both will give me unique data and two bits of information that are much more useful than the order of which they were entered into the database. Consider that the string being generated is "$^T$$". Every time we generate a new record, we have the epoch ($^T) and the current PID ($$) of when that record was created. Even if you have multiple records coming into the database, they can't be running under the same process ID, and therefor must be unique. (I have yet to see a machine that can spawn that many processes per second). And for examples sake, our table would look something like this (under my Win NT box):

        963198426-505 VW Bug
        963198679-503 Porsche 911
        963198688-505 72' Land Rover
        963198703-500 Cowboy Neal

      3. Conclusion
        If I had to sum it up, I'd just say, "Don't let fate take over your application. Fate can be good, but if there is one thing that you can count on, its that Murphy will make it bad." or as my father (a math freak) puts it, "Nothing is truly random, and there is no such thing as a perfect circle".

      # Trust no1!

        Awesome! I feel like applauding. Thank you BBQ. Most enlightening. It occurred to me that (even though highly unlikely) it might be a good idea to pad the sessionid with a couple extra digits (two should be almost too many) in case there is a collision (because the later one would just clobber the earlier and you'd never know). Thanks for a great explanation. TTFN.


        p.s. Initiate Nail Removal Immediately!

Log In?

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: note [id://21702]
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others chilling in the Monastery: (2)
As of 2022-10-06 06:32 GMT
Find Nodes?
    Voting Booth?
    My preferred way to holiday/vacation is:

    Results (26 votes). Check out past polls.