RE: finding differences in a list of amounts

Whoa, Joe!  You make my head hurt on Monday morning!  <need coffee!>

But, you're right, given the time & horsepower as needed to run this, this
would work.

I think, though, that it would be best to try the two-amount combos first,
then the three-amount combos.  Does your pseudo-algorithm do this?  What you
made me think of was that if I just set up a counter, and converted it to
binary, and that binary number was spread out to that second array (i.e.,
ARR2(1) = the low-order binary digit, ARR2(2) = the second lowest-order
binary digit, etc.).  Unfortunately, when I get to a number like 63 (binary
111111), I'll be testing a six-amount combo before I exhaust all of the
two-, three-, etc. amount combos.  Typically, these type of reconciliation
errors involve a smaller number of amount combos.

So, what would be the easiest way to do this?:

00000011 =   3
00000101 =   5
00000110 =   6
00001001 =   9
00001010 =  10
00001100 =  12
...
11000000 = 192 <= Highest of the 2-digit binary for 8 bits
00000111 =   7 <= The first 3-digit binary
00001011 =  11
00001101 =  13
00001110 =  14
00010011 =  19
...
11100000 = 224 <= Highest of the 3-digit binary for 8 bits

(Of course, I'd need as many bits as the number of amounts I'm dealing
with.)
When you wrote "Then I would call a function that would do a sort of
extended binary addition" (etc.), were describing the scenario I presented
above?


> -----Original Message-----
> From: rpg400-l-bounces@xxxxxxxxxxxx / Joe Pluta
> Sent: Friday, September 17, 2004 4:35 PM
>
> 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