Kata

Thanks for your feedback. Added some random tests.

The random tests look good. That marks off the first two of my points. The main issues now are in your description.

1. You say that number is in range [0, 1]. As Johan said below, you should specify that it is a float. Also, if you say it is in the range [0, 1] then you should not be testing for other inputs.

2. You do not specify what happens if the input number is not between two colours. For example if the lowest color is at position 0.2 but the input number is 0.1, you need to tell us how to handle that. Should it assume that the color at point 0 is black/white? Should it assume that there is no gradient, and that it should match the "lowest" colour? (Which is how it currently works). You just need to make it clear

Also, as a side note, as you fix each issue, feel free to mark them as resolved (if they really are fixed)

Hey! Thanks for your feedback, I've improved the description a bit. Now is it clear what is required to perform this kata?

Ehm, no, not yet. Should the return value really be a function from a colour value to a position?

added an example of use

Yeah, that example is inconsistent with

f([r1, b1, g1]) = p1 and f([r2, b2, g2]) = p2

rainbowGradient is f but over all colours at once, right?

my bad. its totaly wrong. the solution should be similar to https://developer.mozilla.org/ru/docs/Web/API/CanvasRenderingContext2D/createLinearGradient, but with 1 dimension and no changeable after creation

And this is why.

Position: 0.9430000000000005
Color Set:
0.0062509: [ 142 203 35 ]
0.1516516: [ 58 187 133 ]
0.1601735: [ 24 198 209 ]
0.1705400: [ 138 62 34 ]
0.2448608: [ 46 100 113 ]
0.2584741: [ 103 205 10 ]
0.4570756: [ 39 41 117 ]
0.4851606: [ 113 106 66 ]
0.4910144: [ 177 90 254 ]
0.4938313: [ 186 233 82 ]
0.6313692: [ 39 159 160 ]
0.7993191: [ 121 236 202 ]
0.8148218: [ 104 254 36 ]
0.9360975: [ 42 81 226 ]
0.9608953: [ 172 52 226 ]
0.9646473: [ 46 121 73 ]
error: expected [ 78, 72, 225 ] to deeply equal [ 78, 72, 226 ]

My solution is correct, and, with some repeated submitting, accepted. ( It doesn't show up in Solutions, but that's probably a CW error. You can see it by clicking View Solutions on any of my comments. )

I genuinely think this is a cool idea for a kata (It seems to be unique as well). I strongly suggest you fix up the problems with it before more people start solving it and rating it badly just for the problems.

I actually agree with this sentiment and think it's a crying shame I just voted "Totally unsatisfied" because you are handling floating point arithmetic really, really wrong.

You have just invented the square wheel when round wheels have been documented for ages.

Position: 0.9430000000000005

p1 0.9360975: [ 42 81 226 ] p2 0.9608953: [ 172 52 226 ]

expected [ 78, 72, 225 ] to deeply equal [ 78, 72, 226 ]

between p1 and p2 blue always equal 226

but you last solution give corect result for this color set

i realy want to keep rgb as integers just like in RGB24

I am not willing to discuss anecdotes. I copied that failure message straight from your submit tests, and you are handling floating point arithmetic wrong.

I know I'm giving the correct answer. My solution is not the problem.

Have you read applicable docs? If, after reading those, you do not understand how to do FP arithmetic in your kata, or why, I am willing to have a conversation.

i realy want to keep rgb as integers just like in RGB24

I understand that. But it can't be done, not in a CW kata. Do you understand why?

You have just invented the square wheel when round wheels have been documented for ages.

I just noticed "round wheels" is a very unfortunate turn of phrase .. :P

Do you understand why?

not realy

CW kata

What is mean?

CW = codewars

So, did you read applicable documentation?

Yes, I read. You are right. I do not really like this idea, but I will make changes.

Seems fixed correctly. Thank you.

You don't have to like it, and I can see why you wouldn't.

One way you can use rounding in a kata is by specifying a specific order of computations ( expression parsers can do this, and sometimes they do. and sometimes then then still get it wrong and allow an error margin ). Or you would have to use a +/- 1 delta, which gets a bit ridiculous, but still lets you specify integers. It's definitely a design time consideration, not an afterthought.

Sorry I was right; I have an irritating tendency to do that sometimes. I try not to let it happen too often. Sometimes I succeed spectacularly. :P