7 kyu
Trilingual democracy
83 of 2,168jcsahnwaldt
Loading description...
Fundamentals
Puzzles
Strings
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.
Translate Dart check the solution
Thanks! Approved.
I added a Crystal translation.
This comment has been hidden.
I added a Go translation.
I added a Kotlin translation.
This one is great. Simple idea but huge variety of solutions
I added a Swift translation.
This comment has been hidden.
This comment has been hidden.
This comment has been hidden.
This comment has been hidden.
Done.
Rust translation uses two-space indentation while the standard for the language (rustfmt and the codewars tab size) is four.
I prefer two spaces, but since Rust and the Codewars Rust editor appear to be rather strict about it, I changed it to four spaces.
Any resources that can help understanding these type of problems.
What do you mean by "these type of problems"? The languages of Switzerland?
I mean resources that have typical examples that can help in understanding programming concepts
I'm not even going to pretend that I understand the top solution.
I think it's just some weird coincidence that it worked out that way.
I considered this approach, but the missing 4th value implied it wouldn't be sufficient. Afterwards I thought I was stupid for not realising the values were chosen such that this would indeed be possible. Now you're telling me it's coincidence?
According to footnote 6, the Swiss Bundesamt für Organisation made a mistake in 1964. I have no doubt footnote 6 is telling the truth.
It's no coincidence. jcsahnwaldt was working for the
Bundesamt für Organisationback in 1964 and purposely made this "mistake" all in preparation for this kata which he had already planned.This kind of "mistake" is exactly something what Mel the Real Programmer would do when creating software for Bundesamt für Organisation in the early computing era.
This comment has been hidden.
don't post solutions on the dashboard
don't post solutions in the discourse
submit your solution; that makes it visible to everyone that already solved the kata
Can someone delete the posting? I don't know how stuff like that is usually handled...
Marking it as spoiler is usually enough, because it hides such posts from users who didnt solve the kata.
OCaml translation
Approved. Thanks!
This comment has been hidden.
Do you have any interest in a SQL translation, else I'll reject it?
Please leave it open! I had a quick look at it when you published it, I just didn't have time yet to check it and approve it. But I will! Thanks!
Already approved
Haskell translation
Approved. Thanks! Good stuff!
Scala translation
Approved! Thanks a lot!
Julia translation and Nasm translation
Great! I approved the NASM translation.
I modified the initial solution a bit: I added comments, and I changed the dummy output to
'?', because the zero char messed up the test error message.Thanks!
TODO: Check Julia translation. I hope I'll have time later today, but if someone else gets to it sooner, that's fine as well!
Julia tests are notorius for difficulties with getting a nice, clean output, but it is possible to at least get explicit failure messages. You can check Julia translations from this collection for suggestions.
I also admit that personally I am not a fan of unstructured fixed tests. Since all three types of inputs of
XXX,XXY, andXYZrepresent different cases, I think they should be represented by separate organization units (describes/its/whatever) in fixed tests of every language.I've unrolled the loops and grouped the tests by their expected output.
I approved the Julia translation. Thanks! I rewrote the tests and changed a few other details. I hope you don't mind.
PHP Translation
congrats on approval, jcsahnwaldt!
Approved. Thanks!
Actual and expected in the sample and final fixed test are swapped. Random test is okay.
Thanks! I'll have a look.
Fixed.
For a kata in beta status this one is accruing way too many translations, which seem to be the source of delay in approval. May I suggest you withold on approving any more translations, have the kata finally approved, and then deal with pending translations?
I don't really know how beta approval works. I'm just here for fun, I don't really care if a kata is beta or approved. :-)
But if translation issues hold back the approval of the kata, I'll postpone approval of new translations.
I just approved the C# translation, because we've been discussing it for a day and it looks perfect now. But we can look at the other pending translations later. Thanks!
Great, kata is approved.
Ahhh, You're a minute earlier than me :)
This comment has been hidden.
I present you with some translations:
Coffeescript☕
Ruby💎
Typescript⌨️
For side reference ^^
Additional Remark: remember to publish the kata after fixing issues below (Kata was sent back to draft when >= 2 issues are raised)
CS approved.
TS approved.
I approved the Ruby translation, and refactored it a bit to produce more helpful test error messages.
This kata deserves to be on the hall of FAME of Codewars (if there is ever one) ^^ It also showcases your character and reminds fellow CodeWarriors about the existence of Wikipedia :-)
Thanks a lot! But you forgot to link the word "Wikipedia" to Wikipedia.
This comment has been hidden.
I agree. Brilliant explanation of the problem. I wish I would have read the whole thing before diving in.
Missing
itblock for Python sample and real test suite. Note that assertions must be the first descendant ofitblocks, i.e, top-levelitordescribeblocks are both acceptable.You're right, according to the documentation, test groups (decorated with
@test.describe) cannot contain assertions. I didn't know that, and the tests worked anyway, so I didn't bother to read the docs. :-)Since the tests are pretty simple, there's no reason to introduce groups, so I guess we can simply change
@test.describeto@test.it. I'll go ahead and do that.Done. I'll publish my changes in a moment.
Java tests should use JUnit 5 instead of JUnit 4. Added bonus is that JUnit 5 provides an overload of
assertEquals(char, char, msg). Also@Ordermight come in handy.I actually tend to prefer JUnit 4 because it's a bit simpler, but the
charthing is a nice touch. I changed the tests to JUnit 5. Thanks!C++ version could use some improvements/fixes.
Issues:
time.hshould bectime,stdlib.hshould becstdlib, and introduced names should be preceded withstd::)Assert::Thatcould useExtraMessagefor custom assertion messages (see this paragraph).random_shuffleis obsolete and planned to be discontinued.Suggestions:
cstdlibandrandom, which is somewhat poor style. If it already usesrandom, why still userand?C++ fork fixing everything...
except maybe: which
introduced namesare missingstd::?thanks for the review
Well, pedants would say you'd have to use
std::size_tinstead of plainsize_twhen you include C++ headers instead of C headers, but I think that just bloats the code and makes it less readable. I'd stick withsize_t.This is easily fixable by
using namespace std;in tests (not in solution tho!), or byusing std::size_t;in any snippet.std::added tosize_tThe fork looks very good to me now.
Approved! Thanks a lot.
Rust translation is missing proper assertion messages.
Done.
C# Translation
Approved. Thanks!
Traduction en Common Lisp, bitte überprüfen, grazie mille.
Grazia fitg! Jau hai approvà Vossa translaziun. Tar la soluziun originala hai jau midà
#\Fsin#\?. Jau pens ch'il code vegnia pli survesaivel, sche nus duvrain in caracter che n'è evidentamain betg correct.In case you don't speak Romansh (I don't): https://textshuttle.com/rm :-)
C++ Translation (please review carefully) thanks!
I approved it... And then I wrote a solution that iterates over the given string, and I ran into weird errors. Took me a while to realize that a C++
std::stringcan contain'\0'chars, and when you iterate over such a string, you'll get those zeros...So I removed the line
group += '\0'from the test code, and everything worked. :-)Thanks!
if you could still have a look at the Rust version and use
[u8; 3], we can go ahead and approve this kataI don't know Rust very well. Is it very unidiomatic to use
&[u8]instead of&[u8;3]in this case? If yes, I'll change the code. But if not, I'd rather leave the code as is, because I would prefer not to invalidate the existing solutions.sorry about that
'\n'issue ... C# should have such no weirdness ;)Since the length is always 3, the input in Rust probably should be
[u8; 3]. And probablyconst char group[3]in C as well, although in C it's less significant.I don't know Rust very well. I guess when I write Rust, I mostly write C with Rust syntax. :-)
After I saw your message, I looked up some Reddit and SO threads about whether the parameter type should be
[u8; 3]or&[u8; 3], and by the time I had learned enough to make up my mind, people had already written Rust solutions. These solutions would be invalidated by the change because they wouldn't compile anymore. I think that wouldn't be nice, so I'd rather just leave the code as is.We could change the C code without invalidating existing solutions. The type would have to be
const char group[4]though, since it's a null-terminated string. I'm not sure yet whether it would be an improvement. I'll think about it.You are free to decide what to do next. But your statement (see below) should never be a reason for making a decision, as beta users are aware their solutions may still be invalidated during beta process:
The entire C translation could just as well have been designed using
enum. That would considerably change it, but when in beta, it's exactly the right time to consider possibly making such changes (though I'm not directly suggesting any particular tack).I changed the Rust parameter type from
&[u8]to&[u8;3]. I guess it's a bit cleaner.Oh, and the old solutions haven't been invalidated! Nice!
They still compile and work, because a function with a
&[u8]parameter also accepts a[u8;3]value.Should have been obvious. I'm still pretty new to Rust...
JS translation
Great! Approved. Thanks a lot!
This comment has been hidden.
Good point. I guess that shouldn't be too difficult.
Done.