Find the optimal shape (with Nopt sides, where Nopt is at least 3) to bring the maximum product of the sides length, given a specified perimeter.
Example: Assuming perimeter equals to 7 (p=7) then the known optimal value is Nopt=3 (a triangle, so 3 sides). let mark L1,L2,L3 the triangle sides length (L1+L2+L3=7), thus the product is L1*L2*L3 and we want the product to be as large as possible for your chosen number of sides Nopt.
Don't assume the perimeter is an integer. The side lengths need not be integers, although it is possible they might be so. And of course, you need to decide if the optimum happens for an equilateral polygon, so with equal side lengths, or if some other set of side lengths that collectively sum to p might be a better choice.
Difficulty level on a scale 1 to 10: 8
I can't get the test suite to work.
Anyone else having a problem?
I appear to get the exact same answers.
The function is setup the wrong way by default. You actually have to return a vector with Nopt as the first element and the product as the second. When he calls the function in the test suite, it will return only Nopt the way the function is originally setup with two outputs.
I have made the problem a little bit more challenging by changing only the test suite.
The propose is to get a math solution.
The leading solver has already made it.
If the purpose is to get a math solution, why play tricks with how the output needs to be passed and read?
No tricks.
Math solution is always better than brute force solution.
if you choose bruth - your solution may be limited by the number of iterations.
Sorry, I should have been clearer with my previous comment. Yes, there is a math solution to this problem that does not require brute force. Solutions 231885-231887 are mine, and give the correct (mathematical) answers with no brute forcing at all. However, because of the way the output needs to be passed to the assert function, they are marked as wrong by Cody. Other than the odd way that the output needs to be parsed, this is a great problem.
The test suite has been updated to avoid the problems mentioned by James.
I took a look at the test cases. The 4th test has a result that is expected to be on the order of 1e40. Then it compares that to the solution returned, and tests to see if the absolute difference is less then 1e-4? eps(1e40) is roughly 1e24. So the difference between two numbers of size 1e40 will never be less than 1e-4, unless they are IDENTICAL. Far better would be to test if the relative difference is small.
I updated the problem explanation to be a bit more clear. I also repaired the checks for a valid solution to use a relative test, mainly valuable for one of the cases where an absolute test on the error was a poor choice.
Clearly, the best score comes from older solvers not having to deal with singularity that occurs when p = 5, which was not included in the test suite back then.
Best solution!