sometimes it runs sometimes it doesn't?

[clodi]

Hello,

before posting my code here, I'd like to make sure that my PC isn't broken or anything.. is it even possible that you run your code and it compiles fine and it runs, then you make a small adjustment (spaces,etc) to force to compiler to re-build and the program runs and then it crashes??

if so, what type of error would I be looking for?

Thanks a lot,
CLodi

[clodi]

apparently the error should be here in this function..

int Lattice::MonteCarloWinner()
{
    //INITIALISE INTERNAL MEMBERS
    vector <int> candidates;
    vector <double> frequencies;

    //BRING SUM BACK TO ZERO
    sum = 0.;

    //FIND CANDIDATE [SITE] INFO
    for( int i = 0; i < NNEIGHBOURS; i++ )
    {
        //FIND CANDIDATE [SITE]
        candidates.push_back( site[ findSiteWithAtom( 0 ) ].getNeighbour( i ) );
        //FIND CANDIDATE'S FREQUENCY
        frequencies.push_back( atom[ site[ candidates.at( i ) ].getAtomID() ].getFrequency() );
        sum += frequencies.at( i );
    }

    //THROW DICE
    double random = (double)(rand() % 10) / 10.;

    //HOW FAR ACROSS
    double x = random * sum;

    //FIND WINNER CANDIDATE [SITE]
    double c = 0.;
    int i = 0;
    while( c < x )
    {
        c += frequencies.at( i );
        i++;
    }
    return candidates.at( i );
}

[Peter87]

Make sure you are not accessing site and atom out of bounds.

[Norm Gunderson]

You might want to check what the values of i are when you are accessing frequencies on line 31 & candidates on line 34.

[clodi]

Thanks!
Yes, I did. Now the error comes up always if I call that function 10000 times, (which means that the error is linked to random generation?)
Anyway, I did the check and yes, some of the vectors accessed were shorter than expected, that's why the error. Now I get the same error, but a lot less frequently and it's got to do with range although when the program crashes, both

cout << i << "\t" << candidates.at( i ) << "\t" << frequencies.at( i ) << "\n";

are fully printed. Does that not mean that they are fine?

[clodi]

what I meant is: when the program crashes now, you can clearly see that the last vector is printed on screen fully.

BEFORE the last vector wasn't making it to 12 which is how I realised that the was a range/memory access issue and could fix to an extent

[Norm Gunderson]

Hmm. From what you've said I would agree that the cause of the crash is probably now occurring outside of your MonteCarloWinner function. If I was in your position I would revert to using a debugging tool to work our where the program is failing & why it's behaviour is not as I expected. (That's always assuming you have access to a debugging tool - the one integrated into Visual Studio is pretty good, imo).

Also, if you are seeding your random number generator (i.e. with srand(time(NULL)) or similar), I would try seeding it with a fixed (known) number (i.e. srand(0)). Then you can repeat & debug the program's behaviour exactly - i.e. you can find a seed number that makes the program crash & then re-run it with that same seed to get the same "random" numbers every time.

[clodi]

fuck, that's genius!!
find the bad seed and stick with it. Genius. thank you so much!!!!!!!