BIT Counting: C programming problem

[Eric Robert Jablow]

In article <35329 at think.UUCP> barmar at kulla.think.com.UUCP (Barry Margolin) writes:
>I haven't seen anyone so far suggest the far end of the time/space
>trade-off: have a 64K table, with each element N containing the number
>of bits in N (you'll probably have to use one of the slower mechanisms
>to compute the contents of this table, but it only needs to be run
>once when writing the program and then incorporated into the program
>text as an initial value).  [Remainder deleted.]
>Barry Margolin
>Thinking Machines Corp.
>barmar at think.com
>{uunet,harvard}!think!barmar

	"Why do you hoard?"
	"Why do you waste?"
		The Inferno,
		Dante

That is a ridiculous idea.  For microscopic savings in speed, you
waste 63K of space.  Were this program intended to be a standalone
program, your suggestion might be accessible, but this program is
obviously intended to be a part of some larger project.  Certainly, 
the surrounding program will be much larger than the bitcount routine;
what if it needs 400K to run effectively, or even 640K. An extra 64K
will put most users over the edge.  Besides, more and more people are
going to multiprogramming environments, even on PCs, like Windows or
DesqView.  Then, it is vital to keep all programs as small as
possible, so that the other programs have room to work.  If you can
assure me that the speed is the overriding condition, I might accept
the 63K penalty.  But I'd hate myself for it.

-- 
Eric Jablow                      {allegra,philabs,cmcl2}!phri\
Big Electric Cat Public Unix           {bellcore,cmcl2}!cucard!dasys1!ejablow
New York, NY, USA	 	 
New address:	jessica!eric at sbee.sbcc.edu.