Change:
assert(typeof josephus(30, 3) == 'number'); ``` <del> `josephus(30,3)` should return `29`. </del> <ins> `josephus(30,3)` should return `28`. </ins> ```js <del> assert.equal(josephus(30, 3), 29); </del> <ins> assert.equal(josephus(30, 3), 28); </ins> ``` <del> `josephus(30,5)` should return `3`. </del> <ins> `josephus(30,5)` should return `2`. </ins> ```js <del> assert.equal(josephus(30, 5), 3); </del> <ins> assert.equal(josephus(30, 5), 2); </ins> ``` <del> `josephus(20,2)` should return `9`. </del> <ins> `josephus(20,2)` should return `8`. </ins> ```js <del> assert.equal(josephus(20, 2), 9); </del> <ins> assert.equal(josephus(20, 2), 8); </ins> ``` <del> `josephus(17,6)` should return `2`. </del> <ins> `josephus(17,6)` should return `1`. </ins> ```js <del> assert.equal(josephus(17, 6), 2); </del> <ins> assert.equal(josephus(17, 6), 1); </ins> ``` <del> `josephus(29,4)` should return `2`. </del> <ins> `josephus(29,4)` should return `1`. </ins> ```js <del> assert.equal(josephus(29, 4), 2); </del> <ins> assert.equal(josephus(29, 4), 1); </ins> ``` # --seed--

Discussion:
<!-- NOTE: If you're reporting a security issue, don't create a GitHub issue. Instead, email We will look into it immediately. --Affected page Your code Expected behavior The code that passes the test suite (given above) provides different output than the traditional description of the problem. I think the test suite has an 'off by one' error in initializing the starting position. Current output with solution that passes test suite: Expected output per problem description: Relevant portion of problem description: See also discussion here: Proposed Fix Change test suite to Bug reported by jsdisco on the forum.
The issue seems to originate from the original challenge at the Rosetta Code, there's optional allowance for numbering prisoners from in solution, and that's what's happening in the used solution - Sample solution for the challenge also needs small change to use for initial label, instead of . And .
I'm confused in the example given in the description, if the executioner starts at 0 and kills every 2nd prisoner then shouldn't the first prisoner that is killed be "prisoner 2" and hence the killing order becomes . I think the challenge description is the one that has to be changed here. Also if numbering started from then the above killing order is just incremented by 1 which still won't be the solution given as example.
This is how I'm seeing it.
Killing every other would be 'safe', 'kill', 'safe' , 'kill', 'safe',.... But the current solution is 'safe', 'safe', 'kill', 'safe', 'kill', 'safe',... The solution/tests definitely have an off by one
I understood it wrongly . Also yea its the tests which are off by one. Looks like a good first issue.
Hi, I have a working solution for this, although not the most efficient one. It's relatively concise but using the time complexity is quadratic. Can I make a PR?
You can always open a PR. After that, we can give feedback and suggest changes if needed.
I'm not sure why you need to make a brand new solution. You just need to modify one of the existing solutions to reduce the starting value. In my solution, for example, you just set
Hi AFAIK, there is no compelling reason to completely change the original solution. The original solution has a better time complexity.

The only benefit to my approach is that the code is less error prone, since we are not implementing a fundamental data structure from scratch, and the basic steps of the algorithm that solve the problem are easier to read, since they are not mixed with the implementation details of the underlying data structure. I have already made a PR, but can fall back to the original solution, if you see necessary.
I agree that the original solution is pretty convoluted.