4 kyu
Right truncatable primes in a given base
Loading description...
Mathematics
Algorithms
This comment has been reported as {{ abuseKindText }}.
Show
This comment has been hidden. You can view it now .
This comment can not be viewed.
- |
- Reply
- Edit
- View Solution
- Expand 1 Reply Expand {{ comments?.length }} replies
- Collapse
- Spoiler
- Remove
- Remove comment & replies
- Report
{{ fetchSolutionsError }}
-
-
Your rendered github-flavored markdown will appear here.
-
Label this discussion...
-
No Label
Keep the comment unlabeled if none of the below applies.
-
Issue
Use the issue label when reporting problems with the kata.
Be sure to explain the problem clearly and include the steps to reproduce. -
Suggestion
Use the suggestion label if you have feedback on how this kata can be improved.
-
Question
Use the question label if you have questions and/or need help solving the kata.
Don't forget to mention the language you're using, and mark as having spoiler if you include your solution.
-
No Label
- Cancel
Commenting is not allowed on this discussion
You cannot view this solution
There is no solution to show
Please sign in or sign up to leave a comment.
It still says in the task description that bases above 21 won't be tested. Although for my python solution it is timing out being tested against base 35.
This comment has been hidden.
Yes, for a 4 kyu, let's push this somewhat.
Current top solutions can all handle up to around n=30, give or take and all are unoptimised.
This comment has been hidden.
Shall we redo the tests then or would you like to?
Go ahead ;)
This comment has been hidden.
Wrong solutions in base 19: 14044103, 266840927, 1830261112811, 1830261894751, 34774961186201 ---(base 19)---> 5CEA66, 5CEAEA6, 5CEAE42AE4, 5CEAEA2AEI, 5CEAE42GIE4 BUT
I've made a fork fixing this issue by using an exterenal library.
Honestly, I believe it would be better to explicitly import it in the initial solution and not mention it in the description, as that would make it easier to translate. However, as to not invalidate any solutions, I just messed with the preloaded section.
You shouldn't end up invalidating any solutions if you add the import to the setup as well as preloaded.
It'll be disgusting, yes, but we haven't been given much choice.
Okay I have approved your fork with some modifications. If this invalidates solutions then it's on me.
Only invalidated solutions were the ones which tried to use a correct prime checker and then append the wrong results as special cases.
Dear themanofthecat,
the solution of this kata seems to have an issue: for base 16, it requires number 2047 in the solution-list. My solution list ( without this number ) is rejected. But 2047 ( = 89 * 23 ) is no prime. i guess the issue is caused by an underlying issue of the fast_is_prime-function procvided by you. fast_is_prime(2047) = True
There is a similar issue for base 19: 14044103 (5CEA66) => 739163 (5CEA6) => 38903 (5CEA) => 2047 (5CE)
This is now fixed.
This comment has been hidden.
I would suggest to make the task actually return all right-truncable primes, not just heads of sequences. IMHO, it just complicates things a little bit.
This comment has been hidden.
Iterative vs recursive only matters if you want to generate prime number list in order (BFS vs. DFS).
You should add in description that order doesn't matter.
However including all prime numbers in list allows to randomize tests a little more by asking for random ranges of prime sequence for a given base.
The heads of sequences... OK.
for me, it was not clear at all from the description, which sequences to include and which to discard
either way, the suggestion won't be implemented, as it would invalidate too many results on an approved kata
This comment has been hidden.
Sorry about that haha, I meant to change that in the hidden test cases This is my first kata and there's not much in the way of instruction for this that I found, so thanks for this
Believe I've fixed the issues, thanks for correcting me