« Prev  Page 1  Page 2  Page 3  Next » 
int getRandomNumber()
{ return "moo"; } 
So some tests on this code. (converted to php)
Average length from getRandomNumberOfDigits: 37 Execution time for 1000 iterations: .3 seconds And just using rand(0, rand(0, 100)) Average length: 50 Execution time for 1000 iterations: .009 seconds On top of that I seriously doubt they actually use a 10^rand(0, 100) number, but rather trim it... Epic Fail! 
Because xkcd's isn't a formula, mine has to be better! 
This is actually way more insightful than most people might know. The Math.random() method already generates the maximum amount of entropy in its output that it can (entropy you can think of as being a measure of randomness). By distilling a sequence of random numbers into digits, you are reducing the possible outputs from billions and billions to ten. You're reducing the ideal entropy of the function (just looking purely at the output size), so necessarily the actual entropy cannot be any greater than that (think of it sorta like the laws of thermodynamics but with bits). So... in short... I REALLY hope that the comment at the top about making Math.random() more random isn't what they actually thought, because the output of this function is way less random than Math.random(). Truly, the real wtf is that they already knew about Math.random() and didn't use it. If you're doing something cryptowise you should just use one of the wellestablished crypto methods like blumblumshubb. Sorry about the super verbose comment. As a crypto programmer, I just thought I'd weigh in. Cheers!  max 
random_comment() 
Obviously the numbers will be even more random if you randomize the digit array first. For example:
... digits = { '5','9','2','1','8','4','7','3','0','6' }; 
Reminds me of this XKCD snippet:
http://xkcd.com/221/ 
Generating unique IDs, obviously :D 
lolz... going by the comments, the readers of this site dont always understand the WTFs

Wow, I can't believe no one posted that before you. Oh wait like 3 people did. 
On many systems this isn't true. Salting the RNG is a better idea, and most systems do have that function.

Maybe digits change somehow on different machines, locations, times (like air pressure in different locations) or other unknown dimensions. So it might make sense to keep the set of numbers as characters. Thanks, that one made my day! ;)

Maybe a disclaimer, "This is also extremely slow and idiotic," would make it a little better for those who use the class and just have the javadoc available.

It would have been easier to simply return the number of "The real WTF.." comments on TheDailyWTF for the day.

Those plots generated by this wonderful function remind me a bit of an old CD Walkman I had. It was an MP3 model, one of the first, and it cost me quite a bit at the time. I would have approximately 120 songs to a CD, and they were typically albums, so 10 folders of about 12 songs each. When this was the case, the shuffle feature seemed to work just fine, but I discovered something sort of weird about it later. I had a CD with about 100 tracks, but one folder only had about 5 and the other the remaining 95.
Those 5 tracks played WAY more often than they ought to, and I realized that the damn thing was randomly selecting a folder THEN randomly selecting a track. Those 5 songs then had a 50% chance of being played vs. the other 95! I'd have a 10% chance of hearing one of the first folder's songs, and a justover 0.5% chance of hearing the other 95! All I can say is... good job Sony! 
Re: Random Stupidity
20080310 15:57
•
by
Kivi
(unregistered)

tchize, this is fabulous. 
Ironically, I hope :D 
On first reading this, I thought "salt!" (Amongst several other fourletter words.)
There is a certain beauty in it, however, and for once on TDWTF it has very little to do with the code. Read the comments: /** * We all know that random number generators aren't truly random. * This class generates random numbers a bit more randomly. */ Cstyle comment, proposing a lemma that is (in practice) indefensible; followed by an indefensible conclusion. // Allow this to be instantiated in parallel in multiple threads C++style comment, ignoring the obvious distinction between "instantiated" and "used." Putting my conehead hat on, I might want to question why there's no "serialize" here. Putting my OMFGWTF hat on, I'm no longer sure that I care. 
The problem with most RNGs is that they are based on a mathematical formula.
In a truly random number generator, the probability of any number being returned is exactly the same as the probability of any other number being returned, every time it is invoked. For a pseudoRNG based on mathematical transformation of the previous value, the probability is skewed because they simply won't return the same value twice in a row. This means that given prng(N) = k, the probability that prng(N+1) = k is zero, which is against the definition of being truly random. Using atmospheric noise (hardwarebased) is probably as close as you can get to truly random, but even that doesn't necessarily create a perfectly even distribution of probability across all its possible values. It just makes it nondeterministic in terms of the state of the software using it. 
For the first time in a long time, I uttered an audible "WTF" when reading that code.
Of course, that's the whole idea here, isn't it? 
Re: Random Stupidity
20080310 17:44
•
by
Babs
(unregistered)

Oh, I dunno, wasting time and billing hours to the clods who outsourced the work to them in the first place?

a brilliant logic really  to guess the number one would need
to guess a number of times to guess a number. Too bad that logic can't replace common sense and good education, ie. one that at least includes math. 
The WTF here is that this code is actually way less random than even a poor random number generator. Consider that in any given range of numbers up to X digits long there are far more numbers of higher digits than there are of lower digits. For example, there are only 10 1digit numbers, but there are 90 2digit numbers. This algorithm, however, gives equal probability to producing numbers of any given length up to the maximum number of digits. Meaning there is an equal chance of producing a 1digit number as there is of producing a 10digit number. Which is not ideal. If this algorithm were actually used in a high security environment it would represent a severe vulnerability.

Noooo!!!! Somone leaked my RSA hash random function!!!! ahhhhhhhhhhhhhhhhhhhhhhhhhhh

"in it's entirety"? Tsk, tsk.

Well, at least that explains the rootkit thing.... Sort of. 
Super extra ultra random security algorithms of course. 
This code is not so bad. It could be improved, of course. For one, the number of decimal points should be randomized as well. One is so very predictable.
Second, it should throw random exceptions with randomized lorem ipsum error messages to throw off malicious callers. Third, the number system should be randomized, using a random alphabet and a random parse function instead of Double.parseDouble. This parse function should pretend to parse the input, but may randomly return something else entirely, like the above mentioned 999999. The caller can never be sure what's actually returned. You cannot be too paranoid after all. And now for something completely different... Melchett: Now, Field Marshal Haig has formulated a brilliant tactical plan to ensure final victory in the field Blackadder: Would this brilliant plan involve us climbing over the top of our trenches and walking, very slowly towards the enemy? Darling: How did you know that Blackadder? It's classified information Blackadder: It's the same plan we used last time, and the seventeen times before that Melchett: Eeexactly! And that is what is so brilliant about it. It will catch the watchful Hun totally off guard. Doing exactly what we've done eighteen times before will be the last thing they expect us to do this time. 
Saw this in a C++ cookbook once:
1) generate lots of random numbers (e.g. 1000) 2) put those random numbers into an array 3) when you need a random number 3.1) generate a random number in the range 0array.size 3.2) use the number in the array as your random number, scaling as necessary 3.3) generate a new random number for that place in the array Use the same singleton random number generator for all steps  takes advantage of 'random number generators get more random over time'. Discuss. 
Re: Random Stupidity
20080310 19:11
•
by
Not very random at all
(unregistered)

Jukebox in a pub played the leastplayed tracks when nobody put any money in  sort of a punishment for not enriching the jukebox company. Those were the 3 most played songs on the machine.

A secondary WTF is inefficient object/memory usage. Why isn't he passing the StringBuilder object to the private methods?!

Re: Random Stupidity
20080310 19:49
•
by
dusoft
(unregistered)

that's randomly secret.

Haha... the best part is where they go (rand * 100) * rand thereby totally ruining an equal distribution. Fools!

Way back, many years ago, a friend of mine in college was stumped on a multiple choice test. So, he pulled out his dice bag, snagged a d4, and randomly answered some questions.

Have they heard of /dev/urandom?

Well, it does do at least 2 slightly "useful" things:
(1)It doesn't actually do any real harm by discarding entropy. (2)It changes the distribution from which the random numbers are drawn, from linear to (truncated) logarithmic. 
Truly astounding!
Quadratic distribution of the number of digits??? Where do people come up with this stuff... 
Wrong. It does harm by shortening the length of the period until repetition of the pseudo random number sequence. 
Re: Random Stupidity
20080311 02:07
•
by
Bozo
(unregistered)

Shes friggin hot eh
(don't tell my gf i just said that) :] 
Re: Random Stupidity
20080311 02:07
•
by
Bozo
(unregistered)

the irish i were drunk chick i mean ;] 
Actually, it can, and this algorithm actually does it, in a extremely backwards way. What am I talking about? Well, most random number generators I've seen in various languages have a limited resolution. Just because they generate a random number with a bunch of decimals does not mean that they are able to generate every number in that interval. Sure, if you are just goint to scale it up to 1100, it's no problem, but once you try to scale it up to, say 11000 000, you'll notice that, no matter how long you run them, some results will never, ever show up. In some cases, it's even noticable in a scale of 110 000 or less. OK, I admit, I've not tried it to the point of "never ever", but close enough. In most cases, you can even see patterns where these "holes" are going to appear. For instance, in some archaic version of C, getting random X and Y coordinates and plotting them on a white screen as black pixels generated a black screen with thin white stripes going diagonally down the screen. If you need such a resolution, another algorithm is needed. One variant is the one used here, to piece it together from random digits, as that only relies on having a resolution capable of handling ten cases. Another, variant, which is faster and simpler, but not guaranteed to be perfect, is to add a bunch of random numbers and wrap if they overflow. This can be made less likely to have holes by adding gradually smaller numbers, thus using the sufficient resolution of a smaller span to plug the holes. This algorith still can't guarantee an even distribution of all results, but at least all results are likely to appear in the resulting data set if run long enough. In other words, the thought behind the code in this WTF is sound, but the implementation of it is effed up. 
Hmm.
I suppose java.security.SecureRandom wasn't random enough either. Maybe it's time to build an external USB random generator. I'm thinking something that actually throws a dice and reads the output ;) Anyone who REALLY wants random numbers would have to get one. 
The greatest WTF in this is that the code author doesn't know that attempts to create more random numbers almost always result in numbers that are less random  unless you are Knuth. Similarly, attempts by the untrained to write sort routines usually result in a bad bubble sort.

I know how to make this *really* random! Let a 2 year old (or similar, like a monkey wih darts) shuffle the array with digits! Now THAT would really achieve randomness...

I'm tired of these novice approaches to random number generation. Here's how you do it:
1) get a (pseudo)random number. 2) Multiply by the number of degrees of the angle that Venus , Hermes and Earth form at that moment. Needless to say we're talking about the angle at the Earth node of the triangle. 3) Subtract the the number of geese presently in flight in your country's air space. 4) Add the number of milliliters of gas present in Bill Gates' lower intestine. 5) Divide by the distance from your PC (front lefthand corner of case) to Neil Armstrong's footprint on the moon (toes). Distance to be measured in number of Hindenberg zeppelin lengths (precrash). 6) Add the chances of you marrying a supermodel. 7) Multiply by the number of Google hits for the word "Nazi". 8) Random number!! Amateurs... 
Re: Random Stupidity
20080311 06:31
•
by
Anonymous
(unregistered)

And don't forget to use the "random sort" algorithm:
:D 
Re: Random Stupidity
20080311 06:37
•
by
Anonymous
(unregistered)

Well... leaving out the =0 part would make the result more arbitrary (but not more random)...
Um... with a compiler that doen't warn you against missing return statements, you'll get quite arbitrary (but not random) return values from this function. 
Re: Random Stupidity
20080311 06:39
•
by
Anonymous
(unregistered)

But random =/=> uniform distribution! What do you mean "true randomness"? Guassian noise (as you would get with any physical measurement) is not "true randomness"? 
« Prev  Page 1  Page 2  Page 3  Next » 