This question already has answers here:
math.random, only generating a 0?
(4 answers)
Closed 8 years ago.
This piece of code is giving the result I wanted
double a=Math.random()*100;
int b=(int)a;
System.out.println(b);
but when I did for the same thing this way, it is giving zero always
int a=(int)Math.random()*100;
System.out.println(a);
As far as I know typecasting will store the bigger data-type to small. but in the later code, I'm gettig zero every single time I run the program.
(int)Math.random()*100; means:
cast the value of 'Math.random()' to int and then multiple by 100. Since Math.random returns a number between 0 and 1 casting to int will always chop off the decimal path and give you 0.
The correct way to do it is
(int)(Math.random()*100);
Try with,
int a=(int)(Math.random()*100);
System.out.println(a);
Math.random() Returns a double value with a positive sign, greater than or equal to 0.0 and less than 1.0. Returned values are chosen pseudorandomly with (approximately) uniform distribution from that range.
Type casting is both right-to-left associative, and has a higher precedence than multiplication.
Source
Let me break it down a bit.
Like any other operator, a type cast has a certain level of priority attached to it. Certain operators have higher priority than others, and certain operators associate with their arguments in a certain way. For example, numerical operations are typically left-to-right associative; that is, with operators of an equal priority, one can parenthesize them from the left and get the same result.
Example:
5 * 5 * 5 / 3 + 5 -> (((5) * 5) * 5) / 3) + 5
Right-to-left associativity would allow you to parenthsize the operations from the right to achieve the same result.
Example:
int x;
int y;
int z;
x = y = z = 10 -> x = (y = (z = (10))
Type casting, much like assignment, is right-to-left associative, so it's going to essentially use the rightmost argument to satisfy its closest association, then progress backwards through the chain until you reach the ultimate goal.
This means that you could write this as valid syntax, although it would be very strange:
Object foo = (Object)(Number)(float)Math.random();
First, we cast our result from a double to a float, then to a Number, then to an Object (which is totally redundant, but possible).
The priority bit in particular is what causes the multiplication to apply last in this chain of events.
Bear in mind, in no one level of priority does the language intermingle associativity. That means an operator at level 1 priority associates in a specific way, and operators in level 2 operate in a specific way.
So, we come now to your expression:
int a = (int) Math.random() * 100;
Casting has a priority level of 3. The mathematical operator * has a priority level of 4. So, Java sees your statement like this:
int a = ((int) Math.random()) * 100;
The parentheses are there for extra clarity. (Note that parentheses have the highest priority.)
What you want to do, as explained more tersely in other answers, is use the parentheses to force your intended priority instead of letting Java decide. So, you would write this instead:
int a = (int) (Math.random() * 100);
This forces Java to evaluate the multiplication before the cast, since the parentheses have a higher priority than the cast.
Because the cast to int happens before the multiplication and as Math.random() generates a number between 0 (inclusive) and 1 (exclusive), it is rounded to 0.
You are casting before multiplying here...
Math.random() will generate number between 0 and 1 and will be rounded to 0 before multiplying with 100.
(int)(Math.random()*100) will behave as you want.
Consider using java.util.Random:
Random random = new Random();
int value = random.nextInt(100);
System.out.println(value);
Random is thread-safe, whereas Math.Random() is not.
When testing, you can feed a Random the same seed to generate reproducible pseudorandom numbers. You can't with Math.Random().
and more.
See more here: Math.random() versus Random.nextInt(int)
use this :
int a=(int)(Math.random()*100);
System.out.println(a);
Related
I had to calculate this: 1*5000*500/(10000*24645.16239360158)
But then realized I should multiply it by 1000. I get 2 different answers depending on how I do it. I'm not sure why, though, as the placement of parentheses shouldn't matter for multiplication. Would appreciate any insight!
System.out.println(Double.toString(1000*1*5000*500/(10000*24645.16239360158)));
outputs
-7.283243937828597
for sure incorrect because it's negative
System.out.println(Double.toString(1000*(1*5000*500/(10000*24645.16239360158))));
on the other hand, outputs
10.143978603480635
(correct)
Basically in the second case we multiply the result by a 1000 after we've calculated it, and that somehow works.
Thanks!
You need to know that int * int yields an int (5 * 5). And int * double yields an double (5 * 5.0).
As you probably know, those data types have different maximal sizes and store values in a different way.
Here are some of them:
You can use Integer.MAX_VALUE and Integer.MIN_VALUE for the exact bounds.
If you need to exceed those values, but also want to have an int, you should use the class BigInteger. It can handle arbitrary big integers.
Else you will have what is called an overflow, when you do Integer.MAX_VALUE + 1 the result will be Integer.MIN_VALUE. If you recall how this number is stored in bytes, for example something like 111 then +1 would return 1000 but there is no place to store the first 1, you'll receive 000 which is the MIN_VALUE.
You also should know that when you compute 5 / 2 it will not return 2.5 but 2, as you divide two int, the result will also be an int. If you want to have a double, then you need to do something like this 5 / 2.0 or (5 + 0.0) / 2.
this expression 1000*1*5000*500/(10000*24645.16239360158),first calculate 1000*1*5000*500,the result is -1794967296,overflow.
this expression 1000*(1*5000*500/(10000*24645.16239360158)) overflow do not happend.
The evaluation of any expression is done by operator precedence parser. If you want to change the priority of precedence, You would've to use parentheses.
In the first case '/' and '*' having same priority table.
In second case '*' is getting some priority over '/'. Thats why your getting diffrent values as output.
It is because of Java's implicit type casting. By default Java would use int. As user2357112 commented, the number is too large for int.
If you want your first version to work, add a "d" to tell Java to use a double.
Double d = 1000d*1*5000*500/(10000*24645.16239360158)
System.out.println(d);
You'd get:
10.143978603480635
just a quick question and I'm probably gonna feel stupid for asking but still would like to know why it is so...!
Anyways, quick example:
x is a double.
double conversion = (x-32)*5/9;
This does the maths just fine.
double conversion = (x-32)*(5/9);
This isn't fine because the (5/9) is being treated as an int, thus result is overall 0.
double conversion = (x-32)*(5f/9f);
This does the maths just fine, as it explicitly makes the 5/9 values a float.
So my question is: Why does the first equation work perfectly fine? ( double conversion = (x-32)*5/9; )
Why isn't the 5/9 being made a 0 if it were an int supposedly? What makes the 5/9 different from (5/9) ?
The difference is between whether you do the multiplication first or the division first - and what the types of those operations are.
This:
(x - 32) * 5 / 9
is equivalent to:
((x - 32) * 5) / 9
So if the type of x is double, then the type of x - 32 is double, so the 5 is promoted to double, the multiplication is done in double arithmetic, giving a double result, and then the division is also done in double arithmetic.
Even if x is an integer type, you're doing the multiplication first, which will presumably give you a value bigger than 9 (in your test case), leaving you with a non-zero result. For example, if x is 45, then x-32 is 13, (x - 32) * 5 is 65, and the overall result is 7, then converted to 7.0 on assignment. That's not the same result you'll get if x is a double with the value 45.0, but it's still better than multiplying by 0...
You basically answered your own question. Evaluation order makes all the difference.
basic left to right evaluation results in different type casting than your explicit evaluation order in your second example
Assuming x is a double then your first equation divides a double by an integer due to order of operations.
(x-32) = y-> y*5 = z -> z/9
at each stage a double is being operated on, overriding integer arithmetic.
It is the order it's done in.
If you multiply by 5, you get a large number. If you then divide by 9, you still get an int,
But the remainder is discarded.
The reason is the order of the operations.
(x-32)*5/9 makes first (x-32)*5 and then divides the result by 9
(x-32)*(5/9) makes first (x-32) and (5/9). After both results are multiplied.
Your value of x might be double and it is making entire equation in double because brackets execute first.
It's a matter of when the conversion takes place. 5/9 consists of one 5 and one 9 (both ints) being divided with integer division. If either is a float (5f/9 or 5/9f) they will divide as floats.
When I perform simple math in java with doubles and other number data types, the double values seem to randomly vary a bit from the supposed result, which might be 5,59999999997 or 6,0000000002 or something. When I cast to int, the double value is obviously rounded down to the next whole number. Does this mean the double could be both 5 or 6? Or does that "5,999999999997" still count as 6 though which would be depending on the binary float value? If not, is there a way to let the negative vary be rounded up, but not lower values from 5,5 to 5,999999999996?
I mean, I dont really want to round the value as described in my last sentence. I'd like to always round down to the next whole number, but I don't want to cause an extra decrement due to wrong double math results.
Converting a double to an int always rounds down. You can round to the nearest whole integer via Math.round(double). The double is varying from what you expect because of floating point error.
If you want to round, you can use the round() method.
double d = 6 +/- some small error
long l = Math.round(d);
Or you can add 0.5 for positive numbers
long l = (long) (d + 0.5);
or
long l = (long) (d + (d < 0 ? -0.5 : 0.5));
I'm not sure I understand the question. Usually when you cast a double to int you add 0.5 to have a nice round.
From the Java Language Specification:
The Java programming language uses round toward zero when converting a floating value to an
integer (ยง5.1.3), which acts, in this case, as though the number were truncated, discarding
the mantissa bits. Rounding toward zero chooses at its result the format's value closest to
and no greater in magnitude than the infinitely precise result.
So 5,999999999997 when casted to an int will 5 and 6,0000000002 will be 6. If I understand what you are asking with having negative versions of the values (e.g. -5.97), I fail to see how
Math.round() does not suffice you. -6,0000000002 will be rounded to -6 as will -5,999999999997 and every other value above (but not including) -5.5.
Ok so basic question here.
double test = 1/3 * 3.14;
I realize that you need to do (1.0/3) in order to get the actual double number. But what I am wondering is why. I would have thought that since you are multiplying by 3.14 this would make it a double.
So am I correct in thinking that whenever two values are used in an arithmetic equation, regardless of what is happening around them, if they are integers then you will get an integer value?
ie. x/y * z
while x is divided by y that is all that the programme cares about and if they are both integers you will get an integer value back? It is only when you multiply it by z (3.14) that it becomes a double.
Evaluation occurs from left to right when two operators have equal precedence. * and / have equal precedence.
1 / 3 * 3.14 evaluates 1 / 3 first. Both operands are int, the first operation is integer division, and the result is an int.
Next, result * 3.14 is evaluated. One operand is an int, the other operand is a double, and we have mixed types. Java does us a favor and casts the int to a double to preserve accuracy. Floating point division occurs, and the result is a double.
With operators of equal precedence, the associativity takes over. These operators / and * are left-associative, which means that the order of operations proceeds from left to right.
So, 1/3 happens first, and integer division happens before the 3.14 has a chance to promote them to doubles.
Because according to the rules of arithmetics, 1/3 is calculated first. Since it's 2 integers, it's an integer division, resulting in 0. Afterwards you have a double calculation, but the error has already happened.
My understanding is that this has to do with autoboxing in java. Java assumed that the 1/3 is dividing two ints so you'd get an int back (casted into a double).
If you did 1/3D, you'd get 0.33333333 back
Is there any possibility to calculate the highest error of the sum or subtraction of two numbers with 7 fractional digits?
For example:
a=#.#######
b=#.#######
a+/-b = #.####### + / - epsilon
a and b are random numbers. I need an equation for an if-case if a or b are equal to zero or equal to 1' <>epsilon. I thougt if I math.ceil 'a' and math.floor b I get the maximal error. But it does not work.
It seems like that the error is everytimes something with 1.#####...E-6. Can it get mathematically proofed?
Talking about IEEE 754:
The possible error (gap) depends on your floating point data type (i.e. float or double) and more importantly also depends on how far away your number is from zero. (nonuniform resolution)
Assuming you want to solve some programming problem:
In general, you deal with this issue by not using a simple equality comparer but define a domain specific epsilon in your comparisons:
// if(a == b)
if(Math.abs(a-b) < epsilon)
{
...
}