7 kyu
Valid Parentheses
2,757 of 9,087Kacarott
Loading description...
Strings
Parsing
Algorithms
View
.avif)
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.
1 kyu
TypeScript translation (direct translation of current JavaScript translation)
Approved, thanks!
Kotlin translation (direct translation of my Java version)
Approved, thanks!
Stolen from Leetcode
Writing a program to verify parenthesis is one of the most classic tasks in programming, that would be like accusing a task "generate a list of prime numbers" as being stolen. Not to mention that the kata is a remake of this kata which was created in 2013, while the earliest similar task I can find on Leetcode is from 2015. Are you sure they didn't "steal" from us? ;)
Ah, okay. It was interesting to know.
Julia Fork with a couple of enhancements. The
iteratedefinition is more efficient and the implementation is cleaned up in general. Also, since the new version of FactCheck no longer shows the custom message for a positive result, I've changed things to be slightly more meaningful to the user (e.g.1 --> 1now readsPassed --> truefor a successful test set)Nothing in here that is critical. I just wanted to improve the
iteratemethod and figured I'd touch up other things while I was at it, so feel free to ignore.Thanks, approved!
Nice kata.
This comment has been hidden.
It's not a performance issue, you have an algorithmic issue. Try adding this input to the sample tests and running your solution:
"(("(which should of course returnfalse).Definitely, it should be '6 kyu' and tagged as 'algorithms'.
Usually, a solution is obvious for '7 kyu', but not here.
Usually, for '6 kyu' and for this kata specifically, you must Find a solution, I think.
'7 kyu' examples:
https://www.codewars.com/kata/5828713ed04efde70e000346 https://www.codewars.com/kata/544a54fd18b8e06d240005c0 https://www.codewars.com/kata/57ecf6efc7fe13eb070000e1
A solution being "obvious" is not a matter of the difficulty of the challenge, but of the experience of a user. The requirement of having to think before arriving at a solution is similarly dependent on the skills and experience of the solver. In other words: you are projecting. As for this kata, since the solution pretty much only involves the arcane art of "counting", the given difficulty is appropriate.
Also there is the Valid Braces kata which is perfectly ranked at 6kyu and certainly more difficult than this kata.
I've added the algorithms tag as suggested, but just for your information, the ranks of kata is almost never changed unless they are very wrong (eg. a 6kyu kata being ranked at 4kyu) and have very few solves.
Also one reason this one is 7kyu instead of 6kyu is that the tests are purposely kept small so that pretty much any algorithm will work, it doesnt need to be anything very fast.
CoffeeScript translation
Approved, thanks!
Nice Kata! Thanks Kacarott
Scala translation. Mostly created at late at night, so please review, and I'm up to fixing any issue found later on.
Thanks!
It should be <= 6 kyu for this problem
7 <= 6 -> so your statement is correct
The C# version of this Kata got the AreEqual arguments mixed:
Assert.AreEqual(Kata.ValidParentheses(str), expected, $"Incorrect answer for str = "{str}"");
"expected" should be the first argument, the result from the method should be the second argument.
If you mean sample tests, should be fixed. Please reset the trainer, reload the page, and verify.
")))(((" Should this return true of false?
This should return
false, because it's not well balanced: the first parenthesis closes something what havent been open before.thats what i thought but wanted to be sure because the example doesnt cover this case.
false
Swift translation. Thanks for reminding me how terrible indexed access to characters is in Swift.
Thanks!
C# translation
Thanks!
The arguments in
Assert.AreEqualin Sample Tests are in reverse order (line 37). Regards, suicHey I'd swear I double-checked before publication :|
Fixed here.
Issues started to pop up, so I approved.
Factor: “Should return f for valid parentheses” should read “Should return f for invalid parentheses” in tests and sample tests.
Oops. Fixed, thanks!
C++ translation.
Thanks!
COBOL translation moved.
Rejected D:
? Who rejected? I've been waiting on someone to review it
LearningWTF's ghost...? :thinking:
fork
Can't to approve the translation due to a conflict in the description. I created a fork with the correct description (although the description looks the same 🤔) and refactor the test cases a little bit.
thanks, a new COBOL star is born \o/
Good to your kata. I solved again. :)
Method name contains sometimes parentheses and sometimes parenthesis.
Fixed (sorry java solvers your solutions were invalidated. Submit again if you like :) )
Julia tanslation I tried to stick as closely as I could to the Python structure, but it's running ~6-7s due to FactChecking all 120 tests. I could drop about 4s by checking the random tests locally instead of making calls to FactCheck, but I'm not sure if that's actually necessary. Any suggestions are welcome.
ref sol, random test generation should be fast, give user more time to solve -> 7 kyu
We've taken out most of the calls to FactCheck, so it's running a lot faster (~2-3s). I've also added a faster reference solution.
Thanks!
C translation, please review carefully :)
Thanks!
Rust translation ready.
Thanks!
This comment has been hidden.
Am I supposed to implement six random generators, or can I just move an existing translation?
Depends if the existing translation was of appropriate quality. One of the reasons for the old kata retirement was that very many translations had very bad tests.
The point of the different generators is to guarantee a variety of different input cases, so for most languages I think they are necessary, but it may depend.
nice kata
Approved as 7kyu, now the new kata can receive translations and the old one retired safely ^_^
Is there any reason to keep the original kata from retiring at this point?
The only reason is availability of people with an access to the "Retire" button.
And potentially moving the translations. But these will come.