• Done

  • .

  • Oooops
    Ok - I'll fix it, may be I've mistyped extra zero ;)

    Thank you for the attention

  • Kata description says Write optimal solution, cause worm can be long (10k), and there can be a lot of instructions (7k).

    But in practice (Java) I am seeing some tests pass

    • worm len = 100K
    • instructions len = 70K

    overkill much?

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

  • 1 isn't prime.

  • Then, why 3 = 1 * 3 or 1 = 1 * 1 won't pass?

  • I tried your solution several times and 2 times it timed out.
    There's a warning:

    src/test/scala/fixture.scala:22: warning: inheritance from class HashMap in package mutable is deprecated (since 2.13.0): HashMap wil be made final; use .withDefault for the common use case of computing a default value

  • OK. <SLAP>

    :yum:

    Author can deal with the actual Issue. I think both of you have a point.

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

  • Hiding things from Prelude was a side effect I chose not to handle when I ran into it, because it just didn't seem important. I could not see anybody needing Eithers to solve this. I could have just as easily made them UP,DOWN,LEFT,RIGHT and not have that problem. I can be so lazy sometimes .. :P

    Letting user define their own Up, Down, Left, Right works in this case. It won't always, but it will often. The funny thing is I regard defining things in Preloaded a service to solvers so they don't have to define things themelves! I would not have thought that actually made things harder in some circumstances. ( I don't use an IDE, I always just type into the website, so my view on this is admittedly limited. ) I might be doing it less as a service in the future, though I won't hesitate to use it when I think I need it.

    I could program a solution without special-casing the edge case, by keeping track of the direction of the head and forbidding it to turn more than 90⁰. But I'd still need to check for collisions, and I'd actually just be exchanging one special case for another, because that max turn rule only implements the special case; it does not handle ( all ) other possible collisions. At least it explains it adequately for me, and implementing it is done simplest with the special case everyone uses.

  • You're right, the worm coordinates would have to be provided as a list as well; the ascii diagram alone (or a single panel of it, anyhow) isn't enough to disambiguate state.

  • Strings. Yes I know some people have opinions about string constants, voiced
    even in this kata's discussion. That doesn't make it obviously correct/better,
    there is however something that makes it obviously have a downside: the
    Preloaded module and hiding things from Prelude.

    Using a datatype has a drawback. Does it have a benefit? Maybe it is
    overengineering. Maybe string is good. Less is more.

    This is a boundary between two organisations (the user and codewars). Parsing
    is not inappropriate at such a boundary.

    But that's what suits me, and not necessarily what's best for the kata. I
    complain about it because it sticks out like a sore thumb. I'd like to see
    Preloaded avoided wherever possible. I also think you have the better
    perspective on what's good for the kata. If after having seen my displeasure
    (for whatever that's worth) you still say that's best, then I believe you.

    Wouldn't a user-defined datatype work too? They could define a shady Eq
    instance, but comparisons could be made through pattern matching instead.
    Actually scratch that, because it's not used in the return value.

    The edge case: I think it's at best only one interpretation, and at worst is
    contradicted by the instructions. I'm all for implicit constraints, I just
    don't agree with this one.
    Implicit constraints tend to be those where if the explicit parts are
    faithfully implemented, the implicit ones fall in line. This sticks out. I
    would point out that everyone has a special case to handle this since it is
    not implied with the collision mechanics, but I can only see haskell solutions.

  • But this is also possible :

    1: worm crosses itself  2: moves left
    . . . . . . .           . . . . . . .
    . . . . # . .           . . . . # . .
    . . @ # 2 # #           . @ # # 2 . #
    . . . . # . #           . . . . # . #
    . . . . # # #           . . . . # # #
    

    And there is a third option where the tail curls the other way.

    This kind of thing is fun, but it takes extreme care to specify and implement unambiguously.

  • What suggestion would you have for passing constants to the user solution? What would work better for you?

  • Loading more items...