7 kyu
Which color is the brightest?
506 of 5,707avermakov
Loading description...
Algorithms
Strings
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.
если не знать как вычислять - то в ступоре... В шестнадцатеричной системе счисления символы A, B, C, D, E и F соответствуют значениям 10, 11, 12, 13, 14 и 15
if you don't know how to calculate, then in a stupor... In the hexadecimal number system, the symbols A, B, C, D, E and F correspond to the values 10, 11, 12, 13, 14 and 15
Added a wikipedia link, I hope that will help future codewarriors.
Your task as the author is to explain what needs to be done. The Wikipedia link is not an explanation
@3au4onok Feel free to suggest a correction in a fork.
Оно явно не 7 уровня. Задачи 6-го решаются проще.
This comment has been hidden.
It is VERY NOT 7tn kuy!!!
Hello. I don't understand why '#625E35' brighter than '#45FABD'.
What a fool! Normal brightness formula (Math.Max (R/255, G/255, B/255) + Math.Min (R/255, G/255, B/255))/2
ok
https://disk.yandex.by/i/gT4dlgDtjxkO9A
R. 83/255=0.3(min) G. 181/255=0.7(max) B. 169/255=0.66
V=((0.7+0.3)/2)*100=50%
50%!=70%
дружище тут надо найти из цветов red green blue самое большое значение то что вы тут пишите не относится к задаче вы пытаетесь высчитать яркость цвета
Your answer helped a lot. Thank you:)
This comment has been hidden.
Read this: https://docs.codewars.com/training/troubleshooting#print-input use
print_rfor php.This comment has been hidden.
That's not what it says, and the tests are fine. Not a kata issue.
Your code is completely wrong. You're not calculating anything about brightness at all.
This comment has been hidden.
I recommend adding the following or similar information to Kata:
Definition of Value of a Color: For a given color = "#PQRSTU", the maximum of PQ, RS, TU hexadecimal numbers.
Definition of Brightest Function: The first object in the Colors list that has the largest Value(V).
It will be an important and beneficial data for problem solvers.
Note that comparing the value for V in the HSV model absolutely doesn't come close to comparing the perceived brightness. #FFFF00 is much brighter than #0000FF although V is the same.
In order to compare the perceived brightness, one needs to compare the weighted average of the gamma-corrected R, G and B components.
That's a great idea for an advanced version of this kata! :)
There are numerous issues with the test cases:
The actual answer is => #FD7734
This comment has been hidden.
Thank you for the help, I've seen my mistake.
C translation
thank you
Any sensible reason for
nulling arrays instead of passing size?both approaches have their pros and cons i guess, just like nul-terminated strings ... what are your reasons for not liking it ?
That it isn't standard way of handling arrays, and best practice approach is preferred on cw while authoring / translating kata, to the point where plenty of betas have issues raised over stuff like this.
sorry, i fail to see any issue with this approach, it's just like a nul-terminated string and it's easy to understand and manipulate. there are only 30 C katas in beta and i dont see what you're talking about. also see
main()'sargv[], and theexec*family of functions :execv(), execvp(), execvpe()take aNULL-terminated array of strings as parameter.Yeah, sure ok.
In Python's random test, user can mutate input.
Thanks, I am working on a new version of tests providing the input in failed logs, I will fix this.
Fixed
Fixed in JS too. I don't know for PHP, I'll leave a message to the translator.
error from random tests: expected '#CD0C29' to deeply equal '#51F321'
but these colors don't have equal brightness even visually close :) #CD0C29 = max(25 12 11) = 25 (btw, in HSB it has B=80) #51F321 = max(6 18 3) = 18 (btw, in HSB it has B=95)
You are misreading the log, this is telling you:
expected your_answer to deeply equal the_correct_answer. Please don't raise issues so lightly in the future, provide more informations (language, input, output, logs) and read carefully this: https://docs.codewars.com/training/troubleshooting/sorry for this and thank you
approved by someone
Rust translation, please don't approve before the question of the case is clarified.
Forked to update description and approved. I hope that's the right way of doing it? :)
Perfect :)
The description should state if the case matters in a sense. Currently, the fixed tests use uppercase hexstrings, while the random ones use lowercase strings exclusively. In the two forks below, I used uppercase for random tests too. The description should clarify this point. The easiest way is probably to use uppercase everywhere like in the description and the forks.
Just realized something: random tests are not good in JS and Python: they always generate colors in the form
#0x0x0x(withxbeing a hex digit). They should generate random int32 and convert them to hex.This should fix the issue in Python: https://www.codewars.com/kumite/62ebec47d6f0ec004aba87ab?sel=62ebec47d6f0ec004aba87ab
(I meant int24).
Fix for Javascript: https://www.codewars.com/kumite/62ebeda1a29959000f07eb2a?sel=62ebeda1a29959000f07eb2a
I didn't check the PHP translation pending.
Edit: apparently the PHP translation has the same issue, I have left a message to the translator.
I approved both forks, thank you very much for spotting this. The problem was that I took randint for half a byte (up to 15) and not full byte (up to 255) as I should have.
Nice. Do you agree with updating the description to state the strings will all be uppercase? That would fix the second issue and make Rust translation approvable (others will come soon).
I have just added a footnote for that.
Approved.
This comment has been hidden.
Let people repeat your mistakes if they have to. Doing mistakes a very good way to learn how not to repeat them later.
typo in description:
brightest(["#00FF00", "#FFFF00", "#01130F"]) == "#FF0000"Thanks, well spotted.