8 kyu
ASCII Total
6,363 of 14,467user3220651
Loading description...
Fundamentals
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.
Решил через цикл for. Достаточно просто вышло.
Scala translation
python new test framework is required. updated in this fork
Approved
Haskell translation
This translation fixes the description - did nobody notice the example? Please approve Julia, below, first to prevent a merge conflict there.
Also, description update: "all ASCII" -> "all printable ASCII" - this is what's tested in the JS original. If any other translations test with unprintable characters and solutions go seriously wrong, the solutions are correct and the tests are not a faithful translation of JavaScript.
i'm the one who rewrote the JS tests - they originally only tested letters and digits. when i updated the kata to Node 14 i changed the tests to encompass all printable ASCII - simply because control characters will mess up the output and because i cant see how a solution could be correct for printable chars and incorrect for control chars
I was afraid of something like that. At the same time, I can't see how most solutions in any language can go seriously wrong for printable characters but not letters or numbers, unless they limitedly hardcode their
ord.I guess it's not that bad. Also, OP should have specified inputs in the description, and then there should have been no need to change that. Implicit restrictions are a bad idea. Testing with letters and numbers only is still forward compatible.
Julia translation and Nasm translation
Nasm approved ( not by me! ), Julia pending.
Julia approved by someone
This comment has been hidden.
C translation
Ruby 3.0 should be enabled.
Enabled in this fork
test is misleading: 'no chars should return null' yet the tests expects 0.
fixed
Python 3 should be enabled.
In the JS Sample Tests, the string
'Mary Had A Little Lamb'actually adds up to1745. Not sure where that1873comes from.Also...
Also...
In the first 2 cases you don't include 4 spaces, hence
4 * 32is missing. As of the third one - idk, you can't process a longer string and get a smaller result - it's definitely wrong.Solved Python and Ruby, so JS will have to wait. Thanks for observations.
This comment has been hidden.
Unicode has much more characters that would fit in a byte.
C#sample test cases have issue. They expectAssert.AreEqual(291, Kata.Unitotal("aaa"));insted of...UniTotal..This is fixed.
Thanks! Good job with all these translations for
C#!Nice little kata. I learned a couple of new (to me) methods here!
One suggested improvement: Console.log message says that a string with no characters should return "null," but then shows that it should actually return 0. Null and zero are different.
Kata translated into both Python and Ruby, if you want to approve them :)
I would also suggest for you to use the
.assertSimilar()method only to compare arrays or more complex objects, plus do not use if possibleconsole.log, as using bothTest.itandTest.describehas the nice side effect of grouping tests together :)Cool! Thanks for doing that! glad to see somebody liked my kata idea! I want to write one (if possible) to recover a string from the unicode total.
I fear it is far from possible: a given (high) number could correspond to many, many possible strings.
That is a good point. Could be just a pipe dream for larger numbers.
It is troublesome even for small numbers: just below 100, you can get a lot of combinations if you consider also the lower ASCII codes.
what if you had the unicode total AND a hash of the string?
A hash like...?