6 kyu
Texting with an old-school mobile phone
240 of 904B1ts
Loading description...
Fundamentals
Strings
Algorithms
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.
Pain... and more pain. The guy who invented this encoding should be forced to solve this kata in Brainfuck.
Your compiler gives wrong result for some tests even I get correct results. I test my code on two different compilers. Can you check it out please.
Hi there.
The C++ translation has been around for ~5 years, and successfully completed 75 times so far. There may be some issues, but none related to the compiler or giving incorrect results (to my knowledge).
Being the author of this kata, I can see your current code, so I copied it and ran it. For the message
"D=b*b-4*a*c", the expected result is"#3****#22*-22**4-*-2*-222", but your code returned"#3****#222222**4-4-22222". I can immediately see that there is an issue with this result: after typingD=("#3****"), you're correctly switching to lowercase, but then you're clicking button26 times, when only 2 are required to output letter"b".Make sure to debug your solution. On CodeWars, you can print things to console and they will show up. You can get more tips by reading this article: https://docs.codewars.com/training/troubleshooting
Let me know if you have any other questions related to this.
Can you please check it out again on the other compiler not codewars cimpiler. I think it will print correct result.
There is no "codewars compiler". It's just Clang. You can find more info about C++ runtime here: https://docs.codewars.com/languages/cpp
One of the most painful 6KYU katas I've ever came across..
... so far!
https://www.youtube.com/watch?v=bfpPArfDTGw
What's a layout for a sign '*' (for multiplying).
I'm not sure I understood your question :/ To type
*, you have to hold the button (*-). If you're asking about which buttons are on that sign, it's'-+=(shown in diagram). If you have any questions, it would be faster/easier for me to answer on Discord.the much im suffering in c++ solving the attemps is deadly
It would be really nice to update the Node.js version for this kata.
Done. I'm not sure if it's gonna auto-select the latest version from now on, or if I should disable the others.
The pattern I've seen is that they generally keep the older versions enabled.
In general, I'd like that too. My only concern is that if it selects node 8 by default, then it's not ideal :p
It seems to default to the latest, though I can't be 100% sure without starting a new account.
Should be 4 or 5 kyu
Hello, I'm trying to submit my attempt but I get errors in the tests (while all tests passed), most of the time it says that '6165...' is expected to be '6165...' (exact same strings but I guess the error must be at the end)
After retrying again until I get different results, I got '9#226#333#666#77#2#555#99 9#777110111' is expected to be '9#226#333*-#666#77#2#555#99 9#7771101'
The only difference is '-' in the middle but that makes no sense to put a '-' after a '' since it's only for numbers or is there something I don't get ?
EDIT : ok it's for '*' I'm dumb sorry
in C:
static(and can be renamed to something more reasonable e.g.solution, sincestaticmakes the name obfuscation useless)const-correctness and generates a warning. Given the function's interface, the only sensible thing to do is to return a heap-allocated string (even though the tests do not free anything), so this should be indicated by a comment, and a better return value would becalloc(1, 1)Thanks for the report. I was kind of clueless when writing the C translation at the time, as indicated by my previous comments.
I'm hoping to take a look at this in the next couple of days, but I may require some pointers from someone like yourself, because I'm still clueless when dealing with C :P
Hi again. Apologies for not fixing the issue right away. I attempted to fix the issues and I'd appreciate if you could take a look:
Fix of the 2 desribed issues: https://www.codewars.com/kumite/66965d54b52b86ee41c6cd36?sel=66965d54b52b86ee41c6cd36
Added additional
freeing of pointers: https://www.codewars.com/kumite/66965d54b52b86ee41c6cd36?sel=669663617463769d8da21a68Please let me know if this is acceptable or if I missed anything. Thanks!
This appears to be fixed.
This kata brought me old memories... :D Nice one!
This comment has been hidden.
Thanks for spotting this. The tests were there, but RNG wasn't seeded.
Should be fixed.
What a number of edge cases !
C version generates warnings.
No, it doesn't. Did you not bother to check?
C++ version generates warnings.
Fixed.
Great kata. Thank you. From this kata I found that in PHP method empty return
truefor '"0"'.Cheers! And indeed, that is strange behavior o_O (especially for someone coming from JS world)
A few little typos in the description:
Holding is re[_]presented by a number,Finish off by holding 1 as 1- and typing ! as 1111 ('1-1111' = 1!).I guess we missed a word about a white space '0' in the beginning. But since the final result in the example is correct, that could be obvious and intentional.Thanks for spotting these. I think #2 was intentional, but I readjusted to make it complete.
The real problem for this test is the cases you need to add a space. I think you need to change the level of the problem or to test the string without spaces.
That's part of the challenge. It's pretty hard for 6kyu, but I didn't set the rank =/
I solved it after hours, resolving every case
Good job! :D And my apologies for any pain caused :P
A little tough compared to some of the other 6 kyu katas but definitely one of the more fun challenges I've solved.
Glad to hear it! If it was up to me, I'd say it's 5 kyu due to the time it takes to write down key mappings and to come up with working algorithm through trial and error, etc, but the standarts keep rising on CW, so expect something like this to be the new 6 kyu ;)
you say uppercase is a toggle and yet in your tests you do not have # after an uppercase to go back to lower case.. the test for "oen two three" is also wrong as theres a space?
what's this, then?
"#44#33..."(edit: don't forget that the sample tests are just sample. That comes from the full test suite)from the description:
Seriously, read the specs again before beleiving that the tests are wrong. 99% of the time, that's the user that is wrong... ;)
note: some definitions local to cw:
Issue: problem in the kata itself (description, wrong tests, wrong internal solution...)Suggestions: well, I guess that part is clearQuestionanything else that is related to you having a problem solving a kata -> that's you, currently.cheers ;)
Thanks for the info.. sincerely, a n00b.
This comment has been hidden.
The test cases made my day. Thx. And, ahm, yeah I'm going to subscrube to PewDePie.
you can't capitalize numbers!
You're right, you can't o_O
Case switching should only be considered when next character is alphabetic (a-z)(numbers not included)Is there a mistake in my solution? Which language?
In ruby it makes you unshift for numbers.
This comment has been hidden.
You're absolutely right, there was a mistake in my code. It should be fixed now. Please try again, and thanks for notification!!
Slightly simplified the description, and added a bunch of translations in languages I have no clue about. Enjoy! :D
Added C++ and C translations.
However, due to my very limited understanding in those languages, there could be some errors. I couldn't find proper testing documentation / examples for those languages =/
Any feedback would be much appreciated :D
I suggest you should just go look up some challenges that you really understand well, and compare/study how the testing is handled in the C/C++ version compared to your familiar language
Oh I did go through like 10 C translations ( including yours :P ) that involve strings and map-like constructs to see how the pros handle these situations. I just picked some of the simplest approaches and applied them to my own kata. ( to best of my ability )
Incredibly, what I thought was gonna be my biggest hurdle - dealing with freeing pointers, etc - was almost never handled by others (and trying to free anything would just blow up the tests), so I'm just praying it's functional at least ( tho I feel like I have sinned :D )
I'm still left in dark about some inconsistencies, like having to allocate 10x more space than I should need (in my solution), or random tests returning 2 different results, using the same code and same input pointer (for when string length < 3 chars), which is why I published it to see if it's something wrong with my solution, or tests. And in the end, I might even learn something :D
It's just unfortunate how many basic things aren't documented anywhere (best practices for each language, simple random test generator, variable scoping for tests, anti-cheat measures, when to use what assertions, how each language should be written in markdown IF: block, etc.)
It is not mentioned when should I press
#to switch case if there are non-cased characters inbetween. ShouldA-zbe#1** #9999,#1**#9999,#1#** 9999or#1#**9999?that's already settled by the contract: you need to use the minimum possible amount of "press", so there is only 1 valid strategy (if you think about other possible cases too)
#2** #9999,#2#** 9999-> invalid: no spaces between different keys#2**#9999or#2#**9999-> here there is that only possible strategy that would ensure the minimum typing "in any case".Seems to me that's not an issue.
"in any case" is not an acceptable answer because it looks like the tests only accepts one answer. If the answer can be non-unique the tests need to handle that too.
let's put it that way: what should be
A-? => only one possible solution, so the contract is enough as is (but it requires some thinking to get it out)I don't see how this is "thinking". We shouldn't have to guess which answer is correct. And both of the answers above is correct according to the specs, so if you're rejecting any one of them your tests have issues (additional assumptions that are not mentioned).
I thought I mentioned it in description: "
You shouldn't switch case until there are different cases between 2 letters". This implies that you should switch only when you HAVE TO, so in your exampleA-zshould be handled as#2**#9999, there's no need to wait for anything btw (it's because you don't have to switch case to type non-alphabet characters).I mean I could try adding tests to account for the alternative approach, but imo there's only 1 proper/intended way to do it.
I'll think of a way to update description to reflect this, I'm terrible at writing descriptions as you can see :D
Let me know which way you think I should proceed and if that fixes the issue.
errr... x)
:trollface:
That clearly doesn't sound like a reasonnable approach, Voile. ;)
Updated the description and added that test case in sample tests.
Seems to be a lot of information, but if you can think of a better way to rephrase it, go ahead :P
I think I'm satisfied with it overall. Please have a look and see if that has fixed the issue. Thanks!
Then that means you have two types of incompatible specifications in the description:
I only see specs of the first type, so I assume I can choose whatever implementation I like as long as my end result obeys all the required properties. You didn't say anything about the second type, and if there are, they would fit very poorly with the rest of the specs.
Sorry, but the ball's at your court again :trollface:
Anyways, the updated description seems clear about this now, so resolved ;-)
This is approvable without any Python completions. This does not seem like a good idea.
Author, when you feel it's really ready for approval, please resolve this issue.
sounds good.
It's because I only added python translation today to bump it up a bit :D I'm fine with waiting a bit for more solves to see if there's any issues
Let me know what you think about this kata. Another idea I have is to make a harder version of this, where
*would bring up an x by y grid and using arrows to navigate and select, as well as adding 3rd input type of numbers, with goal of finding optimal path for least clicks possible (if it doesn't get too complicated) and some other minor adjustments.