Ad
  • Custom User Avatar

    This really doesn't seem kyu7 difficulty to me. At least not for JavaScript. kyu7 is a beginner tier. This is deceptively complex and requires caching results, type conversion, custom value based sorting, and a decent amount of manipulation. Add in the fact that the description is implicit instead of explicit for things like including the original value in the sort options and you are just going to frustrate someone who is at a kyu 7 skill level currently. This should be at least a 6.

  • Custom User Avatar

    This comment is hidden because it contains spoiler information about the solution

  • Custom User Avatar

    This comment is hidden because it contains spoiler information about the solution

  • Custom User Avatar

    It is hard to consider this even 8kyu when the description basically says what to do. More importantly though, there are a bunch of string reverse kata already.

  • Custom User Avatar

    The Math.pow bit is genius. Not sure if you saw that somewhere or came up with it, but that would have saved me a heck of a lot of time figuring mine out.

  • Custom User Avatar

    This comment is hidden because it contains spoiler information about the solution

  • Custom User Avatar

    This comment is hidden because it contains spoiler information about the solution

  • Custom User Avatar

    This comment is hidden because it contains spoiler information about the solution

  • Custom User Avatar

    Happy to help. Thanks for taking the time to make it and quickly adjusting it as well. ;)

  • Custom User Avatar

    Ever finish a kata and then look at everyone else's solution and then look back at yours like.. "that was bad"? This is totally that kata. Some great solutions here guys.

  • Custom User Avatar

    For clarification, toFixed() doesn't just truncate. That would be easier for people to understand at first glace than the real problem. Instead, it likes to trick you into thinking it works fine. 1.556 will properly round to 1.56 and 1.5551 will also properly round to 1.56 even though 1.555 will not. Even funkier is that toFixed(2) will turn 1.525 into 1.52 but 5.525 into 5.23. It is floating point stuff and it makes rounding a bit inconsistent and unreliable. In multiplying by 100, or however many 0s you need to get out of decimals, you move away from those floating point innaccuracies. So except in weird big number situations it is a good way to get a more accurate rounding result. Technically you could do (1.555 * 100).toFixed(0)/100 instead of Math.round(1.555 * 100)/100 to get the same workaround but Math.round is more self explanatory for integers than .toFixed(0) so it tends to be the better choice. There is also toPrecision() but I don't think it avoids this issue either. Here is some related content: http://stackoverflow.com/questions/588004/is-floating-point-math-broken/588014#588014 If you have never dealt with floating point weirdness and want to blow your own mind, try this: Console.log(.1 * .2);

  • Custom User Avatar

    This comment is hidden because it contains spoiler information about the solution

  • Custom User Avatar

    It is worth mentioning that "11" is technically a valid substring of "11" but is excluded from the expected test results. Technically you "11" has [1,1,11] as substrings and all 3 are of course divide cleanly.

    This is already implicit by your example of "11" being 2 in your description but it is probably best to make it explicit with a statement like "the full number does not count as a substring of itself when counting matches."

  • Custom User Avatar

    The description should say "round up to th enext highest multiple of 5" instead of "round to next 5". The current description is really confusing on what to do with things like 0 or a negative number. How exactly is 0 the "next 5" and should the "next 5" for -3 be -5 or 0?

  • Custom User Avatar

    This comment is hidden because it contains spoiler information about the solution

  • Loading more items...