7 kyu
Compare 2 digit numbers
328 of 1,686mbicc
Loading description...
Fundamentals
Mathematics
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.
Language: C++ Can someone explain why the result is 50% on the first test and not 25%? tester(13,14,"50%");
because if you do a list like [ "1" , "3" ] and do a list to [ "1" , "4" ] you will see that string "1" are in the two then that is 50% if the the 3 was 4 then the result would be 100%
The Kata Description can be changed to provide better understanding of the problem
This should at least be lvl 6 if not 5, its not that its super hard, but to me lvl 7 is supposed to be very easy, where this one needs a little bit of thinking.
maybe you "should" get more familiar with this website, before suggesting on changing its behaviour.
your right, sorry did not realize the site gets offended by suggestions lol.
No one gets offended, don't worry. :D But ranks can't be changed once a kata is approved. The reason why you consider this kata more difficult than a "normal" 7 kyu is because this is a new kata (published in 2023). Ranking problems (in terms of published date) were more generous in the past, but with the time, active members and power users started to rank problems more "serious", so now katas have lower ranks. For example, a very old 5 kyu kata would be today 7 kyu maybe. :P I suggest you to sort the problems by
older
in order to avoid harder problems for now, and tackle these harder problems in the future :)ah that makes alot more sense, thank you!
C# translation
Python translation
.
Language: C++
Test suit missing the required header
std::string
I think, It's not necessary. But I added it.
This comment has been hidden.
This comment has been hidden.
This comment has been hidden.
This comment has been hidden.
Yes, there was a flaw in fixed tests. I fixed it
As for the C translation advice from trashy_incel, I strongly disagree with some of his points. See also the discussion on Discord.
The advice:
"It is best to write a wrapper function that takes care of calling the user function and performing the assertions (+ memory management & other setup if needed), that way you can re-use it for random tests as well, and you do not need to hardcode the messages"
is actually what's NOT best to do, as was discussed on Discord. Such a wrapper function hides both the call to the user function and hides how memory is handled from the user, but is required for the user to deduct essential information while solving the kata.
Having explicit test code also allows the user to modify the test code to add extra debugging in the sample tests.
It's OK to have preloaded helper functions that allocate or convert complex types.
As for the advice on strings as return values; that's perfectly acceptable and the resulting strings can be compared with
strcmp
. Having an enum does not guard against illegal values, and might give a false sense of "security". With enums I was able to actually make this test code crash.In general I think discussing a translation is best handled on Discord, or via review comments in the Kata, not in this section of the Kata.
How so ? the wrapper does not have to be put in preloaded. and you cannot see how your function will be called in the random tests anyway. Plus the description and initial code (that you never read) should be enough.
this is an issue with your code, not the tests suite. crashing the tests does not make you pass a kata. There are thousand of ways to make a C kata crash, regardless of its setup (like writing out-of-bounds and then complaining that the tests suite is broken)
It's not idiomatic at all in C to return a fixed set of possible values as strings. They are not a value type an are not first class citizens: no operators, no well defined semantics (a string can be mutable or readonly, free-able or not, etc)
If a wrapper is part of the sample test code, then I'm fine with it. But often it is hidden away in preloaded, which boils my blood.
And no, it's not an issue with my code that returning enums can make the test crash; given that the linker (!) does not enforce types, relying on enums for any "type safety" is just silly. And returning strings is perfectly valid and have VERY well-defined semantics, strings ARE "first class citizens". For simple katas such strings can just be returned as literals.
The argument that C code can crash a kata in many ways is a poor argument; the kata's author/translator should prevent crashes from happening if the user makes trivial mistakes. It's his job to make the user experience a pleasant one. No excuses for laziness are acceptable.
That's a bit rich coming from you with the kind of C translations you authored. Returning wrong enum members (UB) because you write senseless code is not part of the normal "user experience". There are too many ways a user can mess up in C to cover them all. Case in point, you personally opened several issues because you couldnt find the UB in your code, and blamed the tests suite. The author is not to be blamed for UB in the user code, and cannot account for it.
You're changing the subject and making this personal, I would ask you to refrain from that.
With only 2 languages and 1 day of age, the kata already is inconsistent between languages. Either it should be an enum everywhere (in the languages where they are normally used, and C and C++ are similar here) or a string everywhere.
why is it inconsistent to return a string in languages where it makes sense, and an enum in languages where it makes sense ? using
"victory"
,"defeat"
,"draw"
as constants in C is very unidiomatic. It's also not big of a deal, because it usually just changes thereturn
statement, the rest of the logic being shared between languages.Going by that logic, if a JS kata uses an array of 2-elements array, the Python translation to that kata should not use an array of 2-tuples because it's inconsistent
I'm saying that C and C++ are similar in this regard. One thing that is more questionable than a string result either in C or C++ is a string result in one but not the other.
So if an existing C++ kata uses strings constants where an enum would be better, a C translator should replicate the bad design in their translation, for consistency ?
Not speaking about this particular kata, but in general: another option is to change the C++ version so it uses a potentially better design.
I think that's not issue
If returning a string was a deliberate requirement, although arguable in the first place, it should have been enforced in all languages. Approving the change to enum implies that it isn't a strict requirement, so now the C++ version looks bad.
I agree with Unnamed. Why not just return 0, 1 or 2? There is no particular challenge or interest in returning a string or an enum, and that would allow easy translation to most languages. The point is to compute a "similarity" within two two digits numbers.
several issues with the C setup:
error messages are not helpful. they should show the input, expected and actual values. Criterion assertions take an extra printf format string parameter:
It is best to write a wrapper function that takes care of calling the user function and performing the assertions (+ memory management & other setup if needed), that way you can re-use it for random tests as well, and you do not need to hardcode the messages:
you should not compare strings with
==
in C, it just compares their addresses. It works here because of implementation details that are not true in general. Use thestrcmp()
function to compare strings, but Criterion already has a macro for that :cr_assert_str_eq(actual_str, expected_str)
sample/fixed tests should be hardcoded, and not call your solution:
your solution should NOT be visible to the user ! it should be marked
static
, so that the user cannot call it; otherwise, I can cheat the tests like thisusing strings as constants is not very idiomatic in C, because they cannot be handled with operators and because they are pointers types for which you have to define an allocation scheme. If there are only 3 possible values, it is better to use an enumerated type, for example:
Thank you. You have given very good tips. This is my first kata, and I have lot's of issues on it. I will try to fix them all.
I fixed all the issues.
solver
is still not static ;-)and the
CustomTests
should be hardcoded like theSample_tests
are; it's customary on Codewars. This is the point of having fixed tests : they work as a sanity check for the reference solution, and to easily test against edge / corner casesfixed
Memory management isn't specified in C. The return type is non-
const
char *
, so a static buffer doesn't make much sense, but the sample tests don'tfree
the result, which suggests it shouldn't bemalloc
ced.I am not very familiar with memory management in C, can you help me?
fixed
Why
short
? I'd expect eitherchar
(because it's enough) orint
(because it's the default integer type), possiblyunsigned
. But I don't see any reason to useshort
.I changed short to unsigned short
unsigned
or not, whyshort
?..This comment has been hidden.
Ok, I will change tester like this. Thank you for your attention.