Hi,

I hope someone can help with this; I can't find anything on a search, at any rate.

I have a survey with two conditions, which I'd like participants to be randomly assigned to. I've used the {rand(1,2)} equation to make this happen. The funny thing is, my results have 10 participants in one condition and 30 in the other. Now, this isn't impossible by any means; it might be just the way the randomisation went. However, the exact ration of 1:3 make this seem fairly unlikely to me. I've checked everything that I know how to, and there doesn't seem to be anything that might cause this (like a quota or something).

Can anyone suggest what might be causing this skew in the particpant assignation?

Many thanks!
Lodore

Chance?

Just have another participant and I guarantee you, that you will have a different ratio than 1:3, it will be either 10:31 or 11:30.

What I want to say, chance is a difficult thing and sometimes we seem to expect a problem, where there is none.

I can understand your worries though, don't get me wrong. Because of course 1:3 is quite a big skew to one side. On the other hand your sample is pretty small.

Let's assume that there is a problem with the rand formula. But to prove this we would need to make some bigger test. Maybe you can have a test where you have just a text display question, showing the rand function and rand(1,2) and its result. Reload this 100 or 200 times and note down the result. Better go for bigger numbers. And then see who this turns out. It should be a lot closer to a 1:1 ration than this.

By the way, how do you recruit and how do people enter your survey?

Hmmm ... fair enough, chance isn't impossible as the cause of this. Still, I wouldn't have bet any money on the likelihood of a this result ...

I can see that the sample size is small; that's for sure. I guess perhaps I should run through it a good few times just to be on the safe side. This will be mildly tedious as it's a long survey, but it that's vastly preferable to getting no results.

I'm recruiting by using participants in a larger drugs trial: I use them in the dead time between their taking a pill and the pill taking effect. They're presented with the option to take part and click the survey link if they wish to. it's a psychology experiment rather than a survey, so the sample size needn't be bigger than 60 or so for statistical power.

Thanks for the help so far!

I thought of checking just with a survey that has only exactly 1 purpose, generating random numbers. So just create one question. You don't even need to save things in the database. If rand(1,2) gives wrong results, than it should always give wrong results. So I thought, just to make sure that rand works well, create a little test survey and run through it (1 question) 100 times. If there is still a big skew (and ideally towards the same direction), then chances are good that there is something going wrong with rand and you could file a bug report.

Which version of LS are you working with?

Lodore wrote: I've used the {rand(1,2)} equation to make this happen. The funny thing is, my results have 10 participants in one condition and 30 in the other. Can anyone suggest what might be causing this skew in the particpant assignation?

The rand() function might be just the php rand function.I haven't check the sourcecode of LimeSurvey.
If that is the case, depending on your php version, the results might be not that random.
php.net/manual/de/function.rand.php Read the comments.

You can try to use two equation questions, which mostly produce better results.
Looks a bit senseless, but try it. You can replace 2 with a different number to change the range.

setRnd : rand()
rndnumber: ((setRnd - floor(setRnd / 2) * 2) + 1)

OK, so I needed to check this.

I created a survey with 1 question, type equation, with and as endurl that automatically loads the actual survey link.

Then I sat on the sofa, watching TV and clicking the submit button.

At n=100 the ratio of 1 and 2 was 53:47
At n=200 the ratio of 1 and 2 was 103:97
At n=500 the ratio of 1 and 2 was 226:224

This looks pretty reasonable to me.

Friday evening. Sitting on the couch and clicking submit.

If you have access to Linux/OSX you can try:
Siegel www.joedog.org/siege-home/
or Apache Bench: en.wikipedia.org/wiki/ApacheBench
to let the URL called 100times .

The random number will be calculated and saved without clicking submit.
At least when the welcomepage is skipped.
Your poor fingers.

Back to topic: Distribution looks fine to me, too.

Which PHP Version? Which OS?
I am currently too lazy to look up the Limesurvey code to see how rand() is implemented.

programmers.stackexchange.com/questions/...-output-of-phps-rand
For difference between pseudorandom and true-random generators see here:
en.wikipedia.org/wiki/List_of_random_number_generators

PHP offers with mt_rand a better implementation than rand. The MT stands for Mersenne Twister, which is currently the Gold-Standard for Pseudorandom. en.wikipedia.org/wiki/Mersenne_Twister
I wouldn't use pseudorandom for lottery and other stuff which might get to a court.

Thanks to everyone for the replies here; I appreciate the effort very much--especially going to the trouble of the random number generation! To answer the questions being asked:

I'm using Limesrvey version 2.00+ and build 130802; I don't have server access so I don't know the php version (or, I don't know how to get it). I'm oscillating between my work PCs (various iterations of Windows) and my home machines (OSX 10.8+).

I don't think this is caused by an issue with the particular version of Limesurvey: the implementation I used is hosted by a major university, and if there was a bug it would have been picked up very quickly before now. So, that's why I wondered if it was something else at play that I might have inadvertently been responsible for. I've attached my survey structure file if it's any good. (Note, too, that I've used this version of Limesurvey many times before and had no randomisation issues.)

I'll defintely try using different randomisation equations if necessary, though rough parity between my conditions is fine; it needn't be en exact fifty-fifty split.

Lodore wrote: I'm using Limesrvey version 2.00+ and build 130802;
I don't think this is caused by an issue with the particular version of Limesurvey: the implementation I used is hosted by a major university, and if there was a bug it would have been picked up very quickly before now.

Why do you think a bug would be picked up by the administrator of the Limesurvey installation hosted by the major university?
I wonder, since they provide you an very old installation of Limesurvey. Take a short look at the release history to see what got fixed over time.
github.com/LimeSurvey/LimeSurvey/blob/df...cs/release_notes.txt