Thread: what went wrong with this code?

Hi. I wrote a code that rolls a dice 3000 times and counts number of sixes rolled then prints the amount. I noticed that no matter how many times I ran the code, I didn't get 500+ sixes. I thought it was strange, considering that there are 6 numbers and 3000 tosses. So in a "perfect" world there should be 500 counts of each numbers. I got curious and thought I should write a code that runs the main function until there are 500+ counts of sixes and prints out how many times the program ran until it reached 500 sixes. I know how to do it by writing if and else in the main function but Im currently learning about functions so I thought the best way to to it is by using functions only.

this is what I did

Code:

//
//  main.c
//  oppgave 3-6 terning
//
//  Created by Aria Nemati on 07/04/2019.
//  Copyright © 2019 Aria Nemati. All rights reserved.
//


#include <stdio.h>
#include <stdlib.h>
#include <time.h>


int terning(void);
void print(int antall);


int main(){
    
    int i;
    int x;
    int antall=0;
    int funksjon=1;
    
    printf("kaster en terning 3000 ganger!\n");
    
    srand(time(NULL));


    for (i=0; i<3000; i++){
    
            x = terning();
    
            if (x==6){
                
                antall++;
               
            }
            }
   
    print(antall);
 
    /*while (antall < 440){

            main();

            funksjon++;

            }

    printf("antall ganger programmet er kjørt: %d" , funksjon);*/
    
    return 0;
    
    }




int terning(void){
    
    int x = rand()%7;
    
    return x;
    
    }


void print(int antall){
    
    printf("antall seksere: %d\n" , antall);
    
    }

The parts i greyed out are the code I wrote that dont work. Please tell me where my thinking went wrong and how I should approach such tasks in the future. I want to improve the way I think when coding.

its supposed to be 1-6. I fixed that line by changinge to %6 +1.

Originally Posted by flp1969

The linear congruential pseudo-number generator is less random on its lower bits than the higher ones... Try this:

Code:

int x = ((rand() >> 29) % 6)+1;

Since it's signed int, rand() returns only 31 bits of randomness (assuming int is 32 bits), so you need to shift by 28, not 29.

But with 3 bits of randomness, you'll get 1 and 2 about twice as often as 3/4/5/6:

Code:

c@c:~$ cat 177334.c
#include <stdio.h>
#include <stdlib.h>


int main()
{
        for (int i = 0; i < 1000000; ++i) {
                printf("%d\n", ((rand() >> 28) % 6)+1);
        }
        return 0;
}
c@c:~$ ./177334 | sort | uniq -c | sort -n
 124476 6
 124905 3
 125251 4
 125358 5
 249919 2
 250091 1

(Random values 0-5 map to 1-6, and random values 6-7 map to 1-2.)

Originally Posted by GReaper

That depends on the implementation. The standard guaranties that RAND_MAX will be at least 32767, but that's about it. Modern PCs tend to use 31 bits, but I wouldn't rely on it. I've witnessed quite a bit of inconsistency across operating systems.

Of course, but I just wanted to show that using fewer bits from rand() can actually make the distribution of random numbers worse rather than better.

flp1969: that main problem I tried to illustrate is that using the top 3 bits of rand() to roll a 6-sided die gives a very uneven distribution. Values 1 and 2 each have a 1:4 probability, while all other values each have only a 1:8 probability.

That would give the user a 1:16 probability of getting snake eyes instead of the expected 1:36.

(It should work fine with a d2, d4, d8, d16, etc die, since those are all powers of 2.)

On the other hand, if you take only the top 3 bits, you could instead repeatedly generate a random number until it's in range:

Code:

int rolldice( void ) {
    int roll;
    do {
        roll = (unsigned)rand() >> (rand_bits - 3);
    } while (roll >= 6);
    return roll + 1;
}

(There are better ways to do this, but that shows the basic idea.)

That'll give a much more uniform distribution.