It's Cody's 5th birthday, and you've been tasked with putting the candles on the cake. Your goal is to maximize the distance between the 5 required candles.
Given a rectangular cake with specified length and width, return the highest possible minimum distance between any two candles.
Important notes
The Test Suite has the highest minDist as 16 for a cake of size 16×32, but I am getting 16.564. Likewise for a couple of other sizes.
Thanks for the feedback, David. You are absolutely correct. I will fix the test suite.
Ok, I have updated the result for tests 3 and 7. Also, I changed the requirement from 3 decimal places to 2 so that minor discrepancies aren't as big an issue. Please let me know if you catch any other errors.
Thanks. I think it's all good now :-)
well, this was harder than I was anticipating :)
It might be advisable to include additional test cases to avoid hard-coded & non-general 'solutions'. Some additional cases are reported in Solution 1299656.
I second David's suggestion
I agree, David. I'll expand the test suite today.
great! one suggestion would be to add some cases with cake sides ratios between .45 and .55 but different than .5 to avoid solutions that hard-code the .5 case? (e.g. birthdaycandles(5,11) = 5.5204 ; birthdaycandles(12,23) = 12.2028). The behavior in that range seems most interesting, as the solution space seems to transition smoothly between the two "stable" configurations
Done. Thanks for helping me refine things further, Alfonso.
The last two cases have a solution of 258.83 and 517.65, I am getting 258.82 and 517.64 respectively. Is this intended and I am wrong? or is it just numerical roundoff?
I agree with Daniel Turizo that the round-off is wrong for the two last cases. I had to introduce a fudge factor of 1.00003 to get the value in the test suite, even though I use an analytical solution.
That right. I am also using an analytical solution and I had to introduce that ugly 1.0003 factor too.
Daniel and Are, thanks for the input. I modified the requirements so that the player should not need to round to 2 decimal places anymore. The "correct" answers now have higher precision, and a solution's answer must be within a tolerance of 0.01. With this format, you should not need the fudge factor you were using (either way, at least one of your submissions should work!).
I am getting 517.6381 for test #23 (same value using algebraic formula or 1d optimization) compared to the testsuite 517.6500 value, could you please double-check?
Good catch. Test suite updated.
New tests will be added to make this hard-coded solution obsolete.
почему b = 2 * wid - sqrt(3) * len / 2;?
Not a general solution.
yeah! I've done the same... ))
Not a general solution.
Seems like a general approach to me, but the boundaries are not correct. I found it easier to calculate the three options, and then pick the worst.
Fair point.
Good insight in your formula for the first case of your if statement.