Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!uakari.primate.wisc.edu!crdgw1!rdsunx!davidsen
From: davidsen@rdsunx.crd.GE.COM (William E Davidsen)
Newsgroups: comp.compression
Subject: Re: Sound compression
Keywords: sound compression
Message-ID: <19649@crdgw1.crd.ge.com>
Date: 17 May 91 13:53:58 GMT
References: <16198@helios.TAMU.EDU> <19524@crdgw1.crd.ge.com> <104045@sgi.sgi.com>
Sender: news@crdgw1.crd.ge.com
Reply-To: davidsen@crdos1.UUCP (bill davidsen)
Organization: GE Corporate R&D Center, Schenectady NY
Lines: 23


In article <104045@sgi.sgi.com>, rpw3@rigden.wpd.sgi.com (Rob Warnock) writes:
|> In article <19524@crdgw1.crd.ge.com> davidsen@crdos1.UUCP
|> (bill davidsen) writes:
|> +---------------
|> |   Sorry I don't have source any more, but the way to quickly find the
|> | high one bit (on a 2's complement machine) is:
|> | 
|> |   h1bit = n & (-n)
|> +---------------
|> 
|> Sorry, this is quite incorrect! This will find the *lowest*-order one
bit set!

  You obviously read what I said, not what I meant ;-)

  Yes, my note was woefully incorrect. It turned out that for the data I
had it was quicker to find the low bit and discard repeatedly than to
shift looking for the high. I should have said more or nothing.

  There was a discussion of this in comp.lang.c some few years ago, and
for random data a binary search is faster. Sound data isn't random, at
least not in the programming sense.