On Tuesday, 13 July 2021 at 19:06:12 UTC, Bastiaan Veelo wrote:
>
- The output in the readme shows
Valid: false, which worries me. I didn't try your solution myself yet.
Oop. So what happened there is, I updated the README while validateResults was broken, and completely forgot to fix the README after fixing validateResults.
I can assure you it shows Valid: true now!
>
- Not sure if this was clearly stated in the rules, but he says that the sieve size must be a run time value. I hope this doesn't disqualify your solution.
oooh. It's easy to read over but it does seem to say that:
> 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.
It'll mean that the solution can't be marked as faithful: yes anymore, I'll open a PR soon to make sure that's fixed.
Or maybe I'll update the code slightly to allow both a runtime and compile-time set sieve size >:3
While the Sieve does do the computations at runtime, the sieve size is a compile-time constant, and the buffer is static (technically one could argue that it is dynamically allocated due to being in a class >:D ).
>
- Line 23
// it also allows D to write more "file-portable" code. Not sure what you mean by this. Worth noting however is that the import only happens iff the template is instantiated, which is nice.
Basically, if you use scoped imports it tends to be a lot easier to move a piece of code between different files. A lot of the time you can get away with a simple cut+paste and it can just work.
Hence, portable across files.
>
- Line 38: Did you mean to leave
(citation needed) in there?
Perhaps ;)
>
printResults can be made @safe by means of a nested @trusted wrapper (ref):
// If not called from multiple threads, this can be trusted.
static File trustedStderr() @trusted
{
return stderr;
}
It really doesn't feel right to do that. I didn't use the @trusted lambda hack for a reason.
> Out of curiosity, do you know how your solution compares with the first one performance wise, roughly?
[1] is for the first solution, and [2] is for the second one.
Because the second solution has some compile-time things going on, it's doing a fair amount less work: not needing to allocate the list of sieve sizes; validateResults not needing to do a lookup; one less level of indirection because it uses a static array; etc.
I also set some compiler flags in dub.sdl, which doesn't actually seem to change solution_1 all that much if I apply the same flags to it.
As I mentioned in the PR as well, LDC is capable of inlining ranges, so even though this code is more idiomatic, it compiles like it was written in a more traditional C style.
[1] https://pastebin.com/Q0UxibTi
[2] https://pastebin.com/tmXDwejS
Permalink
Reply
