• 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 Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Coversions between different types

 
Ranch Hand
Posts: 57
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
This is a question from a mock exam:
public class Tester {
public static void main(String[] args) {
int i = 0;
byte b = 0;

b += b - (i = 0xffffffc9);
System.out.println(Integer.toHexString(b));
} // main()
} // Tester

This program prints
37
I calculated the result(on paper) as follows:
1) Converted i value to a bit pattern and decoded the value as a decimal -55.
2) Computed the result of the assignment stmt as +55(decimal value)
3) Obtained the bit pattern for 55 and converted the rightmost 8 bits to hex which gave me 0x37.
Although, I got the right answer, it seems like a long process. In the interest of time when I take the exam, I was wondering if there was an easier/short cut method to calculating the new value of "b". I have come across many questions of this kind in the mock exams and it takes up a lot of my time when I do the conversions.
Is my approach wrong or is there a better approach?
My other question is how did it allow the result to be assigned to a byte again without explicit casting?
Thanks
Sharda
 
Ranch Hand
Posts: 7729
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
1. Learn how to do addition and subtraction using
hexadecimal numbers.

2. With compound operators like += there is always
an implicit cast to the type of the target.

-Barry
[ September 13, 2002: Message edited by: Barry Gaunt ]
 
Ranch Hand
Posts: 73
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator


My other question is how did it allow the result to be assigned to a byte again without explicit casting?


Extended assignment operators do an implicit conversion of the result to the corresponding type on the left hand side of the assignment. Hence it works without explicit cast. It is given clearly in the Khalid Mughal book that
<var> <op>= <expr>
is equivalent to
<var> = (<var's type> (<var> <op> <expr>
Note that (<var> <op> <expr> will undergo any numeric promotion as required. But the final result will always be cast to the type of the LHS.
 
Ranch Hand
Posts: 43
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Here is what i did to calculate the result.
1) forget FFFFFF part. It just indicates that the number is negative. Since u r subtracting from 0, the answer will be positive.
2) As Barry suggested, do the hex subtraction but only subtract C9 from 00. When doing hex subtraction always count in 16s not in 10s. So u get 37.
This problem was easy because it dealt with 0 and the number was small. The mantra is practice. The day u dont have to think to start counting in 16s, u got it. But remember there is octal and binary too. So u got to think in 2s, 8s , 10s and 16s. Life is tough. Practice, thats what i am trying to do.
Thanks
Bishal
 
Sharda Vajjhala
Ranch Hand
Posts: 57
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Barry, Bishal,
I am still not clear on the number conversions. Why are you subtracting from 10...0? I am even more confused now.
And would your calculation be different if b were a value other than 0.
Please help!!
Thanks
Sharda
 
Bishal P
Ranch Hand
Posts: 43
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Well these things are dificult to put in writing but then thats teachers are there for. And in this age of internet finding teachers is easy.
So i have a teacher for you in the form of this
link. I hope you are able to understand the subtraction of hexadecimal numbers based on this.
Sorry for confusing you but then what more do you expect of a guy who is also confused.
Enjoy!
Bishal
 
Ranch Hand
Posts: 787
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Sharda: I do not exactly know how you derived this question. The following is the fastest way I could think of:
1. F,F,F,F,F,F,C,9 (in hex)
we see that left most bit is 1 (bcoz F=1111), which is sign bit. So this number is -ve.
convert each hex digit into its own binary eq. Should be very easy and quick:
2. 1111,1111,1111,1111,1111,1111,1100,1001
we know that it is in 2's compliment. To decode, first substrac 1 from it. Should be easy:
3. 1111,1111,1111,1111,1111,1111,1100,1000
now reverse bits
4. 0000,0000,0000,0000,0000,0000,0011,0111 (a negative number)
because we are substracting this number from 0 (b-this number), therefore sign would change.
5. 0000,0000,0000,0000,0000,0000,0011,0111 (a positive number)
above number is in int type. finaly we casting it to byte, which will keep only right 8 bits:
6. 0011,0111
we printing it in hex, so convert each set of 4 binary bits into its equivalent hex
7. 3,7
8. ox37
Let me know if this was faster than yours. Otherwie I can learn your method...
Thanks
Barkat
[ September 13, 2002: Message edited by: Barkat Mardhani ]
[ September 13, 2002: Message edited by: Barkat Mardhani ]
 
Sharda Vajjhala
Ranch Hand
Posts: 57
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Bishal, I went through your link - it was helpful, but my question still remains.
If the value of b is 0, then why are you subtracting from 100000000? I guess I am confused about subtracting from a lesser number.
Similarly, when I added the following lines of code :
byte c = 0x5E;
c += c - (i = 0xffffffc9);
System.out.println(Integer.toHexString(c));
This prints out fffffff3. How did it get that output?
Barkat, my method was pretty much the same except that I converted to decimal to decode the 2's complement(because that's how it was explained in the book).
Thanks
Sharda
 
Bishal P
Ranch Hand
Posts: 43
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

first we will do c-i which is 0000005E-FFFFFFC9 which should give you 00000095 ( +ve - (-ve) = (+ve)) .
You need not put a 1 before the number but you have to borrow. Putting a 1 before the first operand makes it easier to visualize, since the numbers are represented in 2's complement form and so FFFFFFC9 looks higher than 5e which is not the case. This is no hard and fast rule so you can do the way you like to.

Now we will add 0000005E + 00000095 which should give you 000000F3
Now how did you get FFFFFFF3. I tried it on windows scientific calculator and got the same result. Surprised i compiled the code and executed it and wow i got FFFFFFF3.
Actually it happens because of the implicit casting since you are dealing with bytes and int literal (FFFFFFC9). Remember during arithmetic operations both operands are atleast promoted to int.
If your variable c was declared as int instead of byte you would have got F3.
Hope the weekend refreshed your mind and now you can understand the mumbo-jumbo i speak.

Bishal
 
Sharda Vajjhala
Ranch Hand
Posts: 57
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Bishal,
Thanks for your detailed explanation. In the 2nd half of the calculation, you are saying that because of the arithmetic promotion it fills in the remaining bits to the left of C9 to ffffff i.e. it is filling in with 1s. Should it not fill it with a default of 0s instead?
Thanks
Sharda
 
Consider Paul's rocket mass heater.
reply
    Bookmark Topic Watch Topic
  • New Topic