Project Euler #10 Sum of Primes -

i working on project euler's project #10 in asked find sum of primes below 2,000,000. reason, cannot code work. not understanding data types use, neither int, long, or long long seems working. or advice appreciated. here code. thanks.

int main(int argc, char *argv[]) { int primes[100] = {2, 3, 5, 7}; //array of primes have been found int fillcell = 4; //cell looking fill int testnum = 8; //number being tested see if it's prime int divprime; int sum = 17; for(testnum = 8, fillcell = 4 ; testnum < 2000000 ; ++fillcell) {     std::cout << "fillcell " << fillcell << std::endl;     for( ; primes[fillcell] == 0 ; ++testnum)     {         std::cout << "testnum " << testnum << std::endl;         for(divprime = 0 ; testnum % primes[divprime] != 0 ; ++divprime)         {             std::cout << "divprime " << divprime << std::endl;             if(primes[divprime] >= sqrt(testnum))             {                 primes[fillcell] = testnum;                 sum = sum + testnum;                 std::cout << "prime found " << testnum << std::endl;                 break;             }         }     } } std::cout << "sum" << sum << std::endl; } 

don't try run before have learnt art of walking.

don't use fixed size arrays int primes[100] unless have to.

one reason requires you, programmer, determine required size front - example going nth prime page , finding out there 148933 primes below 2000000.

it requires you, programmer, add additional checks code ascertain array accesses aren't exceeding bounds of array (unless using language you, java or c#). yet reason requires add code book keeping, i.e. track how many cells of array occupied.

last not least, allocating array of 148933 integers automatic variable (i.e. on stack) result in crash because blows stack.

if use std::vector<> these headaches go away instantly, , code becomes simpler.

start simple plan , implement steps separate pieces of code. easier keep on top of things if every piece of code has simple, well-defined responsibility. things more difficult if entangle 1 big bad clump.

for example, if store primes found in vector allows @ numbers there see if well, , perhaps compare them known lists of primes (like the first 10,000 primes, or primes 1,000,000,000,000 @ primos.mat.br). can look, don't have to. if intersperse output code have @ of them. if add them sum cannot see them unless debug program , follow each , every step.

formulate plan pseudocode, can take in @ glance , understand fully. if don't have plan, or if don't understand it, result cr*p.

for each candidate n between 2 , 2000000     each known prime p sqrt(n)         if p divides n             break     if no divisor p found // must new prime         add n list of found primes 

obviously, criterion 'if no divisor p found' requires use flag, divisor_found, gets initialised false before inner loop. hence first refinement:

for each candidate n between 2 , 2000000     divisor_found := false     each known prime p sqrt(n)         if p divides n             divisor_found := true             break     if not divisor_found // must new prime         add n list of found primes 

this can implemented without further ado. enumeration of candidates can improved skipping numbers cannot possibly prime, multiples of two:

add 2 list of found primes each odd number between 3 , 2000000     ... 

this cuts workload in half, , simplest example of 'wheel'. problems this, practical skip multiples of 3 (mod 6 wheel) starting 5 , incrementing 2 , 4 in alternating fashion.

add 2 , 3 list of found primes n = 5 2000000 step 6  // 6 = 2 * 3     try n     try n + 2 

here, trial division done in try not need consider 2 or 3 potential divisors, because method of enumerating candidates excludes multiples. extension skipping multiples of 5 straightforward.

if expensive calculation sqrt(n) during each iteration of innermost loop code gets slowed down crawl. n doesn't change during lifetime of inner loop, compute value once in loop header instead of needlessly repeating computation.

be may, randomly trying different integer datatypes nowhere. if values cannot become negative - case here - unsigned should first choice. on current systems corresponds uint32_t, more enough piddling small numbers involved in euler task. can save hassle introducing suitable typedef; way need change 1 single definition should need arise:

typedef std::uint32_t num_t; typedef std::uint64_t sum_t; num_t const n = 2000000; ...  std::vector<num_t> primes; ...  (num_t n = 3; n <= n; n += 2)    ...  sum_t sum = 0; (num_t p: primes)    sum += p; 

i've added separate sum_t since ballpark estimation of sum puts beyond capacity of uint32_t.

in case should consider using sieve of eratosthenes here. simpler wheeled trial division , several orders of magnitude faster - simplest rendering should solve euler task in few milliseconds.