## Problem 601

A place to air possible concerns or difficulties in understanding ProjectEuler problems. This forum is not meant to publish solutions. This forum is NOT meant to discuss solution methods or giving hints how a problem can be solved.
Forum rules
As your posts will be visible to the general public you
are requested to be thoughtful in not posting anything
that might explicitly give away how to solve a particular problem.

This forum is NOT meant to discuss solution methods for a problem.

In particular don't post any code fragments or results.

Don't start begging others to give partial answers to problems

Don't ask for hints how to solve a problem

Don't start a new topic for a problem if there already exists one

Don't post any spoilers
FourLegsDriveCat
Posts: 21
Joined: Tue Sep 11, 2012 9:18 pm
Location: Ukraine

### Problem 601

Hi,
It's rather suggestion, not clarification.
Problem says:
the smallest positive integer k such that n+k is not divisible by k+1
Since k starts from 1, the following examples seem unnecessary:
13 is divisible by 1
120 is divisible by 1
jaap
Posts: 553
Joined: Tue Mar 25, 2008 3:57 pm
Contact:

### Re: Problem 601

I disagree. $k$ is essentially the length of the streak, i.e. how many consecutive lines in the two examples have divisibility before the line where it is no longer divisible. Like a lucky streak, it is about how long you can keep it going before your luck runs out. The divisibility by 1 is part of that, regardless of the fact that a streak can never have length zero.
FourLegsDriveCat
Posts: 21
Joined: Tue Sep 11, 2012 9:18 pm
Location: Ukraine

### Re: Problem 601

OK, makes sense, just confusing a bit when first read.
drwhat
Posts: 42
Joined: Tue Sep 06, 2011 4:56 am

### Re: Problem 601

I was able to use an algorithm that correctly gives the answer to the examples.
To be clear, the answer should be the sum of 31 summands? Not ranging 1 to 31 for each power of 4? That is I should only be calculating:
P(1,4) + P(2,16) + P(3,64) + ...

I wrote a brute force algorithm as well, that was able to get to P(18,4^18) and all the numbers from my algorithm match the brute force one. Obviously each successive P(s,n) takes at least 4x longer to brute force so getting to 31 this way would take quite a while. I feel like I have the correct algorithm, but I must be making some silly mistake somewhere.

If so, is anyone who has solved the problem willing to let me PM a list of of those number and see where I might have gone off?