4 kyu
Counting diamonds
86 of 94drchangliu
Loading description...
Algorithms
Puzzles
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.
Python: The sorting requirement in the description and in the tests don't match.
As described, the example output gets the second and third rectangles wrong (the second has a width of 2, the third a width of 1; the latter should come first as it shares a top left corner with the second but has a smaller width)
The tests expect the output to simply be sorted lexicographically, i.e. without any special key function at all. This matches the output described above.
The description should have this requirement removed for Python (don't know about Haskell tests).
Very nice and creative Kata. Thanks!
Very nice and creative Kata. Thanks!
Haskell translation
[]
solutions... I think that's a bug in the python tests, not sure how it should be resolved.[[(Int, Int)]]
to((Int, Int), (Int, Int))
. this is not in any way imposed by the language, that just seems like the better fit. using(Int, Int, Int, Int)
is the third option, and I slightly prefer that but opted for consistency with description/python there.Happy to change things, don't hold back. I might push back some but ultimately I am looking to match your intentions.
Oh uhm okay. No changes to be made? I suppose I'm resolving this myself ;_;
I think the thing about python tests skipping and this one retrying really does need changing in both of them. The python one for example risks skipping 50x50, while this one risks spending time retrying. I have no idea what the chances are to get an empty solution, the logic of it doesn't seem good though. Maybe fall back to picking a random area and using that sum? Or maybe pick a random area to obtain the sum instead of picking a random sum?
No big deal perhaps, but also noticed now that initial solution here should possibly have different default parameter names (chart -> diamondMap, target -> numOfDiamonds) This happened because the python reference solution uses
map
as a parameter name so I changed that tochart
without thinking much about it and then that ended up in the initial code. :PSounds reasonable to me. I'm very familiar with Haskell, though. Thanks for taking care of this.
how many tests are there in total? Will help in terms of understanding how far off we are from completing before the timeout
There are 50 mix-sized tests and 10 fixed-sized tests. This won't help you understand timeouts, though, because the majority of time is spent on the last couple of large tests of size 50x50.
maybe you should explain in the description how the large tests are organized. With the current explanation, there could be 4x 50x50 or even 100 of them, the user cannot know. While in fact that's neither of those situation.
Done. Added that info.
the sample tests aren't using the new test framework
note: format the inputs using something like this, to ease the debuging for the user:
python ...[ [4, 5, 0, 2], [10,1, 2, 0], [1, 0, 2, 1], [0, 0, 1, 0]], ...
Formatting in sample tests, right?
Yes.
This is to avoid approval:
For example: This solution fails for the following(and several other inputs)
These are reasonable requests. I have made changes so that (1) there are now 50 (instead of 5) fixed size tests. I ran the solution you pointed out four times and it didn't pass. It failed as many as 9 test cases. (2) I fixed the size of the random-sized tests so that the run-time will be more consistent. Now my own solution takes about 5-6 seconds instead of 2-3 seconds. I think we just pushed some boardline solutions to time out, but execution time is consistent. For a 4 kyu, I wish to be more friendly to different types of solutions. That's why I left a 4x room for less efficient solutions. Perhaps this should be a 3kyu one now. I'm fine either way. What do you think? Thanks.
I think 4 kyu is fine, I'll approve this in a while.
In python coordinates should be tuples, not lists.
I hesitate to make changes that will break previous solutions. Why should coordinates be tuples instead of lists? Please explain the justification for this. Thanks.
with a custom assertion function, you can convert the output of the user to the new output format. This way, it's transparent for new users.
reason: because that's the usual way in python, that's all (and typing
[]
is more annoying than()
, and tuples are lighter in memory, and they are immutable which has its advantages too)I went through this suggestion before approving, but I considered that the tuples are not involved in the core of the algorithm, so there would be little to no performance gain(and in case if there's any it would be for everyone), and what remains to be sacrified is just little bit of syntactic sugar.
Thanks for approving this. It sounds like all of you agree that tuples are better in this case. I will go it and attempt to make the change.
(incase, you don't want invalidate solutions, it can actually be done without that, by a type-check and converting the already pubished solution's result to tuples)
Just made the change. Thank you both again, XRFXLP and Blind4Basics. You guys are available all the time. I appreciate your help. Do you work for CodeWars? Just curious.
nope, neither of us. Free time only x) (but I'm in the moderation team, yes)
Even more appreciation from me since you are doing this as a service. What does it take to get in the moderation team? Somewhere I saw that people with 3000+ points can approve Kata. I don't think that's true.
It's almost true (actual limit is 4000). But it has nothing to do with the moderation team, only with "power users" privileges
The moderation team is fairly new (just 2 months or so) so, for now, only users long known from kazk (current cw's maintainer) are in the team. It's sort of "on invitation" because currently, there is no other way.
Things have been evolving on every aspects of CW, lately (even if not that visible for regular users), so there are a lot fo things that are temporary / not decided yet / will evolve in a more or less near future.
That's good to know. Thanks for sharing.
The coordinate pairs are still lists, and
((a, b), (c, d))
is not accepted. It is REALLY weird that coordinates are tuple but this pair is not.I think
(a, b, c, d)
makes even better sense seeing as this is one value,(a, b)
is not used anywhere else and therefore doesn't need to be its own separate thing. That's obviously breaking it too much though.I think the memory remark is odd, I'm fairly sure it has more to do with convention and communication, influence from other languages that are statically typed. A list is many of the same thing, while a tuple contains a mix of things with different meaning. A collection with the specific size 35 might make sense as a list even though it's fixed size, if it's considered many of the same thing, but a 3d coordinate does not make sense as a list as each one has different meaning. Here it's top left and bottom right corner, each to be interpreted differently.
Excecution time is very variable -> random timeouts.
Size of random tests should be more uniform between executions.
They do vary a bit, but I've run my own solution several times and it hasn't timed out on me. The time I remembered was a little above 2000ms. So it can be 5 times more before it times out. Hopefully it leaves enough room to accommodate other types of algorithms. I agree with you that random timeouts are bad. I will think about any subtle changes I can made to the test code to prevent that. I do want random tests to remain mostly random, though. Thanks.
My (slower) solution varies from 6 seconds to timeout. Other solutions have a 3x range.
Thanks for letting me know the numbers.
Order of parcels in result list is not specified.
I updated the problem description with the expected order of parcels. Thanks for the suggestion.
Sort order is very confusingly worded to my eye, pretty sure it's ambiguous, probably ambiguous in more than one way (what is column and what is row (xy vs yx), and since it's not points then should it sort by top left corner and if so then what about two shapes both starting in that location ... and so on). Only way I could figure it out that it was the same sort order as the coordinate structure itself was through the tests. Which is fine in itself but there's an attempt in the description at describing it and it doesn't do much to describe it.Alright so it did say which coordinate is row/col. @XRFXLP edited to add tie breaking information about what to do when the top lef corner is shared.
map
is a built-in function in python. It's better to use another name for the first parameter.Changed accordingly. Thanks for the suggestion.
Returning inconsistent datatypes is not a best practice. Consider asking for a list, possibly of length 0 or 1, of all possible solutions.
Currently, the return type is consistent. It asked for a list of all possible answers. It may feel a little weird when only one answer is available. It will look like [[[x1, y1], [x2, y2]]]. When there are more than one answer, it looks normal. When there is no answer, which does not happen at this level, it looks normal, too, as [].
That looked to me like the answer should be a
[[Int]]
in case of one answer, not a[[[Int]]]
. It may just be an unfortunate wording of the examples.Note I haven't solved the kata ( I don't speak Python ).
That was describing the content of the answer, not the format. But you are right. I will add a sentence after that describing the format. Thanks.
Something is off with this sentence:
[[0,0], [0,0]]
(a single area with 4 diamonds) not valid?Because 4 != 3
That's a good observation. I was thinking about making it more challenging, but the current code requires an exact number of diamonds. I will change the wording. Thanks.
"parcel" is confusingly used for both land and diamonds.
"exactly" that number seems to be missing here, and "minimum" is incorrect, because it implies any greater number is also acceptable and that seems not to be the case.
The spacing of the map is incorrect in my webbrowser ( this may be my webbrowser's problem ).
Good suggestion. I've made changes to the wording accordingly. Thanks.
Thanks for a nice little kata.
Here are few suggestion:
3️⃣
kind of characters because they're hard to read.(Background is whitish-blue and text is white)[upper_left_corner_coordinates, lower_right_corner_coordinates]
), please add that in the description.(1) It actually looks pretty good on Windows. Are you on Mac? I've noticed that it doesn't look as good on Mac. I wonder why. (2) Good point. I just added that. (3) I agree. I just added an explanation.
Thanks for the suggestions. Happy new year.
AFAIK, OS has nothing to do with this(I might be wrong because I've never used windows)
I'm on Linux mint 20, and here's how I see it:

(No big deal, it might be the case that problem is very specific to me)
That is indeed bad. Mine look like this. I wonder what I can do to make it better for Linux/Mac and retain the look for Windows.
Oh, I see this is specific to me.
Leave it.
That's not how it looks at all. Using Google Chrome on a plain Windows 7 I see this:
There are many thing font rendering can depend on:
So without using web fonts and custom styles there's no way to be sure.
@drchangliu :
You can use images(maybe those screenshots?) to resolve this issue.
If Combining Enclosing Keycap doesn't get combined:
Rendered in Firefox 52 on Windows XP:
Thanks for all the good ideas and information. I just updated the kata with a few images. Unforunately, now the kata description is dependent on imgur being up and running, but it will look the same across all platforms. Thanks!
You can embed
data:
type image links. I couldn't tell you how to generate them, and they're pretty big, but if imgur's availability worries you ( it doesn't me :P ), you could go for that.Some info on adding images: https://docs.codewars.com/authoring/kata/adding-images/
This is helpful. Thanks.
Hi, this kata is finally ready to exit beta. Could you be so kind to approve that? Thanks.