Fine! I like that it is ongoing. You can disable/remove the ts-code and optimize the kata with your suggestions :)
When I'll be back in summer I will reimplement the TS.
Although thanks - and happy coding! ;)

I'll have a look. I don't know TypeScript though, so I can't change what I cannot also change there.

Thanks, anyway!

Hello Johan, I'm out of codewars for the last view weeks (private needs) and will be the next few weeks (project change). Can I give you access to the kata to contribute in it? I will do so. As I can see in the settings contribution is free ;)

Bump.

I don't mind waiting, but I can also just do the Haskell version as a separate kata.

Found the time yet? I have a Haskell translation more or less ready to go, but I'm waiting to see what changes need to be incorporated into that.

Function arguments are named and represented inconsistently in the description and the initial solution ( and possibly other places ).

I'd suggest calling them by the same name everywhere, and representing specifically the f argument ( the first one ) as a string, which ATM it is, and not as a function ( which ATM it is not ) in the description examples. I haven't checked the test headers, but the same goes for them. Should you decide to make the first argument a function, then of course represent it as a function everywhere.

Tanks for feedback in advance. I will refactor the kata depending on your suggestions. Just need a few days to get a timeslot for this ;)

Nope. Inputs, and therefore outputs, are entirely predictable. You could at least randomise the order of the tests with const ranges = Test.randomize([5, 10, 20]), et cetera, or, slightly better, generating all combinations and randomising that. Or you could really randomly generate values for x, step and range ( within a reasonable range of course ) and randomly pick f from a list. See some other kata how it's done; most follow the same template ( and some use ridiculously intricate patterns. don't read those :P ).

I like this kata!

I suspect you could have gotten a different idea from all my issues, suggestions and comments, but I quite like the premise; it's just a number of design and implementation details I feel are worth improving ( which is .. kind of a pat on the back with a wrecking ball ).

I agree with Voile here - the semantics would benefit from the result being a newline-separated string. I don't think it's essential - if you don't want to, just don't, and close the suggestion.

Having a 2D array wouldn't make it any easier to test single values, because you can index a string exactly the same way as you can an array.

I do feel it's just inconsistent to have one .join over the 2D array; either zero or all of 'em would be more consistent. But that's just My Inner Autist peeping out. ( MIA has been known to be technically and morally correct, of course. Also, a jerk. )

eval(fct) works without replacing x if x has the correct value in the local scope ( or any superscope ). ( This whole abomination that is eval would not be necessary if fct was passed as an actual function. )

For an example solution, this is not very readable. Please consider what you're trying to showcase here. Make the logic as userfriendly as possible. You can then, if you want, optimise the H*ll out of it for the reference solution, sacrificing maintainability for conciseness and/or speed.

It appears the x parameter is the middle of the output grid. That middle is of course defined by two coordinates, and it would seem its y coordinate is also defined by x.

Is this correct; is this the best way to define the middle of the grid ( I think not ); and if correct, shouldn't this be described more fully?