RE: finding differences in a list of amounts

["Joe Pluta" <joepluta@xxxxxxxxxxxxxxxxx>]

Actually, it might not be totally awful if the number was manageable.  I
believe you can multiply two arrays (I haven't tried, but I think you
can).  So let's say you create three arrays of the appropriate size to
hold all your records (I'd do this manually, based on the number of
records... you'll see why in a moment).

The first array I would load with all the amounts from the file.  One
time read and load.  The second array I would start with all zeros.
Then I would call a function that would do a sort of extended binary
addition.  I would add one to the first element of the second array.  If
that element goes to two, set it to zero and add one to the next
element.  Repeat until you hit an element that doesn't carry.  This will
set your second array to a unique combination of ones and zeros.

Multiply array one by array two to get array three.  Sum (XFOOT) array
three.  If the answer matches your target, you have one possible
combination; print it out.  Jump to step two and repeat.  Do this until
the second array is all ones.

As I said, I'd preset the array size to the number of values to be
processed.  I think you can do this easily by creating a constant in the
beginning and using that constant to DIM your arrays, and then set that
constant to the number of records in the file.  You could probably do
this programmatically and then compile the program.

As a further reduction, if your values are all positive you could run a
query over your database to get a count of only those records whose
value is less than the target, and then skip the records whose value is
too large.

Joe


> From: Dan Bale
> 
> Well, see, that's just it.  I've done this manually numerous times in
my
> career.  It's just that it's a *very* monotonous task, especially when
> looking at hundreds, if not thousands of detail amounts.  I would
think
> this is a very common problem.  Is there a name for it?
> 
> I have the detail in a file, so if there was something to try every
> possible
> combination to see if it would add up to the total amount I'm looking
for,
> that's what I would use.  Brute force, if necessary, even if I have to
let
> it run overnight.  I'm not even sure how I would define an algorithm
to do
> it.