RE: odd sort of bit-counter...

> -----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