closing, as this would be a suggestion anyways, not an issue. there are ways to properly free all of the memory in a standard-compliant way, and without using global variables.

If the frequencies resemble ascending powers of two, one would expect the encoding to have an ideal representation (i.e. code length matches the frequency).

      ... 8
     /   \
    /     \
  ... 4   c:4
 /   \
a:2 b:2

If you build a tree, then all of the previously added elements frequency sum is the same as the frequency of the next element. Thus the new root node should have the previous tree and the new leaf as children. The length of the encoding then is the same as the depth of the leaves, and this way it is validated.

If this test fails, then something with your algorithm is broken.

"...the idea is to substitute the examples into the formula and reduce the resulting equation to one unique term. ...Using this pattern, only one solution is possible for each test..."

But hold on! The uniqueness of solution is disapproved by the example in the description itslef: [ "a + a = b", "b - d = c ", "a + b = d" ]. The expected answer is '2a', however '1b' (or just 'b' - what a strange requirement for explicit 1!) is also a correct answer and it is simpler than the expected one!

Need to revise the kata for either accepting all possible single-term answers (the preferred approach), or making the rules more specific.

About the diagram: [0,7] is the starting position of yellow blob, size 5. This is given in line 6 of sample tests and diargem T0 shows it correctly. After the fist move the blob has relocated to [0, 6], so the print_state should get it as [0,6,5], correpsonding to line 17 of sample tests, and diagram T1 shows it accordingly. I don't see any faults.

About the wrong result: since no fusuion is involved here, I guess, you have a silly mistake in the code, chaning the size instead of a coordinate. What I've got (as probably all others) matches the expected result.

I actually suggested that to the author to be consistent with the input/output capabilities of the original implementation. Makes me wonder whether there could be more done on the more modern Node.JS implementations.

Actually it wasn't misunderstanding. Just a silly mistake in the code

Seems like you're misunderstanding the task. The encoding your algorithm comes up with is terribly inefficient and I'm assuming that's the reason the tests are failing.

"the higher frequencies are, the lower the length of their encoding should be (can also be equal for non-powers of 2)"

Why powers of two should make the difference?

For the frequencies [('b', 2), ('e', 2), ('g', 4), ('i', 8), ('m', 16), ('n', 32), etc,
my Python code gets: b: 000, e: 001, g: 010100, i: 010101, m: 010110, etc.

So, 'g' has frequency 4 (2²) and code 010100 length 6; 'i' has frequency 8 (2³) with code 010101 also length 6. Both frequencies are powers of two, have same code length, but I don't see any problem with that, as there are no frequencies between 4 and 8.

Solved in Python without problems. However in Java this is a real nighmare. For some reason (rather illogical to me) the task wants the result (as an option) to be also placed in provided output stream. But how it should be placed: just bytes, or DataSteream.writeCharts, or DataStream.writeUTF - no clue. Whatever I do it, fails.

I really do not understand the logic here ...

If you mean the logic behind the decision to change the behavior: mostly it's related to difficulty of collecting feedback and opinions. On one side, I like the current version, and I would like to keep it (duh, I wrote it after all). On the ther hand, users sometimes complain. Granted, not much - it happened like two or three times since the translation got approved. Difficult part (at least to me) is asking for opinons and getting answers: Codewars discourses are not really convenient (or, at least for me they are not, as I prefer direct chats much more). That's why after getting feedback from a single, very experienced user who seconded the confusion of other solvers, I got convinced that the change in interface to add one additional argument would be good. I don't like it, but I might not know everything. Now, you two say that it's good. Considering your opinons, the setup would stay as it is.

The difficult thing with C is that usually it has to be very precise w.r.t. expected allocation schemes. I hoped that the setup used here would allow for greater flexibility and a richer thought process when solving. Nice thing is, many users got it right. Bad thing is, it might be against good language practices. If it is or not, I am not to decide because there are other, smarter, and more experieneced people to know.

About preserving solutions: you are right that a blue kata is usually interesting enough to have solutions preserved, but I think only if it is good in general, and not fundamentally broken. If solutions are based on a fundamentaly invalid premise, and if the idea behind the setup forces users, without a good reason, violate a practie commonly recognized as correct, then I believe quality is more important than solutions. Is it like this in context of this kata? Initially I thought it's a good setup, then I got convinced that it might be plain wrong, now there are your opinions that it's not bad. Damn. Decisions are difficult, and things are never black and white.

I have no good conclusion for now. I like the current setup. You two guys like this setup. Large amount of users who managed to get the allocation correctly seem to support the idea of the setup. Three solvers complained on the setup. One very experienced C user said they don't like it because it's not clear enough and overengineered/confusing/artificial.

I don't have time to review the setup at the moment, so even if I were to change it, it would not be soon. But when I will get to this item in my queue, I will definitely account for all data I have and try to base my decision on this. If I were to do this today, I think I would say "I don't know" and leave things as they have been until today :)
But I think something would need fixing anyway, I am not sure whether the idea of the constness of the buffer is correct.

PS. thanks a lot for your opinions, to me they are very valuable to know whether things need improvement, and how. It would be great if Codewars made getting such opinions easier, in some way. Currently it works quite well in beta kata, but I think not that good for approved kata.

If the parameter is added after the pins, like so:

void free_pins(const char ** pins, size_t n_pins);

old solutions will still work (as if they ignored the extra argument). This relies on UB and on the calling convention of the underlying architecture, of course.

I also think it's a bit disrespectful to solvers to make a breaking change on a high level kata after this much time has passed since approval of the translation.

• Is there a middle way possible with backward compatible gate for old solutions?
• Is the change really that important?

Why break existing and valid solutions to a 4-kyu kata ? The de-allocation function makes sense as it is and as you said there are several allocation schemes that do not require global variables. And if the users do not come up with one of these, they can still use the global variable technique, the tests suite allows for that. What is the issue to fix here ? If anything, it will make 'naive users' think outside of their preconceptions. This is 4-kyu after all, C users are supposed to be comfortable with memory models at that level. I really do not understand the logic here ...

Of course, for this kata you can store the size and use in for freeing. However, in general this is not a good practice, as the module can be called several times and even concurrently. Therefore it appears logical to me that the calling function should handle that.

Well of course, no arguing here. and thats why a user has to write both functions in a way which would ensure this. And this is possible, and not overly difficult, with the current state. There is no requirement to use global variables, and global variable is a problem which you introduced into your solution. There are other ways to achieve the goal, you found one, theres more, and some might even require no overallocation and a single allocation. Its doable in a standard-compliant, portable way, in more than one way.

Having said that, I discussed your point with other users and it was explained to me that solvers might have difficulties with coming up with some nice allocation scheme and adding the parameter would make it easier for users who want to use the naive(and IMO far from good) solution. I decided I will change this I will consider changing this (and some other things, like constness of some values) to make things easier for users who like chopping memory into single transistors :) I will Possibly, I will add the parameter when I get to this kata in the queue of kata to fix :)

Of course, for this kata you can store the size and use in for freeing. However, in general this is not a good practice, as the module can be called several times and even concurrently. Therefore it appears logical to me that the calling function should handle that.

My work arround was placing NULL pointer at the end, so I loop until NULL is found. It's better than storing size, however I don't really like even that.