# Lucky numbers

After the "Happy Numbers" challenge, here are "Lucky Numbers": Some positive integer numbers are lucky, because they pass the sieve of Josephus.

The 1 is lucky by definition.

The successor of 1 is 2. So, every second number gets eliminated:

1, 3, 5, 7, 9, 11, 13, 15, 17, 19, 21, ...

The next number is 3. Now, every third number gets eliminated:

1, 3, 7, 9, 13, 15, 19, 21, ...

Number 3 is lucky! It's successor is 7. Now, every seventh number gets eliminated. And so on.

Read more about it in this Wikipedia article.

# Challenge

1) Write a program or script in your language of choice, that prints the lucky numbers between 1 and n.

2) Try to make it as fast as possible for sieving lucky numbers between 1 and a million. (Perhaps it is sensible to measure the time without printing the results.)

Edit: Consider to start with odd numbers.

I found it especially interesting to make it fast. That seems to primarily depend on the used data structure. It has to meet different requirements that sometimes seemed contradictive. I am really curious, what data structures you use in your implementation.

# Verification

There are

- 23 lucky numbers below 100,
- 153 are below 1000,
- 1118 are below 10000,
- 8772 are below 100000,
- and among the first million positive integers 71918 are lucky.

The lucky numbers between 1 and 300:

```
[1, 3, 7, 9, 13, 15, 21, 25, 31, 33, 37, 43, 49, 51, 63, 67, 69, 73, 75, 79, 87, 93, 99, 105, 111, 115, 127, 129, 133, 135, 141, 151, 159, 163, 169, 171, 189, 193, 195, 201, 205, 211, 219, 223, 231, 235, 237, 241, 259, 261, 267, 273, 283, 285, 289, 297]
```

## Discussion (16)

F# solution, ~460 milliseconds runtime.

Edit: Previously 620ms when I had the procedures nicely separated. The current results are from going completely imperative. And generating new filters as needed.About as imperative as possible. But if performance and a sieve is your problem, then imperative mutations are the answer. I actually made an Elm solution first for understand-ability and then translated it into imperative F#. The Elm solution took like 40 seconds to run in the browser. Sooooo much data copying.

## Some explanation

The idea is not to copy lists, but to filter out numbers as they come in. Each round of elimination is considered a "filter". The more filters, the lower margin of error in the results. I experimentally determined (by running the code and tweaking the number) the number of filters required for accurate results up to 1 million input numbers is 6507. In other words, 6507 rounds of elimination. You can tell the required margin of error for a given size because once you reach it, increasing the filter count further will not reduce the number of results.

While JavaScript isn't the fastest language out there I got an implementation working as follows: Great challenge!

Finds luck numbers up to 1,000,000 in ~12s

Fine! This runs in about 19s on my Notebook. splice() works in place. filter() generates a copy and is an additional loop. So I thought working out of place with slice() could be better. No way. I didn't even wait for it to end. Your implementation with splice and filter is faster.

My goal is to see if I can make a

`function*`

Generator but I haven't been able to figure out a consistent pattern yet that can drip out numbers..~~Sorry about deleting my comment, I totally broke my code~~So I changed the

`.splice(j-1, 1, 0)`

to a direct array access and fixed the`j`

offset, making it 2x fasterI look forward to reading some of the solutions. A bit too beat to do it myself at the moment 😋

This problem made me more familiar with Go. Some nice things to learn, there. I wonder why my custom struct didn't speed the thing up (it didn't slow it down either, compared to Go slices). My Python was slow, I'd like to learn some Numpy.

Slow or fast..., I'm curious.

Kasey Speakman raised the bar very high very early. :-)

My holidays during the "Kölsche Karneval" in Cologne are over now, so I'll throw one of my implementations in, before the work begins again.

This is the ranking of my attempts, so far:

`deleteEveryNth`

function: 10 sThe inner loop is

`deleteEveryNth`

, which is done by monadic parsing. The combinator`<*`

in the parsing function`takeM (n-1) <* takeM 1`

means: First take n-1 elements from the input, then take 1, but return only the n-1 taken at first.The outer loop is done by

`until outOfRange deleteUnlucky`

, both functions being quite straight forward.The code, btw, is logically exactly the same as the version with linked lists, the only difference are the "V."-functions instead of the equally named list functions, especially V.length (O(1)) instead of length (O(n)) and also important, the O(1) index operator for vectors

`!`

instead of O(n)`!!`

for linked lists.I'd like to get to a C implementation nearly as fast as the Haskell- and the F#-version. I don't know why my C is slower. I'll share my attempts soon...

So I pretty much went back and inlined everything in the F# solution and updated my post. Got the time way down. It should very nearly read like especially bad C code if you want to see how it does ported to C.

Your Haskell implementation is quite impressive in performance and terseness.

Great to hear that. I'm afraid I can't fully claim credit for the performance. That seems an achievement of the author of the vector library (Roman Leshchinskiy) and the authors of the Glasgow Haskell Compiler. ;-)

You sped up your program, so I let the compiler inline

`deleteEveryNth`

unsing the compiler pragma`{-# INLINE deleteEveryNth #-}`

I had a run in 469 ms CPU time. :-D (Of course, it all depends on hardware. But I also wanted to do the next step and profit of inlining.)

I need some more time to go through your code to understand and port it to C. Great.

I added a lot of comments. Hopefully that will help with a C translation. I just noticed you are starting with odds whereas I am filtering them out at cost of extra CPU time. I'll update my version tonight to do that also.

I'm still quite in awe of the Haskell version. It is quite expressive while performing the same. I don't understand all the specific functions or operators, but I "get" it in a general sense. Whereas I had to remove any semblance of human thought to run mine faster.

Turned out starting with odds didn't change the runtime at all really. But it led me to some shorter code that accomplished the same thing.

I also made a Go implementation that does 1,000,000 in 3s

1.6 on my Laptop. I could speed this one up to 1.2 by counting every element you set to n+1. Then:

No need for the second inner loop (counting up k), then.

Nice. My best Go attempt on an array was 6.5s. I have to think about, why this is faster.

As always: happy to provide a Clojure solution:

This is just a first draft, happy to have the running code in about half an hour. I bet there's a lot of room for improvements, it calculates the first million numbers in 147 seconds.

Got it down to still very slow 100 seconds by using the

`vec`

function on the sieved result to make it a vector instead of a linked list. This way the`nth`

call inside the`recur`

statement is way faster.