Kata

I don't speak haskell. Can someone check translation before approval?

Some things to look for (and maybe consider regardless of reading the translation)

I don't know if I like requiring the rawError flag to be defined by the solution (cannot be removed) An option could be a magic comment that is checked for in the source ... but I'm not much a fan of that either. I had a thought involving unsafePerformIO but getting the user to force that thunk might seem difficult. Among non-optimal options I went with simple. happy to modify it.

oh and I changed the number of small tests to 100... is that bad? it makes the description lie a bit, something I saw later. (lol who reads descriptions before translating amirite) It's trivial to change of course.

And ... it takes a while to run. It reports 6-7 seconds or so. ~3 is compilation, 1.5 for reference, 1.5 for solution. My solution is far from optimized so swapping in a different one might make that number more sane... Performance isn't supposed to matter but err I guess it does. Locally, my python solution + the test suite runs in 0.9s, and my haskell solution + test suite runs in 0.7s so it's arguably same/faster ... just that the haskell runner isn't so great

I changed the input type from set to list. This avoids forcing an import on the solution. I think that's the right choice, leaving the user to use whatever data structure they want. The shape of the data is still the same, a bunch of coordinates. This 100% does not need to be mentioned in description since the type signature makes this very clear and list can be interpreted as set imo... especially when the values are unique, which I do ensure.

I don't know if I like requiring the rawError flag to be defined by the solution (cannot be removed)

In python it isn't required (not defined is the same as False). I don't know if in haskell there are better ways (something in predefined?).

oh and I changed the number of small tests to 100...

IMHO 32 are enough, but there isn't a big difference. The main goal of small random tests is to provide some easily debuggable random test.

I changed the input type from set to list.

It can make difference if there are many membership tests (if (x,y) in shape).

No there are no mutable variables. Can't put it somewhere else because it can't be changed. It is possible to have a reference to something mutable, however, modifying that requires sequencing an IO action, that is, program control has to go through it and that doesn't happen if it's just a global "statement" unless it was looked at (evaluated) which means the user solution would have to put it within its evaluation path which will confuse ppl. Plus, it involves a hack to put IO code in side-effect-free code so it's bad all around. The closest thing would be a comment, I think. Anyway, I decided to display BOTH. I think that works well. The flag is now entirely gone.

> drawBorders [(1,1)]
  Expected "+-+\n| |\n+-+"
  +-+
  | |
  +-+
   but got "+-+"
  +-+

ye?

I changed the test sizes to match. 32 45 50. I think the small ones are good opportunity to catch as much as possible but uh. I don't really know nor care. Happy to match them to the description.

The list stays. Obviously ppl should use data structures that support what they are doing. But since I cannot say what that data structure is, all that remains for me to do is to pass them the data. There is no standard set type like in python. And in python there is only one obvious choice, that's also not the case. And it's an import from outside the standard library. You wouldn't import numpy to pass in a 2d array. It's not the fastest data structure for lookups either because it's a tree set, not a hash set. Faster would be to use Array, but now the shape of the data changes because it becomes key->value. List.

Thank you for letting me know how you feel about things, it helps so much!

The figure is the union of unit squares, there aren't triangles.

Imagine a plane divided in unit squares, each square has (x,y) coordinates.

Added an image with examples in description.

Thanks! Have a better grasp now. The figure in the description helped also.

IMHO it's a 5 kyu or maybe 4 kyu. My initial rank assessment is 5 kyu, as you can see from katas list.

Someone ranks everything 8 kyu (and downotes everything), someone ranks 1kyu easy katas. Min/max/avg ranks on kata page aren't very reliable, especially with few assessments.

Yup, that's unfair. XD I've to write extra 20 lines of FF to clean up the holes stuffs.

But if your point is that avoidance of holes reduces difficulty, then I would say that it is contextual, because in my case it increased the number of lines, but if one solves the problem in other ways(edges tracing), it is easier in those approaches.

That's pretty unfair...

Why?

If so, you have to provide an example with that at the beginning of the description

I will do...

IMHO drawing only outer borders is more interesting.
If you want to draw all borders there is the (simpler) draw th borders II.

Thing is, it feels like you're mixing too much stuff in your kata (plural). Like, adding perf requirements to enforce a specific kind of algorithm while nothing is told about what you expect, that the descriptions (currently) do not make stand out the differences clearly enough so that the user can actually spot what you want.

Currently, I feel like I'm poking in the dark, when you're talking about different kind of algo for those tasks. I don't know any specific kind of algo for these tasks. I just build them out of my mind. So I could use any kind of approach, using only variations to solve each of them and I doubt there would be different time complexities for those. So I really don't follow your train of thoughts.

What are the time complexities of those alogrithm you talk about? Are they actually different? The very least would be a hint about waht you expect.

There isn't a specific algorithm for border drawing, and in this kata there are 3 solutions with 3 diffrent algorithms.

Different kata requirements may restrict the choice of algorithm. If there is a common algorithm it's a single kata (unless the algorithm is 90% of one kata and 10% of the other).

In this kata the main problem is avoid holes (which exclude some simple algorithm), in the second kata the main problem is speed (which exclude more complex algorithms), in the third is ... (top secret).

In general the choice of algorithm is free, in the second kata it's more forced, but in a performance kata it's normal to require the fastest algorithm and/or some micro-optimizations.

May be useful to have a comparative table in description?

from what you're telling, there shouldn't by any perf requirement for the present one, so.

from what you're telling, there shouldn't by any perf requirement for the present one, so.

There aren't performance requirement.

There is the default 12 seconds timeout, but it shouldn't be a problem. Reference solution complete all tests in 120 ms (lesss than 2 s including startup and test case generation).

Maybe change the title to Test contraints ? x)

Description updated.