[Community Puzzle] The helpdesk

Puzzles
#1

Coding Games and Programming Challenges to Code Better

Send your feedback or ask for help here!

Created by @jddingemanse,validated by @Razovsky,@Timinator and @iggy12345.
If you have any issues, feel free to ping them.

#2

I was not able to pass the 5th test. I submitted and surprisingly I got 100%. I think the final submission’s tests should at least cover the open evaluation tests.

Thank you for this mind opening puzzle.

#3

I’m a bit confused about rounding in this problem. The example in the description only covers integer efficiencies but the problems contain floating point efficiencies, are we meant to be tracking fractional minutes or not?

#4

I have same problem as IIIThinkAboutIt !
When I make rounding ServiceTime all tests are passing, but 5-th validator isn’t. When do with just float variables - all validators are passing, but 5-th test isn’t.

#5

I see you mostly do your puzzles in Python. If you did this puzzle in Python, I’d love to take a look. I’ll need you to make sure your code is published. If it says it is already published, please unpublish and republish.

#6

I never do any rounding and I pass all tests and all validators.

#7

While replying to @Oliverri, I think the same issue bothers both @IIIThinkAboutIt and @cfehunter2: rounding.

Let me start with saying apologies and thanks: I simply did not think about rounding. After I get to the bottom of this, I will turn it into one or more proper edge cases. Apparently, at the moment it is a hidden edge case, popping up either in the validator or test case, and that should not be so.

But, as @Timinator already said, this puzzle should be done without rounding. I am a bit surprised by the ‘passing one with rounding, passing the other without rounding’. I am now checking the behavior of rounding vs not rounding at the point of combining helptime with efficiency → there I indeed found some edge case issues, differing on whether you round down to an integer, whether you round (up or down) to the nearest integer, whether you round up, or whether you do not round at all.

Rounding down to an integer
Checking in detail my iterations, rounding is a problem at some point for test case 5 in a situation like this: without rounding some counter has worked for 13,333 minutes and then gets another task for 6,6667 minutes. This brings that counter exactly at the 20 minutes of worktime, earning that counter a break. If instead you would round down to an integer, the counter would only have worked 13 + 6 = 19 minutes, which is not enough to earn a break yet.Since HAB likes to be fair to their employees regarding breaks (after all, Breaks is in their company name), and in that case the counter can in fact claim it worked 20 minutes instead of 19, rounding should not happen.

edit, add: rounding up and down
Besides rounding down to an integer, there is also the case of rounding (rounding up or down, depending on what the nearest integer is). In that case, indeed you pass test 5 while failing validator 5. Indeed, if you use rounding, test 5 will not be a problem, but validator 5 will be a problem. I have checked that case in detail, and found the following for validator 5:

  • Without rounding: for one counter (lets say counter A), progress over the working day are 40/0.75 -> 53.333; +10 -> 63.333; +10/0.75 -> 76.666, while at the same time another counter (counter B) works itself through 40/1.25 -> 32; +10 -> 42; +30/1.25 -> 66; +10 -> 76. There is a point in the day (at minute 76), when a visitor needs to choose between one of those counters, and will go for counter B, since counter A comes available 0.666 minute later.
  • With rounding: counter A would instead move like 53 -> +10 = 63 -> +10/0.75 = 76. Now counter A and B seemingly come available at the same minute, and the visitor will then go for counter A, because that one is lower in number than counter B.
  • Also in this case, HAB is fair: counter A has in fact worked 76.666 minutes at that specific point, so counter B with ‘only’ 76 minutes should take up the task at that specific point. No rounding!

edit 2: rounding up
With rounding up, there is the special (especially unwanted) situation that you pass all validators, but fail test 5. Thank you @IIIThinkAboutIt for publishing your code - this is the case for you. Below the details of test 5.

  • Without rounding: for one counter (lets say counter A) from minute 110 of the working day, progress is as follows: 110; +20/1.5 -> 123.333; +10/1.5 -> 130.000. There is also another counter (counter B) that ends up available at exactly 130 minutes. At minute 130, the next visitor in line will go for counter A.
  • With rounding up: counter A will move like 110; +20/1.5 -> 124; +10/1.5 -> 131. At minute 130, counter A is seemingly not yet available, so visitor will go for counter B instead.
  • Also in this case, HAB is fair. At minute 130, in fact two counters are available; counter A is not allowed to pretend having up to minute 131 by rounding, but should honestly be ready to help the next visitor. No rounding!

In any case, I have added to the statement that you should not round at all. I hope that solves all questions - on the small chance that not rounding at all for some reason (maybe in other languages) gives other behavior, I will revisit this point. Also, I might split test/validator 5 into multiple cases, dedicated to the different problems of rounding down, up or both. If I alter any of the cases, I will make sure that it will not break solution code for anyone currently passing all tests and validators.

#9

I saw this thread and decided to check it out for myself.

  1. I liked the puzzle, easy, but not trivial. Thanks to the author for the work.
  2. Didn’t meet problems with rounding.
1 Like
#10

@Oliverri You may publish your solution in the IDE area if it has passed all the validators, or PM your solution to the author directly. Please do not post your code on the forum. I’ve deleted your post. Thanks.

#11

It maybe does not look good if I have a question on my own Puzzle, but it is what it is;
Question to full-stack developers / people using other languages than Python:
I only know Python. Is there a possibility that the not-rounding in Python leads to other behavior than not-rounding in any other programming language? In other words: might it be possible that at this moment, this puzzle works for Python, but not in all programming languages?

#12

@jddingemanse You can be calm, the programming language has nothing to do with it. I’m not solving in Python. Who does not succeed - most likely the usual errors in the algorithm.

#13

I should note that I did pass this in the end just by using floating point minutes. I think if you were to use an efficiency with a fractional result in the example then that should remove any confusion.

#14

Phew, thanks!

I’ve added it in the last sentence of the statement (that 15 minutes with efficiency of 2 leads to 7.5 minutes). The fact that efficiencies itself can also be floats/fractional should follow both from the input instructions and what players will encounter in the cases.

Furthermore, announcement on a change in the puzzle

  • I moved validator 5 to test 6, and added as validators 5 and 6 cases that show similar behavior to their test with respect to rounding. If you follow all the rules (including not rounding), you should pass all tests and validators. In other cases as discussed above (any kind of rounding), you will either fail test/validator 5 or test/validator 6 (or both).

Thanks a lot to all of you for your quick feedback!

#15

I’m trying this one in C++, applied no rounding and only fail test/validator 5

As the terminal output on here is truncated, I’d probably have to run it in an offline IDE to analyse where this breaks.

#16

@jeetee can you paste here what your output for test and validator 5 is?

In general, test/val 5 and 6 are edge cases with respect to rounding: test/val 5 fails if there is rounding (up), test/val 6 fails if there is rounding (down). I’m not familiar with C+: might there be some unintended rounding going on if you use particular variable types?

#17

Here’s my output for 5:
4 3 4 6 9 4
3 2 1 4 5 3

I’m currently using single precision floating point numbers to track time. I’ll try with doubles mlinstead, though I doubt this is due to a precision rounding error.
Much more likely that I messed up assigning the next available counter to the next visitor -_-’

EDIT: Solved!
Apparently it was a precision rounding error on the single floating data type; changing it to double precision made it pass :slight_smile:

#18

Ah good job! Indeed something rounding-related seemed the most likely reason given that you passed all other tests/validators. I think it is hard to have a wrong visitor-assignment that passes all those except five.

#20

Hello,

I’ve went through all tests.
even if i had some difficulties for to avoid break on the same time the last visitor starts being served on tests 4 and 5). I made it work with seems solid add on.
However trying the validators, I have validators 4 and 5 ko. May it is linked but I’m quite surprised being ok on both tests and ko on equivalent validators.
Could anyone give me some indication if any specificity would appear in those validators ?

Thank you !

#21

Hmm that’s annoying. So you pass everything (including test/validator 6), except for validators 4 and 5?

The issue I wanted to test in test/validator 4 was the fact that someone goes home without taking a break right at the moment his break would start; that is happening both in test and validator 4 for counter 1. The only difference is a third counter with its own extra visitor in the validator case, and another helptime for the final visitors - but behavior until breaktime is exactly the same (counter 1 works exactly up to breaktime, and then goes home, while counter 2 works, takes a break, and helps another one).
Validator 4 IN:

20
3
1 2 0.5
4
30 40 15 15

Validator 4 out:

1 2 1
0 1 0

As for test/validator 5, the only difference between test and validator is the helptime of two of the customers, because of which two counters have a slight difference in number of breaks and number of visitors helps. So, I am curious how your code passes all except those two validators.

If you are coding in Python, you can share your code through PM with me if you want, then I can have a better look.

#22

ok seems I had an issue on one of my list generation on validator 4.
Anyhow it has only solved the validator 4, the 5th is still failing an other issue…
I keep chasing the other bug…