给定N，找到添加的最大*奇数/偶数*数来得到N.

Question

I'd like to ask a follow-up question base on this one: Given n, find the maximum numbers added to get n

What if I can only use odd numbers to sum up N. Is there any formula to generalise it? Thanks!

eg Given 7, ans is 1, for 7 Given 16, ans is 4, for 1+3+5+7 Given 13, ans is 3, for 1+5+7

Answer 1

I'm going to propose code that solves your question, then attempt to prove/defend it.

  public static int maxOddSumToInt(final int n) throws IllegalArgumentException {
    if(n < 0) throw new IllegalArgumentException("n must be positive");

    LinkedList<Integer> currentNums = new LinkedList<>();
    currentNums.add(1);
    int sum = 1;
    int next = 3;
    while(sum < n) {
      currentNums.add(0, next);
      sum += next;
      next += 2;
    }
    while (sum > n) {
      int r = currentNums.remove(0);
      sum -= r;
      while(sum < n) {
        currentNums.set(0, currentNums.get(0) + 2);
        sum += 2;
      }
    }
    return currentNums.size();
  }

The key of your problem is that you just want the count of the most unique odd integers summing to the target. Thus it doesn't matter how we arrive at that maximum count, just that we are sure that we have it.

The fast track to using the most numbers is to use the smallest ones possible. Thus we would want to use 1,3,5,7,9, ... instead of 1,9,15, for example. Thus, the first step is including as many numbers in ascending order as we can, until we hit or exceed our target. If we hit it, great! That is by definition the maximally sized set of numbers to use, because there are no smaller numbers left available. For example, for the input "9", the algorithm will add 1, add 3, add 5, see that it hit 9 and return the size 3.

If we exceed the target, we remove the last addition, as this clearly made it no longer possible. By similar logic to above, this means that any set of the size we were at ( n ) won't work, as we had the minimum summing set before and even that was too large. Thus we try sets of size n-1 . From here, it doesn't matter how we try to get to our target, just that we check to see if any set of size n-1 works. Thus for simplicity we increase the most recent addition by 2 repeatedly to see if we hit the target. This both ensures that we aren't repeating a number (we are making the largest one larger, thus it isn't possible for it to become a duplicate) and that if we exceed to the target again and need to repeat this step, we can do one removal and certainly drop below our target again.

Total time complexity is a bit tricky. I think I can claim that it's O(N^2) at the very worst, where N is the value of the target. The worst case scenario is that the number can only be represented by itself (a set of size 1), so we build a set summing till we exceed it ( O(N) ), and remove each while incrementing till we exceed again ( N*O(N) ). There may be a tighter bound based on number stuff, but not off the top of my head.

The one thing the algorithm doesn't do is gracefully handle invalid inputs. If you give it a number that doesn't have a solution it will run forever. If you can figure out a simple numeric test for this you can just add it to the illegal argument exception at the top.