Kata

Thank you, I have updated the description.

the colours must not only be 'truthy/falsy' but will be treated as booleans. After all, the standard RGB range 0-255 are all truthy and falsy numbers in JS too.

and sorry I don't see the issue here? 0 ≈ false, 1-255 ≈ true

Apparently, there is no difference between 1 and 255. But there could be.

Would more example images suffice as hints?

that would be a start, but you cannot avoid explanations about how scaling has to be handled

And I can understand you do not want to specify dithering, but generally, specification by example ( ie, reverse engineering ) is frowned upon in Codewars. The description should specify, examples can then clarify.

Mind reading is not an available language on here for a reason.

Could you address what's wrong with purple as well? [1,0,1] doesn't seem any more wrong than [1,1,1] ( ie, white ).

Mind reading is not an available language on here for a reason.

I was just trying to write a challenge that I would enjoy.

Could you address what's wrong with purple as well? [1,0,1] doesn't seem any more wrong than [1,1,1] ( ie, white ).

There's nothing wrong with it, a different Kata with a different image could use it.

The problem is, reading your mind is a lot easier for you than for all of us.

It's not mind reading, it's pattern recognition.

I would absolutely agree with you, if tests are done by comparison with a margin for error ( see my third point in the original post ).

Since you never addressed that, I take it comparisons are done without one ( or you would have been proud to note you did things correctly ).

That means it's not just pattern recognition, it's also divining the order of operations your reference solution uses, when we can't even know which operations your reference solution uses. In short, mind reading.

Any kata that uses floating point calculations in a language with IEEE.754 floating point numbers relies on order of operations. This is well-documented, and I will not reproduce that here. Expecting solvers to reverse engineer what order of operations you used, when we are not even sure what operations you used, is too much. Did you know in JS there can be a difference in results between Math.hypot and Math.sqrt for equivalent arguments? Between .toFixed and round ? Between a + b and b + a ?

Really, it's not the pattern recognition part of the kata I take issue with; it's the floating point repesentation inaccuracy mishandling. Which is inherent to JavaScript Numbers. Which you'll have to address in your kata design and testing, not by saying "it's a challenge."

Your first kata addressed this problem by specifying the full order of operations: PEMBDAS, and left-to-right within that ( right-to-left for powers ). That unambiguously specifies order of operations, which means testing should compare for exact equality ( comparing with a margin for error would be wrong there ); that kata ( probably ) did not have this Issue, quite possibly by accident. This one, and the next one I see you just published, very probably do.

I could do an easier version without it?

maybe, yeah.

But in the first place, you should actually describe what the task is. "Reverse engineer" could mean anything here.

• what's the input? (format)
• seems there is only 1 single input => in that case, you can unpublish the kata right now. That won't ever be approved in that condition (did you see the documentation about authoring? (third icon in the left menu bar))
• the output format of the color array isn't properly specified

'still a lot of work on this one before it's in state for approval, I believe

=> ?

this input in the description2 numbers, width and height and I can't find the condition you're referring to? and what's wrong with the output, it's an rgb array?

inputs: mmh, I missed that, sorry. So, how many tests are there?

seems there is only 1 single input => in that case, you can unpublish the kata right now.

condition

'never talked about a conditionnal thing. Maybe you mean as a "problem"? (I'm not native speaker, sorry). Here are some walls of text for you to read:

• https://docs.codewars.com/authoring/guidelines/submission-tests/#general-guidelines
• https://docs.codewars.com/languages/python/authoring/

rgb array

uh, I did read the sentence a bit too fast, yeah. I was missing the 0/1 info, ok.

'never talked about a conditionnal thing. Maybe you mean as a "problem"? (I'm not native speaker, sorry). Here are some walls of text for you to read:

Sorry I misread. I don't see an issue in the first link? and the second one is for python? Could you give me a direct quote of a rule it breaks?

Did I raise any issue? ;) nope. Not yet, at least.

But I see you keep avoiding my question: how many tests? are there random tests? Because that is mandatory, nowadays. If you don't have random tests, the kata will never get approved, sorry.

python/JS: damn it... I'm out of my head, this evening x/ Well, some ideas apply. And iirc... here is the JS version if needed, but that's mostly about the implementation, so might be useless to you.
The other link is far more "important", here.

But I see you keep avoiding my question: how many tests? are there random tests? Because that is mandatory, nowadays. If you don't have random tests, the kata will never get approved, sorry.

My bad, yes, there are 100 random tests. Do I need to state that in the description?

and 11 fixed

+2 rule tests

there are 100 random tests. Do I need to state that in the description?

ok, good. No, not necessarily. On the other hand, what you have to add is some information about what the user is tackling. For instance, how scaling is spposed to be done? You have to at least give some indications (otherwise, it's just like the very old kata where hald of the requirements are hiden/not even announced... You should dig a bit in that direction, you'll quickly realize how much it's annoying for the user x) )

Yeah, I believe an "unconstrained" version could maybe be interesting. Hard to tell so far, since the requirements seems a bit vague for now, tho.

+2 rule tests

?? not following