I am getting data from bluetooth and want to convert byte value to int and show result into float for that I have written following code
String prob1Str = manufactureData.substring(20, 24); // prob1Str = FE70
float prob1Temp = (Integer.parseInt(prob1Str,16)&0xffff); // Here I am getting prob1Tem = 65136.0 instead of -400.0
model.setProb1Temp(prob1Temp);
From above code I am getting prob1Tem = 65136.0 instead of -400.0
can anybody help me how to resolve this
thanks
Just cast your result to short!
float prob1Temp = (short)Integer.parseInt(prob1Str, 16);
int is 32 bits, so 0x0000FE70 = 65136, it is a positive value!
Short is 16 bits, 0xFE70 = -400, you will recast it to int or float after.
Look at that explanation for more details.
Integer.parseInt("FE70", 16) << 16 >> 16
will correctly extend sign bit. or same less tricky and not bound to Integer size:
int i = Integer.parseInt("FE70", 16);
if (i >= 0x8000) i -= 0x10000;
Related
I have the following code...
int Val=-32768;
String Hex=Integer.toHexString(Val);
This equates to ffff8000
int FirstAttempt=Integer.parseInt(Hex,16); // Error "Invalid Int"
int SecondAttempt=Integer.decode("0x"+Hex); // Error "Invalid Int"
So, initially, it converts the value -32768 into a hex string ffff8000, but then it can't convert the hex string back into an Integer.
In .Net it works as I'd expect, and returns -32768.
I know that I could write my own little method to convert this myself, but I'm just wondering if I'm missing something, or if this is genuinely a bug?
int val = -32768;
String hex = Integer.toHexString(val);
int parsedResult = (int) Long.parseLong(hex, 16);
System.out.println(parsedResult);
That's how you can do it.
The reason why it doesn't work your way: Integer.parseInt takes a signed int, while toHexString produces an unsigned result. So if you insert something higher than 0x7FFFFFF, an error will be thrown automatically. If you parse it as long instead, it will still be signed. But when you cast it back to int, it will overflow to the correct value.
It overflows, because the number is negative.
Try this and it will work:
int n = (int) Long.parseLong("ffff8000", 16);
int to Hex :
Integer.toHexString(intValue);
Hex to int :
Integer.valueOf(hexString, 16).intValue();
You may also want to use long instead of int (if the value does not fit the int bounds):
Hex to long:
Long.valueOf(hexString, 16).longValue()
long to Hex
Long.toHexString(longValue)
It's worth mentioning that Java 8 has the methods Integer.parseUnsignedInt and Long.parseUnsignedLong that does what you wanted, specifically:
Integer.parseUnsignedInt("ffff8000",16) == -32768
The name is a bit confusing, as it parses a signed integer from a hex string, but it does the work.
Try using BigInteger class, it works.
int Val=-32768;
String Hex=Integer.toHexString(Val);
//int FirstAttempt=Integer.parseInt(Hex,16); // Error "Invalid Int"
//int SecondAttempt=Integer.decode("0x"+Hex); // Error "Invalid Int"
BigInteger i = new BigInteger(Hex,16);
System.out.println(i.intValue());
As Integer.toHexString(byte/integer) is not working when you are trying to convert signed bytes like UTF-16 decoded characters you have to use:
Integer.toString(byte/integer, 16);
or
String.format("%02X", byte/integer);
reverse you can use
Integer.parseInt(hexString, 16);
Java's parseInt method is actally a bunch of code eating "false" hex : if you want to translate -32768, you should convert the absolute value into hex, then prepend the string with '-'.
There is a sample of Integer.java file :
public static int parseInt(String s, int radix)
The description is quite explicit :
* Parses the string argument as a signed integer in the radix
* specified by the second argument. The characters in the string
...
...
* parseInt("0", 10) returns 0
* parseInt("473", 10) returns 473
* parseInt("-0", 10) returns 0
* parseInt("-FF", 16) returns -255
Using Integer.toHexString(...) is a good answer. But personally prefer to use String.format(...).
Try this sample as a test.
byte[] values = new byte[64];
Arrays.fill(values, (byte)8); //Fills array with 8 just for test
String valuesStr = "";
for(int i = 0; i < values.length; i++)
valuesStr += String.format("0x%02x", values[i] & 0xff) + " ";
valuesStr.trim();
Below code would work:
int a=-32768;
String a1=Integer.toHexString(a);
int parsedResult=(int)Long.parseLong(a1,16);
System.out.println("Parsed Value is " +parsedResult);
Hehe, curious. I think this is an "intentianal bug", so to speak.
The underlying reason is how the Integer class is written. Basically, parseInt is "optimized" for positive numbers. When it parses the string, it builds the result cumulatively, but negated. Then it flips the sign of the end-result.
Example:
66 = 0x42
parsed like:
4*(-1) = -4
-4 * 16 = -64 (hex 4 parsed)
-64 - 2 = -66 (hex 2 parsed)
return -66 * (-1) = 66
Now, let's look at your example
FFFF8000
16*(-1) = -16 (first F parsed)
-16*16 = -256
-256 - 16 = -272 (second F parsed)
-272 * 16 = -4352
-4352 - 16 = -4368 (third F parsed)
-4352 * 16 = -69888
-69888 - 16 = -69904 (forth F parsed)
-69904 * 16 = -1118464
-1118464 - 8 = -1118472 (8 parsed)
-1118464 * 16 = -17895552
-17895552 - 0 = -17895552 (first 0 parsed)
Here it blows up since -17895552 < -Integer.MAX_VALUE / 16 (-134217728).
Attempting to execute the next logical step in the chain (-17895552 * 16)
would cause an integer overflow error.
Edit (addition): in order for the parseInt() to work "consistently" for -Integer.MAX_VALUE <= n <= Integer.MAX_VALUE, they would have had to implement logic to "rotate" when reaching -Integer.MAX_VALUE in the cumulative result, starting over at the max-end of the integer range and continuing downwards from there. Why they did not do this, one would have to ask Josh Bloch or whoever implemented it in the first place. It might just be an optimization.
However,
Hex=Integer.toHexString(Integer.MAX_VALUE);
System.out.println(Hex);
System.out.println(Integer.parseInt(Hex.toUpperCase(), 16));
works just fine, for just this reason. In the sourcee for Integer you can find this comment.
// Accumulating negatively avoids surprises near MAX_VALUE
I have a String representing a HEX value of a 64bit integer "0000000000EA6484". I need to transform it to the double value "0.9155962467" using Java. The instructions I 've been given is to format a 12.52 FP value of type int64_t (8 Bytes).
I found with some googling that the int64_t datatype in C++ is a signed integer. I have also found this post which seem to be relevant but confused me a bit.
Finally I have tried the following java code to see if I get the expected result but I get in both cases "7.5894195E-317". I am sure that either I have not understood how to solve the problem so I would appreciate some help, or that the expected output is wrong.
import java.nio.ByteBuffer;
public class Main {
public static void main(String[] args) {
String hexString = "0000000000EA6484";//0.9155962467
long longValue = Long.parseLong(hexString, 16);
longValue = Long.parseUnsignedLong(hexString, 16);
System.out.println(longValue);
double doubleValue = Double.longBitsToDouble(longValue);
System.out.println(doubleValue);
byte[] bytes = hexStringToByteArray(hexString);
doubleValue = ByteBuffer.wrap(bytes).getDouble();
System.out.println(doubleValue);
}
public static byte[] hexStringToByteArray(String s) {
int len = s.length();
byte[] data = new byte[len / 2];
for (int i = 0; i < len; i += 2) {
data[i / 2] = (byte) ((Character.digit(s.charAt(i), 16) << 4) + Character.digit(s.charAt(i + 1), 16));
}
return data;
}
}
As shown, 0000000000EA6484 represents 0.9155962467193603515625 in a Q40.24 format, not a floating-point format. This is a fixed-point format with 40 integer bits (including a sign bit) and 24 fraction bits. To convert it from the integer represented by those bits in a 64-bit integer format to the value represented by the same bits in the Q12.52 format, divide it by 224: EA648416 = 1536115610, 15361156 / 224 = 0.9155962467193603515625. In Java, dividing the integer value by 16777216 (224) should suffice.
It appears whomever told you this was a 12.52 FP format was wrong. Even if there is some endian issue, or any other byte reordering, that would not explain the shifted position of the bits with respect to a 12.52 format, since it differs by a sub-byte fraction (52 bits − 24 bits = 28 bits, which is 3½ bytes).
I have the following code...
int Val=-32768;
String Hex=Integer.toHexString(Val);
This equates to ffff8000
int FirstAttempt=Integer.parseInt(Hex,16); // Error "Invalid Int"
int SecondAttempt=Integer.decode("0x"+Hex); // Error "Invalid Int"
So, initially, it converts the value -32768 into a hex string ffff8000, but then it can't convert the hex string back into an Integer.
In .Net it works as I'd expect, and returns -32768.
I know that I could write my own little method to convert this myself, but I'm just wondering if I'm missing something, or if this is genuinely a bug?
int val = -32768;
String hex = Integer.toHexString(val);
int parsedResult = (int) Long.parseLong(hex, 16);
System.out.println(parsedResult);
That's how you can do it.
The reason why it doesn't work your way: Integer.parseInt takes a signed int, while toHexString produces an unsigned result. So if you insert something higher than 0x7FFFFFF, an error will be thrown automatically. If you parse it as long instead, it will still be signed. But when you cast it back to int, it will overflow to the correct value.
It overflows, because the number is negative.
Try this and it will work:
int n = (int) Long.parseLong("ffff8000", 16);
int to Hex :
Integer.toHexString(intValue);
Hex to int :
Integer.valueOf(hexString, 16).intValue();
You may also want to use long instead of int (if the value does not fit the int bounds):
Hex to long:
Long.valueOf(hexString, 16).longValue()
long to Hex
Long.toHexString(longValue)
It's worth mentioning that Java 8 has the methods Integer.parseUnsignedInt and Long.parseUnsignedLong that does what you wanted, specifically:
Integer.parseUnsignedInt("ffff8000",16) == -32768
The name is a bit confusing, as it parses a signed integer from a hex string, but it does the work.
Try using BigInteger class, it works.
int Val=-32768;
String Hex=Integer.toHexString(Val);
//int FirstAttempt=Integer.parseInt(Hex,16); // Error "Invalid Int"
//int SecondAttempt=Integer.decode("0x"+Hex); // Error "Invalid Int"
BigInteger i = new BigInteger(Hex,16);
System.out.println(i.intValue());
As Integer.toHexString(byte/integer) is not working when you are trying to convert signed bytes like UTF-16 decoded characters you have to use:
Integer.toString(byte/integer, 16);
or
String.format("%02X", byte/integer);
reverse you can use
Integer.parseInt(hexString, 16);
Java's parseInt method is actally a bunch of code eating "false" hex : if you want to translate -32768, you should convert the absolute value into hex, then prepend the string with '-'.
There is a sample of Integer.java file :
public static int parseInt(String s, int radix)
The description is quite explicit :
* Parses the string argument as a signed integer in the radix
* specified by the second argument. The characters in the string
...
...
* parseInt("0", 10) returns 0
* parseInt("473", 10) returns 473
* parseInt("-0", 10) returns 0
* parseInt("-FF", 16) returns -255
Using Integer.toHexString(...) is a good answer. But personally prefer to use String.format(...).
Try this sample as a test.
byte[] values = new byte[64];
Arrays.fill(values, (byte)8); //Fills array with 8 just for test
String valuesStr = "";
for(int i = 0; i < values.length; i++)
valuesStr += String.format("0x%02x", values[i] & 0xff) + " ";
valuesStr.trim();
Below code would work:
int a=-32768;
String a1=Integer.toHexString(a);
int parsedResult=(int)Long.parseLong(a1,16);
System.out.println("Parsed Value is " +parsedResult);
Hehe, curious. I think this is an "intentianal bug", so to speak.
The underlying reason is how the Integer class is written. Basically, parseInt is "optimized" for positive numbers. When it parses the string, it builds the result cumulatively, but negated. Then it flips the sign of the end-result.
Example:
66 = 0x42
parsed like:
4*(-1) = -4
-4 * 16 = -64 (hex 4 parsed)
-64 - 2 = -66 (hex 2 parsed)
return -66 * (-1) = 66
Now, let's look at your example
FFFF8000
16*(-1) = -16 (first F parsed)
-16*16 = -256
-256 - 16 = -272 (second F parsed)
-272 * 16 = -4352
-4352 - 16 = -4368 (third F parsed)
-4352 * 16 = -69888
-69888 - 16 = -69904 (forth F parsed)
-69904 * 16 = -1118464
-1118464 - 8 = -1118472 (8 parsed)
-1118464 * 16 = -17895552
-17895552 - 0 = -17895552 (first 0 parsed)
Here it blows up since -17895552 < -Integer.MAX_VALUE / 16 (-134217728).
Attempting to execute the next logical step in the chain (-17895552 * 16)
would cause an integer overflow error.
Edit (addition): in order for the parseInt() to work "consistently" for -Integer.MAX_VALUE <= n <= Integer.MAX_VALUE, they would have had to implement logic to "rotate" when reaching -Integer.MAX_VALUE in the cumulative result, starting over at the max-end of the integer range and continuing downwards from there. Why they did not do this, one would have to ask Josh Bloch or whoever implemented it in the first place. It might just be an optimization.
However,
Hex=Integer.toHexString(Integer.MAX_VALUE);
System.out.println(Hex);
System.out.println(Integer.parseInt(Hex.toUpperCase(), 16));
works just fine, for just this reason. In the sourcee for Integer you can find this comment.
// Accumulating negatively avoids surprises near MAX_VALUE
I was trying to save some space in a program and needed to use byte, I got on to a code that looks like this
private static final long MAX = 1000000000L;
private static final long SQRT_MAX = (long) Math.sqrt(MAX) + 1;
private static final int MEMORY_SIZE = (int) (MAX >> 4);
private static byte[] array = new byte[MEMORY_SIZE];
private void getbit(Long i)
{
byte block = array[(int) (i >> 4)];
byte mask = (byte) (1 << ((i >> 1) & 7));
return ((block & mask) != 0);
}
I cant understand what this means? In block why are we using i >> 4 should it not be i >> 3 since each byte is 8 bits? I also dont get what mask is doing?
I'm just getting started with byte's, any links to sources will be helpful
Here is some context - Source Code
Regarding the lowest 8 bits of 'i', this is what I can gather (where the MSB is bit 7 and the LSB is bit 0):
The value in the top 4 bits of 'i' represents an index to 'array'.
The value of 'block' is set to the value located at the above index in 'array'.
The value in bits 1-3 of 'i' represents a bit index to be masked out (the function will return true if the bit at that index in 'block' is 1).
Note: Bit 0 of 'i' seems to be unused.
I know that's not a specific answer, but I hope it helps to point you in the right direction.
I didn't look at the context source code though.
Here's is the situation ... i have a binary file which contains 32-bit binary strings of characters (e.g 1011011100100110101010101011010 ) and i want to convert this to integer ... I have already tried to do it with parse-Int but if the most significant value is 1, i get back a negative number and i do not want that ... Then i tried it with parse-Long and it was okay but after that when i get this integer i have to send it to another class which can receive only integers , as a result i do casting from long to int and i get back a negative integer again ... The only way to do that is with a piece of code that i found which does the opposite thing ( from int to string ) but i do not understand how to change-convert it. It is about masks which i do not know a lot of things.
Here is the code :
private static String intToBitString(int n) {
StringBuffer sb = new StringBuffer();
for (int mask = 1 << 31; mask != 0; mask = mask >>> 1)
sb.append((n & mask) == 0 ? "0" : "1");
return sb.toString();
}
Thank you in advance...
An integer with the highest bit set to 1 is a negative integer, regardless of the number of bits. Just add the heading zero to the string or alternatively clear the highest bit with bitwise AND (x & 0x7FFFFFFF). You can only store a 31 bit positive integer in java int.
Even if you assign such value to long (long x = 0xFFFFFFFF, will be -1), the sign bit expands and now you have the negative long (you can write 0x0FFFFFFFFL however to assign the expected 00000000FFFFFFFF to long). You still need to clear the high bits if this is unwanted behavior.
int a = 0x80000007; // High bit 1 - negative!
long b = a; // Sign expands!
// Clearing high bits (mind leading 0 and
// the long type suffix (L) in the hex constant:
long c = b & 0x0FFFFFFFFL;
System.out.println(a + ":" + Long.toHexString(b) + ":"
+ Long.toHexString(c));
The output: -2147483641:ffffffff80000007:80000007