Win a copy of Pragmatic AI this week in the Artificial Intelligence forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Jeanne Boyarsky
  • Liutauras Vilda
  • Campbell Ritchie
  • Tim Cooke
  • Bear Bibeault
Sheriffs:
  • Paul Clapham
  • Junilu Lacar
  • Knute Snortum
Saloon Keepers:
  • Ron McLeod
  • Ganesh Patekar
  • Tim Moores
  • Pete Letkeman
  • Stephan van Hulst
Bartenders:
  • Carey Brown
  • Tim Holloway
  • Joe Ess

casting a long value (130L) to a byte value?  RSS feed

 
Ranch Hand
Posts: 158
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
somehow, Im missing something about this situation:

1) I know that the maximum value of a byte is 127 because a byte is 8 bits and max value is (2^7)-1 and min value is -(2^7)
2) I know that Java allows you to convert the long to a byte but that you can get an "unexpected" result because of considerations for two's compliment implementation and oveflows and other stuff that Michael Ernest talked about in the topic values cast to a byte
3) I know that I have to remember that when the long value of 130 casts to a byte, we hit 127 then have to start counting up from -128,-127, -126 (stop) to arrive at correct answer.
4) here's where I don't follow:
130 L represented as binary is 64 bits:

leading zeroes ... 1000 0010 <- last 8 bits
to get the byte, we retain only last 8 bits
1000 0010
as I look at this, the leftmost bit tells me it's
a negative number;
so to store this negative number:
a) we first take one's compliment:
0111 1101
b) add 1 to this
0111 1101
+0000 0001
_________
=0111 1110
this looks like positive 126 to me.
where I am goofing up?

Your help is appreciated.
[ November 21, 2002: Message edited by: david eberhardt ]
 
Ranch Hand
Posts: 47
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
i think it needn't cast it.
beacuse it is a compile time constant varible.
jvm do that narrowen word for u
 
david eberhardt
Ranch Hand
Posts: 158
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Originally posted by Keen Chen:
i think it needn't cast it.
beacuse it is a compile time constant varible.
jvm do that narrowen word for u


On a test, I would need to select the correct answer for the output ... so I need to learn how to come up with the correct answer.
still looking for an explanation about the manipulation of the bits please.
[ November 21, 2002: Message edited by: david eberhardt ]
 
david eberhardt
Ranch Hand
Posts: 158
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Originally posted by Keen Chen:
i think it needn't cast it.
beacuse it is a compile time constant varible.
jvm do that narrowen word for u



 
Keen Chen
Ranch Hand
Posts: 47
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
The compiler will implicitly do a narrowing conversion for an assignment statement if the right hand operand is a compile time constant of type byte, short, char, or int and the value falls within the range of the variable on the left and if the variable is of type byte, short, or char.
 
Ranch Hand
Posts: 115
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
David
The 8 least significant bits of the long variable are taken, and stored in the byte variable, without any conversion. So 1000 0010 is stored in the byte variable. Since the leading bit is 1, the JVM treats the value as negative.
Hope that helps.
 
david eberhardt
Ranch Hand
Posts: 158
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Originally posted by John Paverd:
David
The 8 least significant bits of the long variable are taken, and stored in the byte variable, without any conversion. So 1000 0010 is stored in the byte variable. Since the leading bit is 1, the JVM treats the value as negative.
Hope that helps.


oh - ok, so we store it as
1000 0010 (where the left most bit reminds us that it is negative
to come up with the decimal equivalent nbr we:
take one's compliment to get 0111 1101
then add 1 to it to get 0111 1110
this translates to 126
and then we add the negative sign since we know it was a negative number that was stored, right?
I think your answer told me that I should have stored it as you said (instead of doing the two's compliment before the storage), ...
... do the two's compliment when I retrieve it to display it.
thanks John!
[ November 21, 2002: Message edited by: david eberhardt ]
 
It is sorta covered in the JavaRanch Style Guide.
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!