odin-soltion-2

[arenol]

Description

Adding my own Odin implementation

Contributing requirements

• [x ] I read the contribution guidelines in CONTRIBUTING.md.
• [x] I placed my solution in the correct solution folder.
• [x] I added a README.md with the right badge(s).
• [x] I added a Dockerfile that builds and runs my solution.
• [x] I selected drag-race as the target branch.
• [x] All code herein is licensed compatible with BSD-3.

[rbergen]

@arenol Thank you for submitting this.

I see you marked the solution as faithful. As per the contributing guidelines, some required characteristics of a faithful implementation are:

• It uses a class to encapsulate the sieve, or a (closest) equivalent feature in your language if a class construct is not available. This class must contain the full state of the sieve. Each iteration should re-create a new instance of this class from scratch.
• The sieve size and corresponding prime candidate memory buffer (or language equivalent) are set/allocated dynamically at runtime. The size of the memory buffer must correspond to the size of the sieve.

Your solution:

• Does not encapsulate the sieve (memory and size) in a class or closest equivalent feature. Solution 1 uses a struct for this. Your solution would have to do the same, or something similar.
• Does not recreate the bit sieve container from scratch for every iteration. Instead, it clears the one Bit_Array it uses.
• Does not dynamically set the sieve size. The byte array size is directly determined by a compile-time constant, which effectively fixes the size of the array used for the sieve and therefore the sieve size itself. The same applies to the Bit_Array, to some extent. Solution 1 addresses this by making the sieve size a parameter of a function that then creates the sieve container.

For these reasons, your solution cannot be marked as faithful.

You can either address these points to make your submission a faithful solution, or mark your solution as unfaithful.

Out of curiosity, what makes you're unsuccessful at getting the solution_1 multithreaded implementations to work?

[arenol]

Thanks, for your response, Rutger.

I'm not a professional programmer, and thought that this would be a nice excercise for me. Hence, I'm not 100% into what the all terminology exactly means, so excuse me for getting this wrong.

I though that the declaration Sieve :: [sieveSize/2]bool would qualify for "It uses a class to encapsulate the sieve, or a (closest) equivalent feature in your language if a class construct is not available." Obviously not.

Furthermore, it took me quite some time to learn docker and figure out how to use it in this project.

However, I have now corrected my solution, so it is in line with solution_1 and I get more or less the same result. I will upload new source code shortly.

I guess part of the requirement is the calculation of q, which I now assume should be done within each iteration. Doing square roots is stupid if you can avoid it. It is better do "factor*factor <= size" than "factor <= sqrt(size)"

Interestingly, I note that Ginger Bill and Kelimion's 1-bit solution is significantly slower than their byte solution. Using the core bit_array package (that must be quite new), I got a result that was almost as good as the byte solution.

The reason why I could not compile solution_1, I assume, is that I have a newer version of the compiler that is not backward compatible. So I had to comment out those parts of their code to make it compile and run. For the same reason, I could not make my solution work from the primeimages/odin docker image, other docker iimages with odin comiler i could find.

[rbergen]

Thank you for following this up. I've gone over the code again, and it looks good to me now in terms of implementing the requirements for a faithful solution.

With regards to using "factor < sqrt(limit)" vs. "factor * factor < limit" there is no rule or requirement, so you can pick whatever you think is best. It's also allowed to calculate either factor * factor or sqrt(limit) once per sieve run.

I did see a few things in your Dockerfile that Hadolint will complain about. I will kick off CI after I post this comment, at which time Hadolint will run and add its comments to this PR's Files tab. You can also run Hadolint locally, the Hadolint section in the contributing guidelines explains how.
In any case, I'll have to ask you to address the Hadolint findings as well.

Thank you, Rutger

[rbergen]

@arenol I was wondering if you're of the intent to address the Hadolint findings I referred to in my previous comment? That would allow us to move forward towards adding your solution to the collection.

If you need help with anything, please let me know.

[rbergen]

Closing this PR due to lack of follow-up from the author.

@arenol Feel free to reopen this if and when you decide to resolve the Dockerfile review issues mentioned earlier.