APL solution

[Garklein]

Description

Contributing requirements

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

[rbergen]

Please:

• Squash your commits
• Fix the Dockerfile lint errors found by CI (visible under "Files changed")

[Garklein]

I hope I fixed the Dockerfile lint errors.
I squashed as much as I could, I was getting an error since I had a merge.

[rbergen]

Thank you.

Your solution indicates it uses one bit per prime candidate. Could you maybe talk me through how this is setup? I am rather unfamiliar with APL, but/and I don't see anything that looks like the "bit twiddling" that is required in many (if not most) other languages that don't use a specific bit-level container.

[Garklein]

Oops, this was a bit array in an earlier version, but I changed some operators and it was actually using an 8-bit signed integer array. I'll fix that. Anyways, with some operators, if it is creating an array of just 0s and 1s it will convert it to a bit array (this is also implementation specific). You can then use all the normal array operations on the array and as long as it only has 0s and 1s it will stay a bit array.

[Garklein]

Never mind, I logged the array type and it is all a bit array.

[rbergen]

Would it be possible to keep your fork available for some time? When I have the time, I'd like to see if I can get your solution to work with a free software version of APL. If I can get that to work, I'll open a PR on your fork so you can see if you're happy with what I've put together.

What's behind this is that I really would like to add APL to the language collection.

[Garklein]

Yep, I'll just leave it as it is.
When using another version of APL, you'll have to change the timings. Also, I don't believe GNU APL supports classes. You will also probably have to change the main file (it probably has a different way to load other files).

[dzaima]

Note that GNU APL is ~10-100x slower than Dyalog APL, which makes it much less suited for a performance competition. I don't think there are any free APL implementations that really focus on speed.

[rbergen]

@dzaima I understand that. Unfortunately, that doesn't change what we can and cannot responsibly add to this project.

In any case, looking at @Garklein's last comment, it very much looks like getting their APL submission to work on GNU APL requires way more knowledge of (GNU's) APL (implementation) than I could ever dream of having. I sadly think that means that APL will not be part of the collection of languages until someone else submits an APL solution based on GNU APL, if and when that happens.

[rbergen]

@Garklein As discussed in the context of #722, it is now possible to add this solution, provided that the automated build/benchmark is disabled for it. This is described in the relevant section of the contributing guidelines and concerns a CI/benchmark capability that we added after you closed this PR.

You can reopen your PR and add the build-no flag file if you would still like your solution to be added to the project.

[Garklein]

Thanks for the heads up, but since Arcfide's solution is so much better, I won't open my PR.

[rbergen]

That's entirely your prerogative, of course. Thanks for letting us know!