Re: RBB: Really Big Bitvectors

From: Paul Cole (
Date: 12/09/95

On Sat, 9 Dec 1995, Ian Macintosh wrote:

> On Sat, 9 Dec 1995, Paul Cole wrote:
> > Now for the method that does work but is highly proprietary.
> > But close inspection would show that you can use a mere 2 bits for these 4
> > values becuase RUNNING is only possible when you are WALKING and DIVING is
> > only possible when you are SWIMMING. Also, I note that WALKING is the same
> > thing as NOT FLYING. So you could <though I don't, too much work> use 2
> > bits to represent this. 
> > 
> > XY where
> >     X -- 1 = SWIMMING, 0 = WALKING
> >     Y -- 1 = DIVING,   0 = RUNNING
> >    01 = NOT SWIMMING and RUNNING
> >    10 = SWIMMING     and NOT DIVING
> >    11 = SWIMMING     and DIVING
> > 
> > Thus I've just implemented all 4 STATES in 2 BITS.
> > 
> > This is very proprietary and imho, not terribly useful.  It is only 
> > presented here as a method for representing more than X FLAGS in an Xbit 
> > bit field.
> That is not proprietary.  I was using logic like that back in 1981.  To
> lay a claim of 'proprietary' on that is ludicrous in the extreme.  I was
> not the only one doing that type of logic either, as I recall seeing it in
> an old accounting system written to run on the TRS-80 model I. 

I didn't say copyrighted.  By proprietary I mean its not generic.  You 
just can't throw that kind of logic mangling on top of any ol' set of 
flags you want.  It depends entirely upon which flags are being used and 
what their purpose is.  Where the current system doesn't give a darn what 
the flags are nor what their purpose is.  Maybe propreitary implies more 
to you than it does for me.

Another example of a proprietary system is my nifty keen Teac Quad speed 
cdrom drive.  Its interface is proprietary.  You can't use microshafts 
MSCDEX.exe driver on it which made the linux support for the drive just a 
tad delayed. By proprietary in that case did not mean that no one but 
Teac could develop software for the interface, just that the interface is 
not normal and would not work with any other drive.

In my case, I meant that a bit vector implementation based on the above
working example would be proprietary in that you couldn't take world files
or bitvector code from a mud using it and port them to another mud
without a lot of work that wouldn't be necessary if they used the generic

I failed to add this to my original post, I still feel that by far the 
best method for single variable long bit fields is the bits stored in 
character strings method posted a few months back. The downsides of that 
method are that you can't test more than one bit at a time, and each bit 
test adds 2 extra multiply related instructions < a modulo and an integer
divide/multiply> which comes out to 4 extra cpu cycles per set/test.
Not too terribly much.

> Your comments on bitfields, etc, is however, highly correct.  Perhaps you 
> could add that when viewing a situation where any combination is 
> possible, it is in reality a permutation.

I dunno what to call it officially.  Unofficially in my world I call the 
2nd bit a keyed representation.  The 2nd bits meaning is keyed to the 
first bit.

I also failed to summarise the reasons why mathematical massaging will 
ultimately fail <I think>.

  1) decoding will be ambiguous 
  2) encoding will overflow

 > 	Ian.

  --Paul Cole

This archive was generated by hypermail 2b30 : 12/07/00 PST