X-Authentication-Warning: delorie.com: mail set sender to geda-user-bounces using -f
X-Recipient: geda-user AT delorie DOT com
Message-ID: <53373DEA.5070605@buffalo.edu>
Date: Sat, 29 Mar 2014 17:40:58 -0400
From: "Stephen R. Besch" <sbesch AT buffalo DOT edu>
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20100101 Thunderbird/24.2.0
MIME-Version: 1.0
To: geda-user AT delorie DOT com
Subject: Re: [geda-user] Wav to C array ~ 16 bit to 12 bit
References: <CALSZ9gpoxnz9V-CbisKqmdwQyTtVf6G9nCe2Wt=4p4su-afFBQ AT mail DOT gmail DOT com> <201403291603 DOT 19284 DOT ad252 AT freeelectron DOT net> <53372E3F DOT 1040704 AT buffalo DOT edu> <201403291648 DOT 16993 DOT ad252 AT freeelectron DOT net>
In-Reply-To: <201403291648.16993.ad252@freeelectron.net>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-PM-EL-Spam-Prob: X: 10%
Reply-To: geda-user AT delorie DOT com

On 03/29/2014 04:48 PM, al davis wrote:
> On Saturday 29 March 2014, Stephen R. Besch wrote:
>> On 03/29/2014 04:03 PM, al davis wrote:
>>> On Saturday 29 March 2014, Stephen R. Besch wrote:
>>>> realizing that I had forgotten
>>>> about the sign bit it became clear that you cannot just
>>>> toss the high  bits - you need to toss the low bits
>>>> (essentially an integer divide by 16).
>>> Usually if numbers are small enough, you can toss the high
>>> bits.
>>>
>>> "Usually" means the usual two's complement representation.
>> True enough as long as they are all positive. With signed
>> data, you  really have no choice but division of some kind
> True even with negative numbers, assuming the usual "two's
> complement" representation.  Even with other representations the
> conversion is usually simple.
>
> If the number is "small enough" and positive, the high bits are
> all zero.  If negative, the high bits are all 1, and after
> tossing the high bits are still all 1.
>
>
How sloppy of me not to have noticed this!  But nevertheless, simple 
truncation of the high bits is still data dependent, whereas rescaling 
by floating point division is not. Still, I agree with you completely in 
the case where the high 4 bits are all either 0 or 1.

-- 
fictio cedit veritati