8+8 = 137 ??

[Rajesh.Rapaka]

Hi,
I am trying to decode the RLE 16 - bit compression using java.
So here I believe all the data is encoded in 16-bit. so even the face
number should be encoded in 16-bit. using java I am reading it as 2
eight bits A and B. Now I need to add these 2 bits in such a way that I
get the correct value in an 8-bit space.

any ideas?

Thank u in advance,
kind regards,
Rajesh Rapaka.

 

[Roedy Green]

number should be encoded in 16-bit. using java I am reading it as 2
eight bits A and B. Now I need to add these 2 bits in such a way that I
get the correct value in an 8-bit space.

I presume you mean adding modulo 256.


sum = ( a + b ) & 0xff;

--
Bush crime family lost/embezzled $3 trillion from Pentagon.
Complicit Bush-friendly media keeps mum. Rumsfeld confesses on video.
http://www.infowars.com/articles/us/mckinney_grills_rumsfeld.htm

Canadian Mind Products, Roedy Green.
See http://mindprod.com/iraq.html photos of Bush's war crimes

 

[Paul Tomblin]

In a previous article, (e-mail address removed) said:

I presume you mean adding modulo 256.


sum = ( a + b ) & 0xff;

I think he's trying to put two 8 bit values together to make one 16 bit
value, in which case he'd want

sum = a << 8 | b;

 

[Thomas Hawtin]

I think he's trying to put two 8 bit values together to make one 16 bit
value, in which case he'd want

sum = a << 8 | b;

Presumably not if he's stored them in bytes.

Tom Hawtin

 

[Lee Fesperman]

In a previous article, (e-mail address removed) said:

I think he's trying to put two 8 bit values together to make one 16 bit
value, in which case he'd want

sum = a << 8 | b;

At least that makes sense with his subject, assuming he got his hex to decimal
conversion wrong. (8 << 8 | 8) is 0x88 or 136 decimal ... not 137 decimal.

 

[Tim Tyler]

At least that makes sense with his subject, assuming he got his hex to
decimal conversion wrong. (8 << 8 | 8) is 0x88 or 136 decimal ... not
137 decimal.

I make it 0x808.

 

[Rajesh.Rapaka]

yes,
I am reading them as bytes! and I am this is how i felt is the correct
way of doing it....
byte a, b;
readbytes ab();
short value = b << 8 | a;

in this particular compression technique, we get only values between
-127 and 127.

ie a and b can contain values between -127 and 127. But when i see the
value that i get i get most of them above -127.

I dont think conversion from hexadecimal to decimal is important.

any ideas?

thanks in advance,
regards,
Rajesh Rapaka.

 

[Ingo R. Homann]

Hi Rejesh,

byte a, b;
readbytes ab();
short value = b << 8 | a;

OK, think about, what "b<<8" will do with a *byte*!

Hth,
Ingo

 

[Thomas Hawtin]

Doesn't even compile.

OK, think about, what "b<<8" will do with a *byte*!

Much the same as it'd do to an int.

Think about the representation of negative ints across their 32-bits.

Tom Hawtin

 

[Ingo R. Homann]

Hi,

Doesn't even compile.


Much the same as it'd do to an int.

Testing... compiling... testing again...

Intersting!

What's the reason, that java does not compile the first one, when it
really compiles the second one without complaining? Why does java treat
byte and int so differently in this case?:

byte b = 42;
b = b << 8; // not OK

int i = 42;
i = i << 128; // perfectly OK

Think about the representation of negative ints across their 32-bits.

???

Ciao,
Ingo

 

[Tor Iver Wilhelmsen]

What's the reason, that java does not compile the first one, when it
really compiles the second one without complaining? Why does java
treat byte and int so differently in this case?:

It doesn't: The shift operator, like all other operators, promote its
arguments - in this case to int, since neither operand is a double or
long. You then need to mask and/or downcast as needed.

 

[Lee Fesperman]

I make it 0x808.

Quite right. I was thinking of:

sum = (a << 4) | b;

((8 << 4) | 8) produces 0x88.

Mea Culpa...

 

[Tim Tyler]

What's the reason, that java does not compile the first one, when it
really compiles the second one without complaining? Why does java treat
byte and int so differently in this case?:

byte b = 42;
b = b << 8; // not OK

int i = 42;
i = i << 128; // perfectly OK

In the first case Java is promoting to an integer - perhaps because
that's what you might normally want to do - and perhaps so they
don't have to write different bytecode operators for every single
primitive type.

In the second case, Java is not promoting to a 256-bit type -
perhaps because Java doesn't have a 256-bit primitive type - and
perhaps because that's rarely what you would want to do in the first
place.

It doesn't give an overflow error either - Java's primitive integer
types tend not to do that.

Instead it suggests that 42 << 128 is 42.

That is, after all, the answer to everything - isn't it?

 

[Ingo R. Homann]

Hi,

Instead it suggests that 42 << 128 is 42.

It's getting more and more interesting! Do I understand it correctly,
that when x is an int

x<<y

is really interpreted as

x<<(y%32)

? My test suggest so...

That is, after all, the answer to everything - isn't it?

Ciao,
Ingo

 

[Chris Uppal]

x<<y

is really interpreted as

x<<(y%32)

? My test suggest so...

That's right; it's part of the language specification. Similarly, the shift
value for longs is implicitly &-ed with 63.

IMO, the compiler should issue a warning when the 'y' value is a literal value
that it "knows" will be truncated.

-- chris