The Daily WTF: Curious Perversions in Information Technology

Pim · 2011-12-01 Reply Admin

The problem is simply that nobody has ever written a good randomization routine, even though the demand for something like that is very large. So all you need to do is write something decent, and oh man, the world will lay at your doorstep!

No wait, I'll have to rephrase that so the people here will understand.

Write a decent random routine
?????
Profit!

2011-12-01 Reply Admin

Dear Database Architect,

Directive 595 part 9 is as follows.

"Random number generators give lack of predictability, more costly evolution, inhibit the use of the functions acting as a service to applications and make them an inhibitor to evolution."

As such, please remove from all production code and replace with 42.

Sincerely, Chief Architect Gerald

2011-12-01 Reply Admin

Chief Architech Gerald:
Dear Database Architect,
Directive 595 part 9 is as follows.

"Random number generators give lack of predictability, more costly evolution, inhibit the use of the functions acting as a service to applications and make them an inhibitor to evolution."

As such, please remove from all production code and replace with 42.

Sincerely, Chief Architect Gerald

CAPTCHA: minim.

Let's keep this meme to a minim.

Matt Westwood · 2011-12-01 Reply Admin

Pim:
The problem is simply that nobody has ever written a good randomization routine, even though the demand for something like that is very large. So all you need to do is write something decent, and oh man, the world will lay at your doorstep!
No wait, I'll have to rephrase that so the people here will understand.

Write a decent random routine

?????

Profit!

Building a random number generator which is genuinely random is straightforward. The BBC-B did it by analysing the output from a noisy diode. The problem is that using this technique you can never repeat a given sequence of random numbers. Another way is to store a string of bits generated by spinning a coin and entering 1 for head and 0 for tail, for example, or (as Don Knuth did for TAOCP) rolling an n-sided die. If you have a large enough table, you can output a fair approximation to randomness. Another technique would be to pregenerate a long sequence of digits of pi. These are random to a high degree of randomness testing (the details of which I'm shaky on). The trouble with all these pregenerated values is that they will sooner or later repeat themselves.

However, I can see a market for a gigantically humongous file of genuinely random numbers, generated by an appropriately random physical process. You can guarantee to get as long a string as you like (up to a number dependend upon the size of the file) of repeatably random digits by taking every pick-a-smallish-prime n'th digit after the pick-any-number-you-like m'th in the series. Memory is cheap, so the hardware is feasible - what you'll be selling is the guaranteed randomness.

Matt Westwood · 2011-12-01 Reply Admin

nag-geoff:
Chief Architech Gerald:
Dear Database Architect,
Directive 595 part 9 is as follows.

"Random number generators give lack of predictability, more costly evolution, inhibit the use of the functions acting as a service to applications and make them an inhibitor to evolution."

As such, please remove from all production code and replace with 42.

Sincerely, Chief Architect Gerald

CAPTCHA: minim.

Let's keep this meme to a minim.

Nonono, let it run.

Oh, and please show some sensitivity. I once read a TDWTF about a chief architect called Gerald. And let me assure you, it was so funny it made me piss my combats.

Maurits · 2011-12-01 Reply Admin

Matt Westwood:
However, I can see a market for a gigantically humongous file of genuinely random numbers, generated by an appropriately random physical process.

From 1955:

http://www.rand.org/pubs/monograph_reports/MR1418.html

Large sources of random digits are useful for generating one-time-pads.

frits · 2011-12-01 Reply Admin

Matt Westwood:
Pim:
The problem is simply that nobody has ever written a good randomization routine, even though the demand for something like that is very large. So all you need to do is write something decent, and oh man, the world will lay at your doorstep!
No wait, I'll have to rephrase that so the people here will understand.

Write a decent random routine

?????

Profit!

Building a random number generator which is genuinely random is straightforward. The BBC-B did it by analysing the output from a noisy diode. The problem is that using this technique you can never repeat a given sequence of random numbers. Another way is to store a string of bits generated by spinning a coin and entering 1 for head and 0 for tail, for example, or (as Don Knuth did for TAOCP) rolling an n-sided die. If you have a large enough table, you can output a fair approximation to randomness. Another technique would be to pregenerate a long sequence of digits of pi. These are random to a high degree of randomness testing (the details of which I'm shaky on). The trouble with all these pregenerated values is that they will sooner or later repeat themselves.

However, I can see a market for a gigantically humongous file of genuinely random numbers, generated by an appropriately random physical process. You can guarantee to get as long a string as you like (up to a number dependend upon the size of the file) of repeatably random digits by taking every pick-a-smallish-prime n'th digit after the pick-any-number-you-like m'th in the series. Memory is cheap, so the hardware is feasible - what you'll be selling is the guaranteed randomness.

You can also use one of these. Randomness guaranteed.

2011-12-01 Reply Admin

Pim:
The problem is simply that nobody has ever written a good randomization routine, even though the demand for something like that is very large. So all you need to do is write something decent, and oh man, the world will lay at your doorstep!
No wait, I'll have to rephrase that so the people here will understand.

Write a decent random routine

?????

Profit!

Seems to me that Alex has found a pretty good random number generator and is using it to decide whether to post a new article on thedailywtf.com on Thursday.

Captcha: abico (well-known maker of abicii, somewhat useful for calculating random numbers)

2011-12-02 Reply Admin

I overheard a guy at the lottery counter (don't look at me like that, I was just there to buy porn and booze), saying the he would never use "Quick Pick," because it's impossible for a computer to generate a TRULY random number.

I didn't engage him in conversation on it, because I wanted to believe that he built his own precisely-calibrated numbered-ping-pong-ball-shuffling-and-dispensing machine at home.

The poop of DOOM · 2011-12-02 Reply Admin

Bananas:
Pim:
The problem is simply that nobody has ever written a good randomization routine, even though the demand for something like that is very large. So all you need to do is write something decent, and oh man, the world will lay at your doorstep!
No wait, I'll have to rephrase that so the people here will understand.

Write a decent random routine

?????

Profit!

Seems to me that Alex has found a pretty good random number generator and is using it to decide whether to post a new article on thedailywtf.com on Thursday.
Captcha: abico (well-known maker of abicii, somewhat useful for calculating random numbers)

Or any other day :P It's like a random number generator which decides which days in a week to post articles on. Maybe he ran out of WTFs to post? Time to get busy making some then...

PedanticCurmudgeon · 2011-12-02 Reply Admin

The poop of DOOM:
Maybe he ran out of WTFs to post?

How can he run out of WTFs? Snoofle alone provides one front-pager per day on average.

The poop of DOOM · 2011-12-02 Reply Admin

PedanticCurmudgeon:
The poop of DOOM:
Maybe he ran out of WTFs to post?
How can he run out of WTFs? Snoofle alone provides one front-pager per day on average.

They gotta be real and in production :P

QJo · 2011-12-02 Reply Admin

frits:
Matt Westwood:
Pim:
The problem is simply that nobody has ever written a good randomization routine, even though the demand for something like that is very large. So all you need to do is write something decent, and oh man, the world will lay at your doorstep!
No wait, I'll have to rephrase that so the people here will understand.

Write a decent random routine

?????

Profit!

Building a random number generator which is genuinely random is straightforward. The BBC-B did it by analysing the output from a noisy diode. The problem is that using this technique you can never repeat a given sequence of random numbers. Another way is to store a string of bits generated by spinning a coin and entering 1 for head and 0 for tail, for example, or (as Don Knuth did for TAOCP) rolling an n-sided die. If you have a large enough table, you can output a fair approximation to randomness. Another technique would be to pregenerate a long sequence of digits of pi. These are random to a high degree of randomness testing (the details of which I'm shaky on). The trouble with all these pregenerated values is that they will sooner or later repeat themselves.

However, I can see a market for a gigantically humongous file of genuinely random numbers, generated by an appropriately random physical process. You can guarantee to get as long a string as you like (up to a number dependend upon the size of the file) of repeatably random digits by taking every pick-a-smallish-prime n'th digit after the pick-any-number-you-like m'th in the series. Memory is cheap, so the hardware is feasible - what you'll be selling is the guaranteed randomness.
You can also use one of these. Randomness guaranteed.

Hardware-based randomness is all very well, but is no good if you want to be able to repeat a run with a particular set of random numbers - unless you make the specific effort to save the numbers you generated and use those instead. All this makes for added software complexity, but these problems are not insuperable.

2011-12-02 Reply Admin

Chief Architech Bert:
Dear Database Architect,
In case you can’t tell, this is a grown-up place. The fact that you insist on using your ridiculous randomization algorithms clearly shows that you’re too young and too stupid to be using computers.

Go away and grow up.

Sincerely, Chief Architect Bert

FTFY

2011-12-02 Reply Admin

function getRandomChar(temp)
    getRandomChar = mid("A4Z7C1K6B9Y2D8F3N5G7J1MP#Q2RXTUVW4HE", (temp mod 36) + 1, 1)
end function

frits · 2011-12-02 Reply Admin

QJo:
Hardware-based randomness is all very well, but is no good if you want to be able to repeat a run with a particular set of random numbers - unless you make the specific effort to save the numbers you generated and use those instead. All this makes for added software complexity, but these problems are not insuperable.

I actually can't think of a single scenario where I'd want to repeat an exact sequence of random numbers. One argument I could see is for some type of unit or integration test. However, that would be poor test design IMO.

hatterson · 2011-12-02 Reply Admin

frits:
QJo:
Hardware-based randomness is all very well, but is no good if you want to be able to repeat a run with a particular set of random numbers - unless you make the specific effort to save the numbers you generated and use those instead. All this makes for added software complexity, but these problems are not insuperable.
I actually can't think of a single scenario where I'd want to repeat an exact sequence of random numbers. One argument I could see is for some type of unit or integration test. However, that would be poor test design IMO.

I remember a story on here a while ago about a military simulator. Random numbers were used to modify the scenario so that it wasn't identical each time (and wouldn't change in a predictable manner). However clearly there was a need to re-run scenarios either with different users or just another time to see if improvement could be made.

2011-12-02 Reply Admin

frits:
QJo:
Hardware-based randomness is all very well, but is no good if you want to be able to repeat a run with a particular set of random numbers - unless you make the specific effort to save the numbers you generated and use those instead. All this makes for added software complexity, but these problems are not insuperable.
I actually can't think of a single scenario where I'd want to repeat an exact sequence of random numbers.

I can see generating a set of random inputs, and then comparing multiple different algorithms or implementations against those inputs, or testing against those inputs under multiple different environmental conditions.

It's basically a way to eliminate variables. "Damn! It was ten times as fast that time! Did our code change make that much difference, or is there something about this particular pattern of inputs?"

Of course, we'd also want to vary the inputs while keeping other factors constant, to make sure our code behaves as expected across that dimension as well.

Matt Westwood · 2011-12-02 Reply Admin

hatterson:
frits:
QJo:
Hardware-based randomness is all very well, but is no good if you want to be able to repeat a run with a particular set of random numbers - unless you make the specific effort to save the numbers you generated and use those instead. All this makes for added software complexity, but these problems are not insuperable.
I actually can't think of a single scenario where I'd want to repeat an exact sequence of random numbers. One argument I could see is for some type of unit or integration test. However, that would be poor test design IMO.

I remember a story on here a while ago about a military simulator. Random numbers were used to modify the scenario so that it wasn't identical each time (and wouldn't change in a predictable manner). However clearly there was a need to re-run scenarios either with different users or just another time to see if improvement could be made.

Wot e sed.

Design of monte carlo simulators indeed calls for the ability to precisely repeat any particular run. Otherwise, when bugfixing, how can you compare the difference between your "before" and "after" runs?

Typically you'll want to create a library of reference runs, which is a specific set of pre-created scenarios, each one of which will need to be run after any major (or minor, not fussy) code upgrade, to make fucking damn sure that no stupid cockups have happened during the upgrade. Testing the individual modules is all well and good but you can't be sure it's all dunky hory till after you've run your test scenarios.

2011-12-04 Reply Admin

Porting an interpreter, compiler, or OS to a new platform.
The underlying language doesn't support a sufficient PRNG (e.g. Assembly or Python's underlying Mersenne Twister) and there isn't any previous code that can be easily used.
Your application requires a PRNG with a property not possessed by the native PRNG(e.g. trivial reversibility or a specific period).

2011-12-04 Reply Admin

//I will never for the life of me understand why people feel that they will get a "better" random number by calling a rand() function a rand() number of times, or some variation of that idea.

Well, I think it's just people applying what is usually a good heuristic in real-life situations.

I know i have been guilty of this one..:-)

Aka "Pick one thing you are good at and do it again and again."

no laughing matter · 2011-12-09 Reply Admin

Page 2 of this thread is not only a trainwreck, it is a work of art of a trainwreck - the benchmark of evilness programmers of webforum-software should test against.

And of course it is the ultimate wreck of hope for mankind.

2011-12-10 Reply Admin

OK, '#' instead of the digit zero. I assume there's some semi-rational reason for that.

But... 1, 2, 4 and 7 are repeated, and hence will be over represented. I, L, O, and S will never be selected. (in spite of 'S' being the "default.")

Random Char and Triply-Random Double

Leave a comment on “Random Char and Triply-Random Double”