Win a copy of Mesos in Action this week in the Cloud/Virtualizaton forum!

# Reality Check!

Sam Moran
Ranch Hand
Posts: 86
I wrote the function below to accomplish the following:
1. Determine if the MSB (most significant bit) is set
2. find the true decimal value from the binary string
I swap the bits and then add one to the LSB.
So, now my question, was there a better or easier way to do this? I am sure that I took the long way there.

[ February 20, 2003: Message edited by: Sam Moran ]
[ February 20, 2003: Message edited by: Sam Moran ]
[ February 20, 2003: Message edited by: Sam Moran ]
[ February 20, 2003: Message edited by: Sam Moran ]

Peter den Haan
author
Ranch Hand
Posts: 3252
Does this fit the bill? - Peter

Sam Moran
Ranch Hand
Posts: 86
Peter thank you very much for the Reply! This doesn't work because I get the following runtime error:
at java.lang.Short.parseShort(Unknown Source)
at hextobin.twoscomplement(hextobin.java:36)
at hextobin.main(hextobin.java:109)
Maybe I didn't explain properly, but the string that I am currently trying to get the correct value for is a 16 bit binary number. I wrote the above function to work on any size binary number. I have only proved with 16 bits, and have not tried 32 bits yet. I may need to assign to a long if the number of bits is to large.
Any thoughts or comments? Also, I did try using the XOR, add one, but I still had to multiply by -1 to get the correct result. See below:

The above works, but as I stated above I was trying to come up with a generic way to perform the translation of the correct signed decimal value. I assumed that I took the long way around.
Thank you again.
[ February 20, 2003: Message edited by: Sam Moran ]

Peter den Haan
author
Ranch Hand
Posts: 3252
Originally posted by Sam Moran:
Peter thank you very much for the Reply! This doesn't work because I get [a java.lang.NumberFormatException]
You're right, parseShort() wants to see a sign and doesn't handle a full 16 bits number including the sign bit. D'oh. Stupid behaviour. Oh well, then we'll have to do the bit fiddling ourselves:Basically, this code goes through all the character bits in turn and shifts them into the long value. There is just one twist -- the Math.max() call ensures that the value is left-padded with the MSB (sign) bit to 64 bits.
Padding with the sign bit is how you extend signed binary numbers to larger sizes; the JVM internally handles widening integer conversions in exactly the same way.
- Peter

Sam Moran
Ranch Hand
Posts: 86
Peter, thank you again! This attempt does not work properly either. You can tell me to go away and tell me that I should drop it. I was just curious if there was a better way to do it!?!?
The output looks like this:
C:\temp\java\work>java hextobin
This is the new = 65524
This is the new = 65531
Here you can see I get the wrong result. It should be -12 and -5 respectively.

I made a minor change to grab the max chars in the string sent in. What do you think? Go away( i am kidding of course)!

Peter den Haan
author
Ranch Hand
Posts: 3252
Originally posted by Sam Moran:
[...] This attempt does not work properly either.
*grumble* Well, it worked for me.This outputs 5, -5, 12 and -12, respectively. I obviously misunderstood what you're trying to do. What are you trying to stick into the function?
- Peter

Peter den Haan
author
Ranch Hand
Posts: 3252
I should really add that if your string starts with anything other than a 1, you shouldn't complain that the function returns a positive number...
- Peter

Sam Moran
Ranch Hand
Posts: 86
Peter, thanks. I have Java Version 1.3.1, and the integer output from the code snipet that you sent me gave me the result of:
This is the new = 65524
This is the new = 65531
I do not expect to get a minus decimal if the MSB is set to zero. I have an IF statement at the beginning of the function to test for this. In the mean time I did find a different approach:

Peter den Haan
author
Ranch Hand
Posts: 3252
No clue why JDK 1.3 would give a different result -- it is almost as if your for loop only down from 32, or as if the left-shift gets evaluated as an int! Are you sure you copied the code as-is?
The problem (if it is a problem) with your code is that it will work only up to 31 bits -- 63 bits if you switch to Long. My snippet does all of them. By the way,looks like an elaborate way to write 0xffff
- Peter
[ February 21, 2003: Message edited by: Peter den Haan ]

Sam Moran
Ranch Hand
Posts: 86
Peter, Thank you again. I have looked at my O'Reilly book, the Sun website and done a search via Google for an explanation of getting a signed decimal value from a 16 bit string representation of a binary number, which was my immediate need. I could not find anything that served as a striaght forward approach. So, I attempted to write a function that would XOR the bits and then add one to the LSB. This worked and I proved it out. While I was working on it I decided to build into the function a more generic approach by testing the length of the string in hopes that if a 32 bit binary string was sent in, it could handle it.
I posted this version in the Performance section of JavaRanch in hopes that someone would look at it and say, "hey stupid why didn't you do it this way?" I am at a loss as to why when I used your rendition it gives my the large non-signed decimal value. Thank you again for the information.

Peter den Haan
author
Ranch Hand
Posts: 3252
Last attempt, and then I'll leave you in peace.This will handle 16-bit bitstrings only. The cast to short is essential..Will do the same for 32-bit strings. You can use a case statement to combine them, if you wish:.Not pretty, but arguably better than what you have now.
- Peter