This question already has answers here:
Best way to make Java's modulus behave like it should with negative numbers?
(6 answers)
Closed 5 years ago.
I was writing a code (I knew the output,In Java) , after compiling it giving the input i got a weird value.
Code Snippet -
long a,b,c;
a=-245436499;
b=992;
c=(a+b);
System.out.print(c%b);
And the Output it gave me was
-819
But when i calculated it on calculator, it was
173 \\why?
Proof:
Calculators output
Compiler's output
There are two ways of calculating modulo of a negative number:
Java (as per the JLS) uses the "preserve sign" method; ie if the first operand is negative, non-zero results are negative
Results are (made) positive by adding (if necessary) the second operand to the result of method 1
Your calculator clearly uses method 2 (-819 + 992 = 173)
Related
This question already has answers here:
Mod in Java produces negative numbers [duplicate]
(5 answers)
Closed 2 years ago.
I am converting a program written in Python to Java. There is an equation in Python code: (19 - 20) % 91 and it Java version is (19 - 20) % 91 means same. This equation is giving the answer 90 in Python but, in Java it is giving the answer -1. How do I modify this equation from Python to Java so that it can work and run properly?
The problem here is that in Python the % operator returns the modulus and in Java it returns the remainder. These functions give the same values for positive arguments, but the modulus always returns positive results for negative input, whereas the remainder may give negative results. There's some more information about it in this question.
You can find the positive value by doing this:
int i = (19-20) % 91;
if (i<0) i += 91;
Or you can use Math.floorMod():
Math.floorMod((19-20), 91);
This question already has an answer here:
Division between integers in Java
(1 answer)
Closed 3 years ago.
I've been struggling with Math.asin() for a while.
System.out.println(Math.toDegrees(Math.asin(1 / 2)));
This very simple line of code pretty much sums up my desperation: The result should be 30°, however, I only get 0.0 as a result. Its not just these numbers, no matter which numbers I use, the result is 0.0.
My question is, is this a known bug of Java, or am I missing something?
Bonus Information:
I need asin() to calculate the angle between the centerpoints of two objects in my game.
You’re doing integer division, please add a decimal point in the end of each number like this:
System.out.println(Math.toDegrees(Math.asin(1.0/2.0)))
This question already has answers here:
How does Java handle integer underflows and overflows and how would you check for it?
(12 answers)
Closed 3 years ago.
I though that the following pieces of code does not compile. However after running it I got unexpected result, I don't understand how it is printing -2 ? can you explain how addition is done here?
int x = 2147483647+2147483647; // it compiles
System.out.print(x); // prints -2
any explain is welcome
Short answer: When Java integers reach their maximum value plus one, they start at their minimum again. It's like going in a circle.
It's like that due to the technical representation of integers as bits. Imagine having 3 bits available to represent a number. You could have the number 111. If you add 1 to it, you'll end up at 1000 but since you only have 3 bits available, it cuts off the first and you end up with 000 which is why you're at the minimum value again after adding 1 to the maximum.
This question already has answers here:
Is floating point math broken?
(31 answers)
Closed 4 years ago.
I have odd problem in my java code. Why does every number lower than 0.4f multiplied by 0.0025f gives me wrong results.
Correct result:
0.4f * 0.0025f = 0.001f
Wrong results:
0.399999f * 0.0025f = 9.999975E-4
instead of 0.000999998f
0.33333f * 0.0025f = 8.33325E-4
instead of 0.000833325f
0.11111f * 0.0025f = 2.77775E-4
instead of 0.000277775f
How are you printing your results. You should maybe look at that. It sounds like you don't understand exponential notation.
9.999975E-4 == 0.000999975
The E-4 just means shift the decimal 4 places to the right.
Furthermore, you're doing your own math wrong. You have a number ending in a 9 multiplied by a number ending in 5, which means the answer is going to end in a 5 (9 x 5 is 45, after all). So it's NOT going to be 0.000999998. You got that answer from something that rounded it, perhaps a calculator that won't show it all the way out.
You don't have a math problem. You have a display problem, and not really. It's that you don't understand the display.
Perhaps look up the printf methods and use a format string with lots of room for data after the decimal.
This question already has an answer here:
unsigned right Shift '>>>' Operator in Java [duplicate]
(1 answer)
Closed 9 years ago.
i get confused when i readed the code snippet
long lastWordMask = WORD_MASK >>> -toIndex;
but toIndex is positive, i wonder what is going on if a negative number come after the operator(>>>)
any help will be appreciated
If toIndex is positive and a negative (-) sign is placed before it, you have to imagine that the positive binary counterpart of toIndex is converted to it's negative binary counterpart. after that a right shift is then performed. try to manually calculate the result.
after that long litany, just try that line of code and compare to the result of your manual calculation.
if not, then you have to learn to calculate. :)