[Pharo-project] [Slightly OT] Integers smarter than me today
bschwab at anest.ufl.edu
Thu Feb 11 22:12:21 EST 2010
I will try your test, subtract+negate algorithm.
On extending the highest bit, what is the reason for stopping at 16? I thought of something similar, but assumed I should cover all bits used in representing a small integer??
From: pharo-project-bounces at lists.gforge.inria.fr [mailto:pharo-project-bounces at lists.gforge.inria.fr] On Behalf Of dpharris at telus.net
Sent: Thursday, February 11, 2010 8:00 PM
To: Pharo-project at lists.gforge.inria.fr
Subject: Re: [Pharo-project] [Slightly OT] Integers smarter than me today
Assuming these are 12bit signed numbers, then I think the answer is that you should extend the 12th bit out to the 16th bit position. The conversion should be 0..2047 (0x000..0x7FF) => 0..2047, and 0x4095..0x2048 (0xFFF..0x800) =>
-1..-2048. So, it is probably easier to keep the numbers less than 2096, and
for those those bigger than 2047, subtract them from 4096 and negate.
Quoting "Schwab,Wilhelm K" <bschwab at anest.ufl.edu>:
> Hello all,
> I am trying to make a recognizer for a communication protocol that has
> very likely been errantly documented. Such tasks can be difficult
> enough with good docs, but I'm not even sure what is supposed to be
> happening, so it is really interesting.
> One of the things that I **think** is happening, is that 12-bit two's
> complement data is included at one point in the stream. The bits are
> spread over a 16 bit word. Let's assume that I can correctly gather
> the 12 bits together. Could some kind soul suggest how to go from the
> resulting SmallInteger to the correct signed value? Smalltalk is
> adding a wrinkle that I am not sure how to handle: should I set the
> "missing" bits to 1? Out to bit 31?
> Any pointers/suggestions would be greatly appreciated.
> Pharo-project mailing list
> Pharo-project at lists.gforge.inria.fr
Pharo-project mailing list
Pharo-project at lists.gforge.inria.fr
More information about the Pharo-dev