This question already has answers here:
Converting 32-bit binary string with Integer.parseInt fails
(4 answers)
Closed 5 years ago.
The binary string is "10101010101010101010101010101010", 32 bits
Got this exception when i try
Integer.parseInt("10101010101010101010101010101010", 2);
But the same string(add "0b" prefix)
System.out.print(0b10101010101010101010101010101010);
return -1431655766.
Is this a valid binary string?
Integer.parseInt() is the wrong method as it only accepts signed numbers.
With Java8, use:
Integer.parseUnsignedInt("10101010101010101010101010101010", 2);
Before Java8, use:
(int) Long.parseLong("10101010101010101010101010101010", 2);
The value you wanted to convert goes beyond the int type size, UseBigInteger:
BigInteger b = new BigInteger("10101010101010101010101010101010",2);
Integer.parseInt("10101010101010101010101010101010", 2);
Note that this would be 2863311530, which would cause an overflow, as it is above Integer.MAX_VALUE.
System.out.print(0b10101010101010101010101010101010);
This however uses the internal representation of an integer, which is two-complement form. Thats why it is negative. The Integer.parseInt() however treats it as an unsigned binary number, which causes the Exception.
It is important to understand the different bit representations.
Edit: If you want your input to be interpreted as two-complement, use this:
Integer.parseUnsignedInt("10101010101010101010101010101010", 2);
Related
This question already has answers here:
Different between parseInt() and valueOf() in java?
(11 answers)
Closed 5 years ago.
I have recently stumbled upon another question on Stack Overflow where one person suggests using Short.parseShort(String s) and another Short.valueOf(String s).
I have tried both myself, and I found no difference in functionality and the official Documentation didn't really help me either:
Short.parseShort:
Parses the string argument as a signed decimal short. The characters in the string must all be decimal digits, except that the first character may be an ASCII minus sign '-' ('\u002D') to indicate a negative value or an ASCII plus sign '+' ('\u002B') to indicate a positive value. The resulting short value is returned, exactly as if the argument and the radix 10 were given as arguments to the parseShort(java.lang.String, int) method.
Short.valueOf:
Returns a Short object holding the value given by the specified String. The argument is interpreted as representing a signed decimal short, exactly as if the argument were given to the parseShort(java.lang.String) method. The result is a Short object that represents the short value specified by the string.
Both accept the additional Parameter radix, and both throw a NumberFormatException.
They seem to be identical, but if that is the case, why do both exist?
valueOf is using parseShort internally and additionally wraps the value in a boxed type Short:
public static Short valueOf(String s, int radix)
throws NumberFormatException {
return valueOf(parseShort(s, radix));
}
This question already has answers here:
Why are integer literals with leading zeroes interpreted strangely?
(8 answers)
Closed 6 years ago.
I just wanted to experiment with some integers and assigned the value "0013" to an integer a. When I print the value to the output console I get "11". What causes this? Why I do not get 13 ?
int b = 0013;
System.out.println(b);
A leading zero mean octal. Just like a leading 0x mean hexadecimal
Java has accidentally automatically taken your number to be an octal number. Unlike hexadecimal notation, where the number is preceded by a 0x, octal is proceeded by a single zero. The compiler has probably taken your number and made it into an octal format.
Try using 13 instead of 0013
This question already has answers here:
How to calculate modulus of large numbers?
(10 answers)
Closed 6 years ago.
for(i=0; i<n+1; i++)
{
y=y+(a[i]*(int)Math.pow(j,i));
}
int r=y/786433;
s[k]=y-(r*786433);
k++;
Now in this code the j value can be 786432. So when I try to get modulus of a number say (1+2*(786432)^2+3*(786432)^3)%786433 then I get -521562 which is not correct I was using modulus operator before too but I got the same answer even with this approach I am getting the same answer. In this approach the modulus of the number is stored in array s[k]. Can anyone help?
If you use Math.pow you are using a double types. Then you convert it back to an int. Rounding can happen and also truncating if values are too big.
To solve this problem You need to use BigInteger:
Immutable arbitrary-precision integers
In particular the method mod:
Returns a BigInteger whose value is (this mod m). This method differs from remainder in that it always returns a non-negative BigInteger.
This question already has answers here:
hex to int number format exception in java
(4 answers)
Closed 6 years ago.
I get following exception:
java.lang.NumberFormatException: For input string: "3693019260"
while calling
Integer.parseInt(s);
And I don't know why I get it.
3693019260 is smaller than 2^32
3693019260 is clearly a natural number
the String is cleared from all non-digit elements with s.replaceAll("[^0-9]", "")
So why do I get this exception?
According to the little bit of debugging I did, I saw that the number dips under multmin but I don't know what this variable does and how I should interpret this observation.
While 3693019260 may fit into a 32 bit unsigned integer, it looks like you are trying to parse it into a plain int which is a signed integer. Signed simply means that it supports negative values using -.
With signed numbers, half of the namespace is reserved, so your number must fit into 2^32÷2−1 2147483647 instead of simply 2^32.
The simplest fix is to parse the value as a long instead of an int. Long numbers are 64 bits and support many more digits in the string.
This question already has answers here:
Why doesn't Java support unsigned ints?
(17 answers)
Closed 6 years ago.
Byte value is between 0 and 255, very simple and straight forward. Java didn't think so however and decided that values to be between -128 and 128 and ruined my life and many others.
I just want to know what's the big idea? why everytime i need to get the unsigned byte value do I have to do this:
int byteValue = (int) javaByte & 0xFF;
Java supports only signed integers. byte is integer number as well so Java is just consistent here.
This is not case for C for example where char type doesn't have defined whether it's signed or unsigned. You need to explicitly tell. This is in my opinion much worse than saying that it's by default signed.
Anyway, the original intention in C for char was a string character where the unsigned made sense. In Java there is different type for string character - char.