7 kyu
Multiply Adjacent Digits
225 of 384shreedave
Loading description...
Fundamentals
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.
This comment has been hidden.
return the result, not print
JS translation added. No leading minuses ( correctly this time ).
not 7kyu at all
I think it's EXACTLY 7 kyu
Highly depends on language ( Haskell doesn't have
eval
) and solver approach.It's not unreasonable to rank a kata for the simplest possible solution in its first language. Even then, I ranked it 6, not 7. But I was an exception: https://www.codewars.com/api/v1/code-challenges/67191920c29c7e09d9f40707/assessed-ranks
i agree
I am still unhappy about the possible leading minus sign: it's a unary minus, where all the others are binary ones.
Especially now that this is approved at
7kyu
, I would like to suggest to remove this special case. For a7kyu
, it's already complicated enough ( can you tell I voted6
? ).When solving with
eval
, this is not a problem, but when solving with a parser, it definitely complicates things.Good suggestion, removed leading minuses.
Removed in Haskell as well.
ETA: I fixed it wrong. I'll fix it right.
ETA: Now it's fixed right.
the input parameter
string
overwrites the Python module of the same nameN.B. that
str
should not be used as a replacement, as that would overwrite the Python function by that nameperhaps consider a variable name based on the concept of what's presented, which is a "calculation" or possibly an "expression"...
Thanks for pointing out, issue addressed.
( Python )
random tests generate a lot of cases that expect
0
.generating smaller numbers would help, removing
0
from available digits would also help.note that the current random generator can generate numbers that start with leading zeroes; that is a choice - solvers might not expect that and might or might not handle it correctly ( most code will handle leading zeroes gracefully ofc ).
Thanks for the input, test cases updated.
Haskell translation
this translation modifies the description. check you're OK with that.
this translation generates slightly different random inputs than the Python version. if you can read Haskell, check you're OK with that. if you can't, just take my word for it. :P
in general, accepting translations before approval is .. a choice. but I don't expect the specs to change, and the translation is probably solid ( famous last words .. ).
I sometimes reserve judgement on a new kata; uncertain whether it may be erroneous, a duplicate, or rife with issues. In this case, seeing that Johan was willing to submit a translation, it hereby earns my upvote.
I just wanted to write a parser-based solution and a
foldr
-based one in Haskell ( which does not haveeval
, does have a parser library I actually know, also hasfoldr
, which apparently is not Pythonic enough to even include in Python, and also I generally find it easier to write Haskell than Python ), and I figured I might as well translate the kata if I had all that code already.Publishing a translation is not necessarily an endorsement. ( But if it were riddled with issues, I probably wouldn't bother publishing one, you're correct there. )
.. and the specs changed after all. :]