public static void primeFactor(long n){
boolean prime = true;
long n1=0;
long n2=0;
for(long i=2;(i<=(n/2))&&(prime!=false);i++)
if ((n%i)==0){
prime = false;
n1=i;
n2=n/i;
}
if ((prime==true)&&(n>BigBossPrimeOne))
BigBossPrimeOne = n;
if (prime==false){
primeFactor(n1);
primeFactor(n2);
}
}
>>5 (>>4)
Well, yeah. I can't see what the hell this is meant to do past the line noise and public static void and complete lack of whitespace in important places.
I know I could used that but I made it a point to build the all the algorithms myself however crappy they may be. I know it's not good practice. I just did it for a greater sense of satisfaction!
Thanks
Also I must be dumb....
I just realized that a "prime test" is nothing but an algorithm to test for primarily lol. Yeah I read the title but I didn't link them automatically. Guess that's why I'm autistic ;_;
>>13 I know I could used that but I made it a point to build the all the algorithms myself
That's what I meant, implement the sieve yourself. You will find some subtle things about your existing test that could have gone better. That n/2 bit is particularly telling; 2 isn't just a number, it's a prime number.
uint64 Projects::EulerProject3() {
/*
The prime factors of 13195 are 5, 7, 13 and 29.
What is the largest prime factor of the number 600851475143 ?
*/
const uint64 n = 600851475143;
uint64 primefactor = 1;
vector<uint64> f = Helper::GetFactors<uint64>(n);
for (size_t e = 0; e < f.size(); e++) {
uint64 testval = f[e];
if (Helper::IsPrime<uint64>(testval)) {
primefactor = testval;
}
}
return primefactor;
}
f.push_back(1);
T b = static_cast<T>(sqrt((sizeof(T) == 4 ? (float)(n) : (double)(n))));
for (T c = 2; c <= b; c++) {
if (n % c == 0) {
divisor.push_back(c);
T t2 = n / c;
if (c != t2)
division.push_back(t2);
}
}
for (size_t e = 0; e < divisor.size(); e++)
f.push_back(divisor.at(e));
for (size_t e = division.size(); e > 0; e--)
f.push_back(division.at(e - 1));
f.push_back(n);
return f;
}Obviously not the most optimal solution at all, but it performed fairly quick for a nonsieve algorithm.
/* Find the largest prime factor of 600851475143. */
#include <stdio.h>
int main(int argc, char* argv[])
{ unsigned long long n = 600851475143ULL;
while(n != 2 && !(n % 2)) n >>= 1;
while(n != 3 && !(n % 3)) n /= 3;
for(unsigned long long i = 5, s = 2; i * i <= n; i += 2 + (s ^= 2))
while(n != i && !(n % i)) n /= i;
printf("%llu\n", n);
return 0; }
>>21: In function ‘main’: >>21: warning: ISO C90 does not support ‘long long’ >>21:4:26: error: use of C99 long long integer constant >>21:7: warning: ISO C90 does not support ‘long long’ >>21:7: error: ‘for’ loop initial declaration used outside C99 mode >>21:9: warning: ISO C90 does not support the ‘ll’ printf length modifier >>21: At top level: >>21:3: warning: unused parameter ‘argc’ >>21:3: warning: unused parameter ‘argv’
>>30
Any times times that anyone could post would be meaningless.
That doesn't change the fact that on almost all platforms >>1's code is ridiculously slow and >>21's is the fastest in this thread.
>>31 That doesn't change the fact that on almost all platforms >>1's code is ridiculously slow and >>21's is the fastest in this thread.
Well I'm not so sure about that. You've just rejected a fine measure, so 'fastest' doesn't have much place to look for meaning left.
>>32
That is more telling, particularly in the contrast between the >>8 and >>21 versions.
>>35 >>21
People who program like this don't deserve to get real jobs programming.
Should be cleaner. Opening braces can go on a newline if you like, but they should be there. For such simple programs, using single letter variable names is fine, but normally they should be descriptive and self documenting.
#include <stdio.h>
int main() {
unsigned long long n = 600851475143ULL;
while ((n != 2) && !(n % 2)) {
n >>= 1;
}
while ((n != 3) && !(n % 3)) {
n /= 3;
}
for (unsigned long long i = 5, s = 2; (i * i) <= n; i += (2 + (s ^= 2))) {
while ((n != i) && !(n % i)) {
n /= i;
}
}
You don't deserve a real job in programming, you forgot to comment your code.
Name:
Anonymous2010-08-03 6:11
>>39
For such a simple program, there's no need to comment. And commenting every line of code with verbose statements is for amateurs.
Real EXPERT PROGRAMMERS document public APIs, keep their code well-factored and self-documenting using descriptive identifier names, and use comments primarily to provide rational for taking certain approaches or explaining why they're doing something that isn't so obvious. They don't go overboard with comments.