Beta
Increment a variable ...
Loading description...
Esoteric Languages
Algorithms
Fundamentals
View
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.
I don't think this is a spoiler because it doesn't help solve the kata.
In case anyone else needs the interpreter code for local testing:
Isn't
+++++[>++++++++<-]>+[<+++>-]<
shorter?This doesnt work for any initial value
Typo: "tour task is to generate the BF code that adds n to the cell" should probably be "YOUR task..."
Fixed.
Hi,
Your bf interpreter should report errors when the user returns bad bf code, such as
mismatched square brackets
orcontaining input/output instructions
, rather than continuing to run or just raising an error.You should combine seven assertions into one for a single test. For example:
You should make this type of solution less easy to pass.
The reference solution passes the entire 0-4095 tests in about 8.5 seconds most of the time, so why are there so few random test cases?
Thanks for reporting. Tomorrow I'll review the kata.
IMHO this is cheating, and it's hard to stop (at least in python).
Well, I know it's impossible to stop it, but you can at least make it more difficult.
Try now, should be fixed (except anticheat).
Looks much better, although there are still a few minor issues :)
Your bf interpreter still ignores input/output commands. It would be more user-friendly to report errors.
The number of random tests is still not enough IMO.
For example, even in the worst case, a solution with
70
wrong answers might take only40
attempts (1-(1-(1-70/4096)^125)^40=0.993
) to pass the random tests.So I suggest setting the random tests to
random.sample(range(4096),1600)
.This way, even a solution with
10
wrong answers will takeC(4096,1600)/C(4096-10,1600)=142.632
attempts on average to pass the random tests.You could use 16 batches of 100 random test cases or some other reasonable scheme to organize this many random tests.
About the code size limit, existing solutions are basically in the 2.5kb size range. It might be better to set it to 5kb to reduce the possible hard-coded size of future solutions.
Example of a solution having
70
wrong answers passed the random tests.Updated:
Nice work! 👍
Some typos:
sigle
,core
(should becode
I assume),forst
Fixed.
First of all, cool Kata! I'd love if it would be available for Haskell. Second of all, I think there is a typo in the description of the operations:
]: jump backward to the command after the matching ] if the current cell is non-zero
Should be
]: jump backward to the command after the matching [ if the current cell is non-zero
Fixed.
hi,
from what I grasp from the example in the description, your wording is incorrect: what the user is apparently supposed to do is to "increment the cellforget that... x)n
in the tape", no? 0 indexed?edit: this task does ring a bell... I mean, I believe we already have a kata asking for the same kind of optimizations...
This comment has been hidden.
.