[Community Puzzle] Panel count

Coding Games and Programming Challenges to Code Better

Send your feedback or ask for help here!

Created by @dolmen1234,validated by @jddingemanse,@etig and @TBali.
If you have any issues, feel free to ping them.

I was surprised to see that in at least one validation test, there were multiple people with the same name, and they had to be treated as separate people (i.e., there was no identifier unique to a person). It turned out the names are completely superfluous and irrelevant to the problem. It might be a good idea to at least note in the problem statement that names are not unique.

Otherwise a very nice problem for easy level.

2 Likes

:wave: Hi to all and thanks @dolmen1234 (and validators @jddingemanse,@etig and @TBali) for this very interesting Puzzle.
→ It’s a good exercise (or review) about Dictionary usage => Good job :+1: !
Bye and good luck to all : have :sun_with_face: sun, :dark_sunglasses: fun and :keyboard: CodinGames :wink: …

1 Like

It took me a long time to understand this, it should be clearly explained…

@dolmen1234, can you do it please ?

Nice puzzle otherwise.

1 Like

Given that two persons (@sammck, @Statisticiah) react to the issue of non-unique names, my reaction as approver:
I ran into the same issue while approving this contribution. However, in my opinion it just adds an extra challenge to the puzzle - it forces you to do some debugging and error finding. While it is not explained in the statement that it is possible to have duplicate names, it is also not stated that this is not the case. I think it is fairly common for contributions to have edge case surprises waiting for you in later cases.

It took me some time to find and solve the error - but it was (in my case) a good reminder that python cannot have duplicate dictionary keys :upside_down_face:.

Doesn’t the visible “Formulas repeating” test also feature non-unique names?

Also, for most of the time, there shouldn’t be situations covered in validators but not covered in tests, and situations = general aspects and not minute details. I would regard non-unique names as falling into the category of general aspects.

@5DN1L ; I’m not sure I fully understand. Your point is that there is a problem here or not? The non-unique names is both appearing in the test and the validator indeed - if it would only appear in the validator, it would be a problem, but that is not the case here. I do agree non-unique names is a general aspect rather than a minute detail (or, rephrased: it is something your code should certainly take into consideration).

My point is there doesn’t seem to be a problem with this puzzle, yet when sammck and you write about it, you both seem to imply that the non-unique name situation appears in a validator only, but not in a visible test, and that makes me confused.

And oh… maybe you write “validator” when you mean “approver”…

1 Like

Ah I understand the confusion. Edited my post to write ‘approver’ instead (though, at the start of this thread, it states ‘validated by…’, making me a validator :upside_down_face:).

1 Like

Hi there,
I added the repeating names on purpose : the test cases were designed so that each one adds a new feature and requires a more complex solution.
I thought this would give more fun that frustration.

1 Like

And no one mentioned that for some reason the formulas used properties that were not in the original list of personality properties. It is extremely unclear why this was done. The description of the puzzle is composed in such a way that you cannot conclude that there may be unknown properties in the formulas, and only after you run the tests and catch an NPE - you understand that the author of the puzzle is a “genius”.
Having a tag (Map) and not using them is bad manners.

It was done because it is an edge case.

You don’t know what the phrase “edge case” means, but for some reason you use it.

Internet tells me: “In programming, an edge case typically involves input values that require special handling in an algorithm behind a computer program.”.

I feel like this definition applies to the test case you referred to, as your algorithm didn’t initially handle the input values and therefore required a special handling (ie - as far as I can tell - switching to using maps).

Now if you don’t give the same meaning to edge cases, it is fine. It would however be more productive to tell me what they actually mean instead of telling me I don’t know but still “for some reason” use it.

These puzzles specifically have Constraints in which you need to specify what the user will receive in the input stream.
The essence of these puzzles is solving the problem, not validating the input data.
Why didn’t you copy the text that comes after the one you copied from the wiki: “testing boundary conditions of an algorithm”.
That’s why constraints must be set to understand where THESE BOUNDARIES ARE!!!!
It must be clear, precise, with reasonable constraints…

Edge cases, for example: division by zero (when you were told that 0 is possible in the input data), or checking for going beyond the array boundaries when you look at neighboring cells.