I saw the libgdx MathUtils.randomBoolean(chances), I guess this would help me but I'm not sure.
MathUtils.randomBoolean(10); // I'm not sure if this will give 10% chance?
MathUtils.randomBoolean(float chance) gives the true with probability given by the parameter. But the parameter chance can take value between 0 - 1, meaning that for example 0.1 gives 10% (0.1) probability of returning true.
Your example - 10 - would always result in true as it's bigger than 1.
Take a look at the LibGDX Javadocs regarding MathUtils:
randomBoolean
public static boolean randomBoolean(float chance)
Returns true if a random value between 0 and 1 is less than the specified value.
That means if you specify a number (passed as an argument), the method will return true if the randomly generated number (between 0 and 1) is less than the passed chance. In this case it would be:
MathUtils.randomBoolean(0.1);
This is because 0.1 is 10%, or 10/100. Thus, a random number between 0 and 1, if less than 0.1, will cause the method to return true.
Your code previously would always return true because a number between 0 and 1 is always less than 10.
Related
According to the Javadoc:
public static double nextAfter(double start,
double direction)
...
If start is equal to ± Double.MAX_VALUE and direction has a value such that the result should have a larger magnitude, an infinity with same sign as start is returned.
But according to this example:
System.out.println(Double.MAX_VALUE);
System.out.println(Math.nextAfter(Double.MAX_VALUE, 1));
System.out.println(Math.nextAfter(Double.MAX_VALUE, 1) == Double.POSITIVE_INFINITY);
Output:
1.7976931348623157E308
1.7976931348623155E308
false
Eh? Not only is it not Double.POSITIVE_INFINITY, it's actually smaller in magnitude.
...157E308
...155E308
Am I just completely misreading the Javadoc?
The docs are misleading.
The direction parameter needs to be greater than Double.MAX_VALUE for the returned value to have a larger result.
Since 1 is smaller, the output is the floating point number just before the one you provide.
The C++ docs (under IEEE754) are clearer and even spell out this edge case explicitly: http://en.cppreference.com/w/cpp/numeric/math/nextafter
I was reading Data Structures and Algorithms in Java book and I came across the following question that I would like to get help with:
Suppose you are given an array, A, containing 100 integers that were generated using the method r.nextInt(10), where r is an object of type java.util.Random. Let x denote the product of the integers in A. There is a single number that x will equal with probability at least 0.99. What is that number and what is a formula describing the probability that x is equal to that number?
I think x is equal to zero; as most probably 0 will be generated. However, that's just a guess. I wasn't able to find the formula. The java documentation doesn't specify the randomization equation and I wasn't able to find any related topics either here or after searching using Google.
I would like to get some help with the probability formula please. Thanks in advance.
The possible values for the array elements are 0 .. 9, each with probability 1/10. If one of the elements is 0, the product will be 0 as well. So we calculate the probability that at least one element is 0.
It turns out, this is the opposite of all elements being greater than zero. The probability for an element to be greater than 0 is 9/10, and the probability that all elements are greater than zero is therefore (9/10)^100.
The probability that at least one element is 0 is therefore 1 - (9/10)^100 which is approximately 0.9999734.
Regarding nextInt: The javadoc specifies:
uniformly distributed int value between 0 (inclusive) and the
specified value (exclusive)
a "uniform distribution" is a distribution where each outcome is equally likely.
hence the chances for a particular outcome are "1/[number of possible outcomes]" (so they all add up to 1).
Regarding the array:
Filling the array can be regarded as observing 100 statistically independent events.
You should read up, on how the maths work when combining multiple independent events.
https://docs.oracle.com/javase/7/docs/api/java/util/Random.html#nextInt(int)
As you already expect, it will of be 0
r.nextInt(10)
will return numbers from 0 to 9
The product of any 0 * 1-9 will be 0, therefore for 100 random numbers, the chance that no 0 will be returned from this function is pretty low.
Math.pow(0.0, 0.0) in Java returns 1 which is wrong. 0^0 is undefined. The same problem exists also in the windows calculator (I am using Win7). Why is that?
Mathematica declares it as an error as well as my Casio scientific calculator, why not java or the Win calculator... Is it a bug?
0^0 = 1 is considered a reasonable definition in many contexts. For a list of arguments for and against it, see http://en.wikipedia.org/wiki/Exponentiation#Zero_to_the_power_of_zero
Because that's exactly what the Javadocs say it will do:
public static double pow(double a, double b)Returns the value of the first argument raised to the power of the second argument. Special cases:
* If the second argument is positive or negative zero, then the result is 1.0.
Is it a bug?
No, a bug is something that violates the specification. The specification states:
Returns the value of the first argument raised to the power of the second argument. Special cases:
If the second argument is positive or negative zero, then the result is 1.0.
Finally, mathematically, some do define 0^0 as 1. In fact, Knuth says that it has to be 1.
The number of mappings from the empty set to the empty set is 0^0. It has to be 1.
His reasoning is as follows. If you have two sets, A and B, the number of functions from A to B is |B|^|A|. How many functions are there from the empty set to the empty set? Well, there is exactly one. By this logic, 0^0 should be 1.
Java defines it that way. That's all you can really say.
However, mathematically it is an undefined quantity. One way to see why is to write
x = 0 ^ 0
where I've used ^ to represent exponentiation. Taking logarithms,
log x = 0 log 0
I've done this since every mathematician accepts that log 0 is undefined and so it follows that log x and therefore x are undefined too. (Mathematically it's called a singularity and a mathematician will tell you that it's one of the worst singularities you can encounter).
The exact definition of the function's behavior is given at http://docs.oracle.com/javase/7/docs/api/java/lang/Math.html#pow(double,%20double)
You will see here that
public static double pow(double a,
double b)
Returns the value of the first argument raised to the power of the second argument. Special cases:
If the second argument is positive or negative zero, then the result is 1.0.
Not a bug - it's by design.
I need to map different interval to different single value.
The interval is type long and formed by min and max. The value is a short.
The intervals are not overlapped, but can be consecutive.
I would like to look up if a value is contained in one interval and in positive case returning the value mapped to this interval. Otherwise return null.
For example:
Range => Value
100-200 => 5
500-800 => 50
201-300 => 50
If I lookup for 150, I need to have 5 as result, for 554 50 and instead for 305 null.
If third-party libraries are fair game, this is 100% exactly what Guava's TreeRangeMap does.
I'm trying to sum 561 logs.
They look like these:
-7.314254939475686
-7.656004233197743
-4.816276208120333
-8.426112454893817
-4.771824445549499
-9.34240318676797
So they're not big numbers. However, when I proceed with summing them I get this:
-2668.179647264475
-2674.7747795369874
-2679.18920466334
-2683.9724816026214
-2690.3342661536453
-Infinity
-Infinity
The code that does it is:
double probspam=0;
for(int j=0;j<words.size();j++)
{
probspam+= Math.log(spam.getClassProbability(words.get(j)));
}
Do you have any idea of how to get around the -Infinity issue and why it happens? Thank you
For some values, spam.getClassProbability() returns 0.0: see the docs:
If the argument is positive zero or negative zero, then the result is negative infinity.
The Javadoc for Math explains why you get -Infinity as a result:
If the argument is positive zero or negative zero, then the result is negative infinity.
You should check your values for zeros, or filter them out prior to applying the log function.
Most likely the value of spam.getClassProbability(words.get(j)) is zero at some point.
Math.log(0.0) returns negative infinity (as the API documentation says).
If the class probability for one word is zero, then you add -Infinity to your sum.
One of your spam candidates is getting a zero from getClassProbability:
System.out.println(Math.log(0));
Output:
-Infinity
This is a special reserved double value, and any operation on it also gives -Infinity, so once it hits the zero, your summing variable will stay -Infinity
To "fix" it, do this:
double wordProbSpam = spam.getClassProbability(words.get(j));
probspam += wordProbSpam > 0 ? Math.log(wordProbSpam) : 0;
Frankly, I think your approach is flawed. I would be simply summing the result of getClassProbability(), not summing its log, because for number between 0-1 the log is negative, which will do weird things to the sum.
I think you've already had this questioned in general - you are taking the log of 0.0. Even if your getClassProbability() is perfect, numerical underflow may still mean it returns zero when mathematically speaking the result was non-zero.
One option is to replace all zeros with the value of Double.ulp(0.0). This is the smallest non-zero value Java can represent (4.9e-324) and has a log around -744.44. This recognises the game breaking concept of a zero probability. After all spammers are very clever so the probability will never truly be zero.