> -----Original Message----- > From: mi400-bounces@xxxxxxxxxxxx / Joe Pluta > Sent: Monday, September 20, 2004 2:08 PM > > How about this? > > Do a preprocess. Set up array two and start shifting it as I explained. > Each time you do a shift, do an XFOOT. This will get you the bit count. > Do a MOVEA to get the bit pattern, then add the pattern and bit count to > a list. > > What kind of list depends on the number of entries. You might be able > to use an array for small numbers; I'm not sure what the max on DIM is. > Remember that the number of entries required is the (2 ^ (number of > values)), and that number goes up quick. Personally, I think you could > probably use a data file instead, because you could preload it. 100 > values would require about a million entries, each about 100 bytes long > (plus the bit count). > > Then, process the list based on the bit count. > > It's a thought. And a good one. Cuz I thought of it too! <g> If this were something I'd doing on a regular basis and disk space was not at a premium, I can see where the file you & I are thinking about would make sense. Still a problem of how to incrementally lay out 100 "bit" values. I.e., programatically-speaking, what comes after binary '11010111'? BTW, 100! = 9.3 e+153 = the number of any possible combination of a list of 100 elements. Were you thinking of a different value? I think I've got a plan. It's being turned into a free-time exercise so I won't play with this until an evening this week. Thanks for throwing out ideas, Joe (and others)! db
As an Amazon Associate we earn from qualifying purchases.
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.