7 kyu
Round up to the next multiple of 5
12,538 of 36,349hwtdstrngls
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.
No random tests in Rust despite the 1000 ++ tests of hard-coded values
Условие очень непонятно...
I tried my best to get [X, Y] as a result, but in the end I was just required to get Y
very dirty explanation
python new test framework is required. updated in this fork
Approved
This comment has been hidden.
my function returns all the correct results but I'm receivig an error: Input: 0: expected [ 0 ] to equal 0
Propably my format type is wrong?
This comment has been hidden.
Go translation
approved :)
D translation
Approved
This comment has been hidden.
done
C Translation
Approved :)
looks like a problem - explanation about round; fix test abour trunc.
This comment has been hidden.
Ranks cannot be changed.
I am guessing this one is a pretty old one. :)
It's from 2015, which you can see in 'details' page. It's maybe 7.5kyu, but IMO 7 is OK for it.
Oh neat. Never looked past the promotions for other kata on that page.
I guess the colors of the kyu are a better indication of the level of difficulty.
You are super smart, we get it
Forgive me for giving half a care about the content on this site.
olaxa
Should we remind on the edge cases nearly i32::MAX, such as 2147483647 or 2147483646, because if in these 2 cases, the returned number will be overflow i32 in most of currently solutions.
This kata expects these results: ..... ..... 10>10 9>10 8>10 7>10 6>10 5>5 4>5 3>5 2>5 1>5 0>0 -1>0 -2>0 -3>0 -4>0 -5>-5 -6>-5 -7>-5 -8>-5 -9>-5 -10>-10 -11>-10 ..... ..... etc...
0 ==> 0 2 ==> 5 3 ==> 5 12 ==> 15 21 ==> 25 30 ==> 30 -2 ==> 0 -5 ==> -5
Input: 1: None should equal 5
this is my kata on codewar...
output is okay ... same to same why i am still getting this error
because you're printing instead of returning
thank for feedback.. but if i return then how i can i loop through . just an example def trial: for num in range(11): return num
then the function will break because of returing everytime...
You should never write this. Make sure you only return once.
It will only return once, just
0.Should be Given an integer as input, can you round it to the next (meaning, "higher") multiple of 5?
modified
Actual and expected are flipped in Java.
Fixed with this fork, please verify.
Done.
Hi, the final test are not working correctly, i get always the following error msg
"Input: -1 expected: <-5> but was: <0>"
but my return value is -5. The sample testcase with the same values was valid. Could someone help me?
Please see if this FAQ helps, and come back if still have problems.
Mention the language when reporting a problem, so it's easier to check. The problem is, actual and expected are flipped in Java and the expected value for -1 is 0, not -5.
The sample test is with 1, not -1.
Here is the problems in Rust, probably assert_eq! macro's left and right variables being mistaken. I checked on my local machine and everything was fine.
tests::test_exhaustive assertion failed:
(left == right)left:0, right:-550The tests are correct and the arguments are in the right order.
This comment has been hidden.
Not a kata issue. Your solution doesn't work with negative numbers.
Needs better explanation. Random test casses assume input will be rounded to closest 5. But explanation says: "Given an integer as input, can you round it to the next (meaning, "higher") 5?". Its not the same.
At least in javascript, that isn't true.
Java translation kumited! Please accept :smile:
This comment has been hidden.
I'll change the name of the kata, it's actualy inaccurate. Should be "round to the next multiple of 5"
Now it's totally clear. Appreciate it.
all translations corrected, except the Haskell one: I couldn't find out (in a reasonnable amount of time) how to put in the negative numbers. Need someone to take care of that version.
Fixed.
You still need to add random tests for the Ruby version.
"you", "you"...
"you" could do it too! ;p
Thx for the haskell fix.
Now it's rounding in the wrong direction in Haskell and all previous solutions are invalidated.
roundToNext5 (-1) `shouldBe` (-5)<- ???Yep, the description says
-2 -> 0.It wasn't fixed, it was broken -_-
Fixed (again) ;-)
ruby random tests added.
PHP translation kumited! Plase Accept :D
I didn't see your translation before I modified the description/kata. You'll have to fork your translation to update the description. Note: you'll need to update it with negatives too (so other versions, except for haskell)
Created the new translation, trying to add negatives
can U check again?
Forked and approved
Nice beginner kata. I agree names should be clarified.
Needs better explanation and better test cases
done.
Great beginner Kata but one suggestion - change the title to "Round up to the next 5". When I started this Kata I thought it was asking me to round off to the nearest 5.
I agree and was going to make the same suggestion. "Round up" would be far clearer.
Fixed.
This comment has been hidden.
Should let user know how to handle negative numbers, either in the escription or the test cases.
done.
what is the better?
Negative integers are not tested.
done.
Description should state that the task is to round to the next multiple of 5.
If n = -7, should the answer be -5 or -10?
done.
no tests and examples (clarifications) for negative inputs
done.
The description should say "round up to th enext highest multiple of 5" instead of "round to next 5". The current description is really confusing on what to do with things like 0 or a negative number. How exactly is 0 the "next 5" and should the "next 5" for -3 be -5 or 0?
done.
The instructions say round but the actually mean round up or ceil, so this is quite confusing.
done.
Some examples should be given for positive and negatives numbers.
done.
Should include a negative example or test case to illustrate whether it rounds toward or away from 0.
Either the above or get rid of "Input may be any positive or negative integer (including 0)." from the description.
done.
In C# unit test code you could omit the [Test] attribute when using [TestCase] attributes.
Not working if using big numbers in ruby,are tests okay ...?
done.
Need to improve on instructions text
done.
I might just say round to the next multiple of 5.
Suggestion
Somehow this seems broken to be but I do not why. I have tested my function in a local ip notebook on a sequence which includes the test case, I see that it correctly evaluates there. Upon copy-pasting it to the editor in codewars the second test fails (input:1, expected:5, got:0). In the notebook everything is all right.
not enough details and seems rather a problem in the code of the warrior. Closing.
No test cases for negative numbers, also description should state that you are rounding up.
done.
The appearance of the test cases is a little bit messy to me. I think it would appear more organised if every test case was one line, like in most kata's I've seen.
done.
Test didn't test negative integers but details mentionned it.
done.
At the description it says "Input may be any positive or negative integer (including 0)".
However, no negative integer is ever tests.
Rather, a set for negative integers is added or the condition is eliminated from the description ;)
done.
Add an example with a number larger than 5 as last digit. For example: 7 --> 10
done.
Large numbers would work with my own tests but not the tests run on submission. Issue seems to have been resolved now I think.
This comment has been hidden.
The ruby test uses floating point operations on large numbers, which does not yield the correct result.
I think I've fixed it. The same error was also in the CoffeeScript translation. Long story short: don't use
ceilor.to_fon numbers that exceed the safe range of2^53 - 1of IEEE 754 double values.I think that the ruby submission tests for big numbers are broken.
Works with big numbers n: 9324082039 Test Passed: Value == 9324082040 n: 129043509843590 Test Passed: Value == 129043509843590 n: 23908490234823904833 Expected: 23908490234823905280, instead got: 23908490234823904835 n: 9012384091234898738954729342 Expected: 9012384091234899173918638080, instead got: 9012384091234898738954729345
I agree. I don't see why the regulard Bignum calculations aren't "correct".
23908490234823904833 should be 23908490234823904835 not 23908490234823905280
Sorry, I have no experience with Ruby, and it is indeed weird that the solution produces wrong results.
Could it be some limitation of large integers in Ruby?
Hopefully the author of the Ruby translation could give us an answer :)
i get this too
I've got it. Going to file an issue, but I also try to resolve it.
0 is not a positive integer. The input to the function is a non-negative integer.
If we're being picky, then 0 is neither positive nor negative and also sort of depends on context. For purposes of this kata though, we include it in the range. Consider following application: rounding time given in minutes to 5-minute intervals. Numbers ending in 1-5 produce a number ending in 5, while numbers ending in 6-0 produce numbers ending in 0.
Either way, examples in the description provide necessary context to determine how input should be mapped to ouput.
Added a CoffeeScript translation :D
Thanks! CoffeeScript looks like an interesting language :) Approved!
C# translation kumited.
Approved! Thanks :)
Hi @-Julz-, sorry for hijacking this comment, I've answered your question in the previous discussion:
```
Just add the result as additional field to the test and use a regular
Assert.@hwtdstrngls, OK! This is a nice kata and definitly deserves a C# translation, so it's my duty ^^ @bkaes, thanks for your researches. Your example is a proper way to write these test cases and will keep it in mind!
You should still be able to incorporate this into your (approved) translation (you need to edit the kata), if you want to. That being said, @hwtdstrngls: Haskell translation kumited.
Thanks! Approved it.
JS translation kumited.
more info on how to approve it ( or not )
Thanks! Approved.