Excellent point, updated the description.

Very nice, I would've liked to have had the initial test feature populated, but attempting to submit sufficed.

I believe the limit is a few seconds, as I found out on the image processing kata ;-)

UPDATE: now after solving the problem, I'm morbidly curious just what you're doing that's timing out...

Should probably fill in the initial test fixture field to make it easy on your users.

Nice one, about the only improvement I could see would be filling in the initial test case so that your users need not copy/paste/adapt from your problem description.

Not sure if you'll like this one, but I'd also suggest using/providing a convenience utility for testing, here's the one I used:

function TestDictionary(spec) {
  var matcher = new Dictionary(spec.words);
  spec.expectations.forEach(function (e) {
    Test.expect(
      matcher.findMostSimilar(e.query) == e.nearest
    , 'expected findMostSimilar("' + e.query + '") == "' + e.nearest + '"'
    );
  });
}

And how I adapted your first description case:

TestDictionary({
  words: ['cherry', 'pineapple', 'melon', 'strawberry', 'raspberry'],
  expectations: [
    { query:   'strawbery',
      nearest: 'strawberry'
    },
    { query:   'berry',
      nearest: 'cherry'
    }
  ],
});

Okay, well now it let me submit my "spaghetti" version. For reference, the spaghetti versions runs in ~0.1 second on my macbook, where-as my refactored version takes 0.6 seconds (probably largely due to temporary array allocations and more indirection used for clarity / generality / more like a grownup numeric api). I'll submit my refactored version if codewars lets me at some point in the future. I'm bemused that code which runs in 0.6 seconds on my (imo modest) macbook takes so long on your server ;-)

Well @jhoffner, since I actually managed to succeed in one attempt in the past and can now see the test cases (despite not being able to get further solutions through to submit), I was able to actually copy the entire test suite for this kata and run it locally: 0.677s on the wall clock (0.656 user + 0.024 sys) on my macbook.

Speaking of the test cases, @constablebrew, if timing is an issue you may want to consider hardcoding expectations rather than computing them with a reference implementation.

I'll play with my solution a bit to see what I can trim.

Okay, so here's the confusing part for me:

• I can run my code against the two demo tests you have in the description text (note you really should put those into the initial test fixture input for your user's convenience)
• my solution succeeds every time against these two trivial tests
• however every time I hit "Attempt", all I get is a mysterious "Code Timed Out"

Well anyhow, now that I've solved it (even if codewars won't let me actually "Submit" my solution, it at least recognizes that I have succeeded an attempt in the past and lets me see solutions and such), here's my thoughts:

• first off, I liked this kata a lot: it was more involved than most others on this site, even if it was in the (imo) most annoying of the three languages offered
• having some background using grownup numeric packages (octave/matlab, numpy, R, etc) this was an interesting demonstration for me of just how unsuitable raw JavaScript is for this task: you end up with way too much spaghetti too easily, while having no good end game for performance
• there were some points where I felt the problem could've been more interesting (hard); mostly the, seemingly, arbitrary restriction to odd-square kernels

I really do hope that codewars lets me submit my refactored solution at some point since, I feel, it demonstrates a way for managing the pasta-explosion and recovering something resembling a sane grammar of functions for doing ndarray-style manipulations (yes my NumPy/octave/matlab experience is showing through in this).

I really wished that the test-case swatches let me get better access to the raw data. Personally I like the base64-coded raw octet-stream approach that I used in my first comment; but even a json-encoded array form would be better than nothing. I was able to get my own data (of course) by console.logging it, but copy/pasting that way is a bit awkward. I wouldn't expect someone for whom this problem is a challenge to be able to pull off the canvas API convolutions that I did to extract the actual expected data.

In my opinion, since the likes of Coursera present problems far harder than this in their intro to GPU programming classes, I really don't feel like it's that "hard"... but then the same could be said by comparing large swaths of the katas on this site with other MOOC content.

Great, it's working now, and I'll be able to submit my solution as soon as codewars decides it will let me:

• once I dropped my "renormalize the kernel" line, it passed your corrected test suite completely; my previous (with renormalization) matched your test visually (no noticeable difference to the eye) but had the slight offness cited in my OP
• however, after cleaning up my code and trying to resubmit, it now perpetually results in "Code timed out", despite still working locally

Maybe the timeouts have to do with my mobile internet... will retry when I get home... but that seems a dubious explanation.

First off: kudos on a fantastic kata, I've thoroughly enjoyed this one.

It appears to me that the test suite is sensitive (for better or worse) to floating point rounding issues. I'm not sure if my solution is still slightly wrong or what. I've tried some floating point fudge, but it's only made things worse (but then there are just so many options for fudging floating point.... I'm sure I've not been exhaustive).

My solution passes the first 6 of your tests, but fails the 7th.

I managed to extract the image data from the expected canvas for test 7 (the 9x9 kernel with a -0.9 center), and compared it with my console.log'd output generated by my solution:

• 7147 of the 7776 (72 x 36 x 3) values differ (~92%)
• within these differences, we have:
• min: 1
• 25th %-ile: 2
• 50th %-ile: 4
• 75th %-ile: 6
• max: 28
• mean and sample deviation: ~4.36 and ~3.15 respectively

Here's my raw data (encoded as a raw binary stream... hmm me thinks decoding that by itself would make a decent kata ;-) ).

Maybe I'll wake up tomorrow, look at my code, and be like "ahha! that's what's wrong!" ... but figured I'd provide some feedback at any rate.

Certainly agree there @nklein. Perhaps I've come off overly harsh:

• I don't in any way dislike the problem; in fact I too found it quite interesting (why else would I take the time to comment?)
• I simply feel that its problem statement doesn't provide enough to go on without (in my opinion) undue side research

I think you misunderstand my point; my objection is precisely that this feels more like a "problem in pure geometry" rather than a "problem in programming".

No matter what you take $domain to be (astronomy or geometry) I'm saying that your problem description requires too much pre-existing knowledge to permit for a focus on programming skill.

If I wanted to, I probably could scrape together enough geometry / astronomy info by googling or wikipedia hopping. But just from your problem description, it's not clear what you're asking for unless you have that geometry background.

It's not that I think your problem is fundamentally "hard", it's that you may not be testing what you may think you are; those who have solved it likely had enough familiarity with domains outside of programming to read between your lines and know what you mean by "matching".

Finally realize, if this were not a "Beta" kata, I'd just move on or solve it (by doing the needed background research) and provide little to no feedback. I'm trying to be more useful to you during beta by trying to remain in more of a "beginners mindset" and work solely from your problem description.