I read it that way anyway - had to go back to see what you REALLY wrote ;)

Proposition: leave it like that, but add a flag "sum_to_100" with the restriction that each value can't be more off than 1%. But then testing might get a nightmare, as you'll get different algorithms "cutting" different values... Ouch, the problem seemed so simple!

putting it back in beta is what I meant to say

These are good points. I think this kata came out of beta prematurely. It was supposed to be a pretty simple kata but edge cases are getting out of hand. I'm putting it back so that it can be polished a little bit. Please provide any suggestions you may have about how the description and test cases can be updated.

Sorry to auto-reply: in fact you have more examples and sometimes it's not even enough to only adjust the last value (except if you accept negative numbers, which is another thing that is not stated in the description...)

Take 40 times the same value, you get 2.5, rounded you get 3, times 40 is 120... So if you adjust your last value, you get -17...

What does

all percentages should add up to as close to 100 as possible using only integers

really mean?

• are negative values allowed?
• is it OK if the sum is > 100?
• is it OK if the sum is < 100?
• by how much each value might be off to correct towards a total of 100%?

Then again, this could all be said as over-engineering, as the task at hand was supposed to be very simple, but with all corner-cases, this gets nearly to a 4 kyu kata ;)

In fact I think that the only case where that happens is if you have n times x.5, which can only happen for 8 arguments, given a 100%-goal - as all other number of arguments won't give you a x.5, is that correct?

First I wanted to write that you're wrong, but now I got an example where you're right ;) - if you give

{:a=>10,:b=>10,:c=>10,:d=>10,:e=>10,:f=>10,:g=>10,:h=>10}

you get

{:b=>13, :f=>13, :c=>13, :e=>13, :h=>13, :g=>13, :a=>13, :d=>13}

which is of course wrong, because the total is now 101!

OK, updating this code ;)

Good catch. I updated the test cases to check for case where the underscore shouldn't be added. We will mark this answer invalid (once we build the ability to do that...)