Retired
Calculate Average of 5 Rubik's Cube Solves (retired)
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.
The description could be more condensed instead of pasting the whole rulebook into it.
500 random tests is too much, 100 is enough.
I know for this kata it is difficult to change it; but returning different data types is bad practice.
Current input method and rounding requirement is flawed anyway; try this:
The proper method to it is to use
Decimal
object to parse time strings as decimals directly; see https://www.codewars.com/kata/round-and-roundNot disagreeing with the proper method, but isn't that example correct? I don't understand the point you are making with it.
round(2.675, 2)
gives2.67
instead of2.68
because of floating point inaccuracies.In any case, there are some specific values where this will happen, which is why doing decimal rounding over floating point range is a bad idea.
Ah ok, I understand. I was not sure how acceptable it was to use rounding in this kind of kata (which is supposed to emulate some kind of 'real world' requirement), where rounding issues could be considered a part of the task. But if it's bad CW practice I guess its bad CW practice.
This comment has been hidden.
The implementation of
real_round
provided by the kata is flawed: it doesn't accepts thendigits
optional parameter.Also calling it
real_round
is disgustingly misleading; Banker's rounding is the real round since it's recommended by IEEE standard. The function should be called something faithful and accurate likeround_half_up
.Tests shouldn't log anything.
I only logged text in the tests because the descriptions of tests were offset (descriptions of the previous test case would show up delayed to the next test case).
Edit: Fixed.
Marking issue as resolved
Tests rely on the user's solution importing
math
.No, what makes you think so? Check my solution for instance which has no imports and it still valid.
FArekkusu, besides the Author you are the only solver so far who has imported the whole
math
module. No other solutions had an issue with it.This?
I did some digging, seems this is
only an issue ifcaused when the solver importsreal_round
themselves instead of using the existing one.Should still be fixed though.
Using an existing what?
real_round
is defined in a separate file, it must be imported. It seemspreloaded.py
is concatenated tosolution.txt
andfixture.py
when there're no explicitimport
statements, although it really shouldn't be.I just loaded
real_round()
into the initial solution as to avoid confusion.Moving
real_round
to initial solution doesn't change the fact that you must importmath
in the fixture. Thereal_round
defined in preloaded should be explicitly imported too, or moved to the fixture completely.You shouldn't need to import math, I don't believe--I think you can just use
real_round()
without importing (since it's in the preloaded file) and without importing math (because math is imported in the preloaded file), at least when it's preloaded.import math
has been moved to the initial solution, though. I'm sorry if I'm misunderstandingsome info on setup of modules: https://docs.codewars.com/languages/python/authoring#imports
@mjaydenkim To reiterate, you should
import math
at the top of the tests, since you usemath.floor
within the tests. This will solve the error FArekkusu was getting.You really do not need to
import math
, integer division with 1 should've done the job.New test framework should be used.
real_round
should be preloaded in the initial solution.I included it in the preloaded file, but I have just added it to the initial solution as well.
Some of the numbers in the list of some of the tests are greater 600 seconds (which translates to 10 minutes).
Oh, I meant under or equal to in the context of those conditions apply to 10 or under minutes. I should clarify that.
It was clear to me, but might be better to just modify the rule itself. (
9f1) All timed results under (or equal to) 10 minutes...
) rather than adding it as a note mid sentence. I doubt anyone here is going to be familiar enough with "cubing" to be offended by slightly altered rules.Very good point -- doing that right now.
Done, will push out changes when I fix the random tests issue.
Then it is not clear why some of the result are expecting floating number with non-zero fractional part.
It only expects floating numbers when the average is under 10 minutes
I did not see any results over 10 minutes expecting a float. I think you can safely close this issue.
Okay, cool.
Random tests are generating list of 4:
Oh, huh. Lemme see. It shouldn't be doing that
I found the culprit--it's a printing error, not a testing one. I'm going to fix that right now
It is actually a testing error, the reference solution is mutating the input list to remove
"DNF"
, so the list the user receives does not contain it. (Just send the reference solution a copy of the list instead)Oh, okay! Thank you so so so much for clarifying that, I was wondering what the problem was but I guess it was that simple.
Just fixed that issue as well as another printing one (descriptions of the previous test case would show up delayed to the next test case).