Welcome to the Java Programming Forums

The professional, friendly Java community. 21,500 members and growing!

The Java Programming Forums are a community of Java programmers from all around the World. Our members have a wide range of skills and they all have one thing in common: A passion to learn and code Java. We invite beginner Java programmers right through to Java professionals to post here and share your knowledge. Become a part of the community, help others, expand your knowledge of Java and enjoy talking with like minded people. Registration is quick and best of all free. We look forward to meeting you.

>> REGISTER NOW TO START POSTING

# Thread: Time complexity and algorithms

1. ## Time complexity and algorithms

I have just completed a problem on project euler, as I progress slowly I have come to realise time complexity is increasingly becoming a major factor. One problem I recently completed took me two hours to run and find solution, probably because I used many loops. From looking at the advice of others, I saw that many had used some brute force algorithm to calculate solution in seconds.

Are there any resources or material relevant to Java from a beginners perspective I can use to learn more about practical brute algorithms or other techniques which will massively reduce the time complexity of my code. If anyone can it would be great if you can share their experience on learning about time complexity and algorithms.

Thank you for taking the time to read.

2. ## Re: Time complexity and algorithms

Brute force is the slowest possible way to do something (usually).
It really depends on the problem statement. Simple things like the data types you use can effect your speed if a program is working on a large enough scale.
Consider that an if statement can be an extremely powerful tool to reduce the amount of looping you do, especially when it comes to nested looping. If you reach an exit case, don't waste time exiting.
Without seeing some code you've done, I'm not sure how much advice people can give you directly.

3. I have done some Euler problems. Only 20 or so. Your problem is a common one from what I've seen.

My approach was always do it first. If it takes longer than I'd expect then I would do as much research on the the problem as I could and try to refine my logic.

I had a prime number method that would find the first 10,001 primes. It did it in 400m/s. You might say that was fast but a little bit of research and I got it down to 54m/s.

Another way specific to the actual problem your working on. Once you get the answer to the problem, you are granted access to the forum for that question. Users post their solutions and they're a good read. You will learn a lot from them. (Except where people use assembly or mathematica lol)

It certainly comes down to practice though.

Post some questions, they're fun to discuss.

Good luck with Euler.

4. ## Re: Time complexity and algorithms

Thanks guys, I'll keep plodding on.