Bruce...that's quite a few checks. My computer is at 27,000,000 right now. For the fun of it. I'll let it keep running. The way i'm running it is I have the code stored in a database and load it into the before processing.

>>Jay, Most of the discussion is frankly above my head. I've run the program on several small datasets with perfect results in just seconds. Now I'm running it on a real dataset. I've created a test target that I know is valid. My real dataset has 70 numbers. The time to calculate has increased exponentially as it should. the program is running right now and already I'm up to 3,000,000 iterations of the main loop. I'm no statistician but I think something has gone arwy. I'll let it keep running for the fun of it. Thanks for all of your help...Marvin
>
>Hi Marvin, got your reply on my other post - but I think Jay's code is fine - it looks very much like mine, the only difference being that I used table instead of array - but no big deal on that difference.
>
>I think what you are seeing is *reality* with your real data running, unless there is a numeric overflow and the prg gets lost somehow. Here is another bit of math, but not too heavy, don't worry:
>
>The number of combinations to check is the binomial coefficient sum, which sounds bad, but all that means is this:
>
>When you have n data items, you will have 2^n - 1 sums to check. So, for
>
>n=4, there are 2^4 - 1 or 15 checks.
>
>n=10, there are 2^10 - 1 or 1023 checks
>
>n=70, there are 2^70 - 1 or 1,180,591,620,717,411,303,423 checks
>
>That is getting to be a large number of checks! This might be time to look for mathematical optimization, as Steve and I were discussing. That just means to look for ways to abort/eliminate some loops, say by using the target value's size, might be one way. Splitting the prg up into modules to only run part of the checks at one time may be another. Runtime reduction may be vital, in fact, with so many checks to do.