4 kyu
ASCII art codec
Loading description...
ASCII Art
Image Processing
Recursion
Performance
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.
Preventing a near possible approval until the suggestion below is sorted out.
.
Both functions could be made linear in number of characters of the initial string (actually linearithmic, I believe. I'm specifically thinking about the encoding function, but I also see suboptimal decoding implementation in the current solutions). Are you sure you don't want to inforce that? Because this would make a nice 4kyu, imo.
I like it the way it is to be honest.
I could increase the size of the images in the random tests up to, say, 1000 x 1000 to disallow very slow solutions, but I don't really want to rewrite my own implementation, even if I had an idea how to optimise it ;)
You could use mine? (the fork / I even can write the perf tests, if you want... x) )
Frankly, the current suggested ranking is somewhat of a boomer (I've not been around for some time, and I see the beta process isn't going any better, considering the rank creep). With the additional requirement, I'd have no problem approving it in the blue level anyway.
current rank creep is really sickening imo
Ok. I will look into it a little more deeply. And I'll take you up on your offer.
It's gonna need a "performance" tag now, right?
tag: yes, and a note in the description saying that anything equal or worse than
O(N²)with N the number of chars in the input won't work.Tell me when you want me to sneak myself in the process. The general idea about the tests, if you want to give it a shot, is the following:
testing long linear input of alternatig characters will make the recursive string concatenation explode:
.x.x.x.x.x.x[...].x\n(doable with longer subsequeneces, to "add some variety" x) )testing vertical input as well, just to avoid users avoidign the previous constraint with weird ideas:
.\n.\n.\n.\n.\n.[...]\nsome kinda sqaure inputs also, like:
Then it's about tweaking the input generation to reach big enough inputs and adding some variations so that the user cannot kinda "hardcode" some parts of the logic in the perf tests.
Note: buidling random huge maps with big homogeneous areas might not be a good idea. Or just a tiny number of them, because their generation will cost a lot
I have republished the kata with the additional tests suggested above.
I also took your
decodefunction, although I kept my originalencodeSeems to have invalidated all but one of the submitted solutions.
But that would make the requirements inconsistent: now, both fonctions do not require the same time complexity. Do you want me to try if I can differentiate both kinds of encoding solutions?
OK, in fact, the current tests setup is not good : your code barely passes the tests, in 12s. that's not the good way to enforce performances. I’ll take a shot at it in the next few days.
Yes, go for it.
fork published here
Approved
do you want me to approve it right now at 4, or do we wait a bit for new feedback? (I wonder if it's 4 or 3 in the current state...)
wait, it seems there is a problem. My previous solution shouldn't pass...
well, according to my last measurments, they both behave almost the same anywy, so... I cannot really differentiate them. So I guess 4 kyu is enough... Approving?
Yeah, do it. It's been long enough
Very minor one:
Comma-separated would mean
2,3\n..., but there is also a trailing comma2,3,\n...You formulated it better here:
Ok, description clarified.
How do I decode stuff without width and height encoded?
At the outermost level the encoded string must start with
image_width,image_height,to be valid.The dimensions of any subdivisions are not required as they can be calculated (as described in the kata description).
I see you already solved it but in case someone has the same problem, the tests are fine.
I had that problem and it was an error in parsing specifics inputs like the one above. ;)
What are the constraints on width and height for test cases?
0 <= width < 300 <= height < 30Description updated.
should be Bottom-right, unless I'm mistaken
Correct. Description updated.