6 kyu
Going backwards: Number from every possible sum of two digits
93 of 140JohanWiltink
Loading description...
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.
Hi,
Errrr.... Dunno what going on, but something seems to be very wrong (python):
[9]instead of 99 as annouced in the tests?Cheers
ok, the problem is: the tests are not testing the output of the user but are actually rebuilding the input. Nothing is said about that and that's not what is done in the sampel tests so it's confusing af...
edit: note: actual and expected aren't swapped, so, ofc...
Because
so I can't tell you what the expected output is. I have to test in reverse. That's what
sums:says.yeah, I already know that. But what you can tell to the user is the way the tests are done in the full test suite. ;) Again:
Oh. OK. Except I can't. Because I'm not that into the Python test framework.
I'll be happy to see a fork suggested to fix this.
This has nothing to do with the test framework... It's about addding a line to the description... (I know you're allergic to descriptions modifications, but... XD )
Oh, you want it added to the description?
No, not doing that.
ffs, WHY?
Not closing the issue, then.
Because that doesn't need to be in the description. It can be done in the
itheader and the failure message, so it doesn't need to pollute the description.but aren't you using that approach in all languages?
Yes. But I still feel that it's better to explain that in failure messages than in the description.
But it's not "technical", it's "logical". Its place is in the description, especially considering that's not the usual way of testing the user's solution.
I don't understand what you mean by logical instead of technical.
We disagree on explaining testing in the description.
technical: bad way to express "language specoific", here
logical: the general idea behind the tests
It's that simple.
And that is what I want to have in the failure message, and not in the description. Because it's not pertinent to the task how it will be tested.
Also, for certain cherry-picked inputs ( example tests ), it's not how they're tested.
Do it as you prefer, but the info has to be given somehow/where. Currently, the test feedback is totally useless because the user is not warned about that (meaning the kata is a pain to debug)
Took me a while to figure out Haskell includes empty input, while JS does not.
Isn't
n = 0an empty test in JS as well?oh yeah, silly me .. forgive me and accept this gift
Approved. Thank you!
Not a good problem description and confusing test cases.
This problem could be good, but as it is written right now, it is confusing and a waste of time.
Please let user code run inside the
itblock: Otherwise things that our program prints to stdout appears before theitblock in the output window, which is incredibly confusing.In Haskell, that's just the way it is ( which is probably why it doesn't confuse me ).
In Javascript, it's been implemented.
I think you could have phrased this as a suggestion, and it would help similar cases if you specified a language.
Pooh! That was really difficult but exciting! But it had to make a hack on the case with one element in the array. Now will examine other solutions. Thank you!
test case which make me so confused!
testing for 12, Expected: [3].
??
It's also testing backwards.
Your input is
[3]. Allowed return values would be12,21or30.Because there can be multiple possibilities, the test checks the resulting sums of digits, not the return value itself. Those digit sums are unique.
The description is bad. We don't understand why the expected value of the first test is 156.
[6, 7, 11] -> [ 6 + 7, 6 + 11, 7 + 11] => 48, not 156.
This comment has been hidden.
Because
156 => [ 6, 7, 11 ]This is the reverse of another kata. The top of the description is from that other kata.
THATS why I'm so damned confused
Ahhh... Ok thank you, now i understand.
Was debating asking a question but I gave in :)
I did the other kata being mentioned here - but i'm still lost. The previous kata returns the array and it looks like what's being passed in this funciton (sums) is that array.
How are we manipulating the array here [6,7,11] to get 156?
Not giving out spoilers, sorry.
any non spoiler - hints?
The other kata tells you how to go from
156to[6,7,11]. All you have to do is reverse that.Of course, the input might have been
12345, so you'd get[3,4,5,6,5,6,7,7,8,9]. Could you get back from that to12345?Collecting some different inputs and outputs from the other kata might be useful; you might be able to spot patterns without trying to reverse the manipulations from first principles.