RE: finding differences in a list of amounts

Dan,

I'm thinking some sort of a shifting algorithm...

0000 0011
0000 0101
0000 1001
0001 0001
0010 0001
0100 0001
1000 0001
0000 0110
0000 1010
0001 0010
0010 0010
0100 0010

and so on....

When you get to 3 bits, 4 bits, ect.  You'd just (?) make multiple passes,
shifting one bit at a time.

Or perhaps, Shift the whole pattern:
0000 0011
0000 0110
0000 1100
<...>
0000 0101
0000 1010
0001 0100
<...>

Again, two bits is easy.  Three+ takes more thought, which I don't have time
for right now ;-)

But it is an interesting task, I'll be thinking about it at home tonight. 

If you have to brute force it, you might consider running the 2-bit before
spending much time validating the 3+ bit.  You may get lucky and find the
difference only involves 2 amounts.



Charles

> -----Original Message-----
> From: Dan Bale [mailto:dbale@xxxxxxxxxxxxx]
> Sent: Monday, September 20, 2004 10:17 AM
> To: RPG programming on the AS400 / iSeries
> Subject: 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
> 
> --
> This is the RPG programming on the AS400 / iSeries (RPG400-L) 
> mailing list
> To post a message email: RPG400-L@xxxxxxxxxxxx
> To subscribe, unsubscribe, or change list options,
> visit: http://lists.midrange.com/mailman/listinfo/rpg400-l
> or email: RPG400-L-request@xxxxxxxxxxxx
> Before posting, please take a moment to review the archives
> at http://archive.midrange.com/rpg400-l.
>