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.
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.
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 !
Bye and good luck to all : have sun, fun and CodinGames âŚ
It took me a long time to understand this, it should be clearly explainedâŚ
@dolmen1234, can you do it please ?
Nice puzzle otherwise.
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 .
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ââŚ
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 ).
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.
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.