Thanks, I have lots of inspiration atm, so I'm taking advantage of that to author kata's. Btw, you are free to ignore any tables or fields you don't need.

• 24  PERFORM create_temp_tables(product_identifier);
  25  WITH
  

  ⬇

  24  PERFORM create_temp_tables(product_identifier); WITH
  

• 60  cur_date = end_dates[i];
  61  SELECT
  

  ⬇

  60  cur_date = end_dates[i]; SELECT
  

Long story short, it's a problem with the ruby test library from codewars (the run_sql function incorrectly truncates the literal string in some cases).

I can take a look at it if you post your code. :)

no pain, no gain

You could use a select statement to iterate all tables and build insert statements from that using dynamic sql. I can't think of an easier way.

msg is like a print.

When you write in a code print("a\nb") you don't expect to get \n visible in the console, you expect the b on the next line. Hence print is interpreting the double char you wrote as the escaped chr(10) (iirc, it's 10... didn't check). So must do msg.

Now, the problem is that you're writting a code that sort of interprets that print statement. And there, you want the line feed to be "humanly readable" in the generated code, hence, that code is outputting \\n, so that the final compiled code actually contains \n.

Not sure this is clear... Probably not... Cannot do better, sorry. To summarize, it's about the difference between what you actually type, and what's printed from that.

I was between 3 and 4 kyu, but I'd say 4 is reasonable.

I was inspired by a 3 kyu kata on binomial expansion which was admitedly easier than this one. However, that one was severely overated.

So yeah, I'm happy with 4 kyu. I't nice to have this kata finally approved after 5 months.

Then I guess we can approve this kata. Votes are all over the place though, are you happy with kyu 4?

Creating a polynomial multiplication algorithm isn't hard (an unoptimized one, that is). So forcing one to do it wouldn't affect the difficulty much.

If one was to create a translation, it would only be necessary for the creator to make it such that even a poorly optimized algorithm would pass.

What I'm saying is that while it would increase the difficulty, it would be minor, as long as the translation creator has this in mind.

this might give a problem with translations to other languages, the difficulty level will not be the same

I do like your idea. I believe that many katas can be solved very easily through the use of imports.

In a way, this is also the case for this kata, if you consider the mathematical part of the problem to be the main one.

However, as it may be clear from the description, this kata has an enphasis on the regex part of the problem; the main difficulty is to recognize the coefficients of the polynomial by its string representation as well as produce a well-formed one as an answer.

I do believe that a very good kata could be made by forcing the user to create an O(nlogn) algorithm for the polynomial multiplication as a solution. However, I think it would take the main focus away from this problem.

Much of the kata would be significantly easier in Python, since python already has modules for dealing with generators and such.

Hi - I haven't solved this yet, but just started a notebook on it yesterday and making some early notes (I don't yet know how to solve).

But I think you are incorrect in your final reasoning: remember you are a "local" agent you don't have a global view. I think your reasoning about one pit being located at (2,0) is correct at that point, but then you say "Since I can now feel no wind at (2,1)" - this is incorrect AFAICT.

Why? At this state of knowledge you have accounted for 1 pit only. There are up to 3 pits possible in the grid. Therefore it is entirely possible that there is a Pit at (2,2) which also produces wind to its left, at (2,1), which "overlaps" the wind produced by the Pit at (2,0).

Similarly there could be a Pit at (3,1) which produces wind upwards into (2,1). Again, knowing that (2,0) is 100% sure to be a Pit does not allow you to rule out Pits in (2,2), (3,1).

A simpler illustrative example:

P _ P

in the above configuration, if you detect wind in the empty cell _, and an Oracle told you with 100% confidence that there is a pit in (0,0) (leftmost cell), according to your logic it means that the wind at (0,1) "has been accounted for", but in fact the pit (0,2) also produces wind in cell (0,1).

new solutions tab view with mine should sort this out