I could sure be wrong about this (or perhaps out of date). It makes
sense in theory. But I can't find it in the JLS and in the bytecode I
still see it calling Math.log(), calling StrictMath.log(), FWIW. I
would actually believe a JIT would do something with this. But I still
find myself always prog
On Thu, Apr 29, 2010 at 3:29 PM, Sean Owen wrote:
> You mean "sum * Math.log(sum)"?
>
Of course. Sorry.
> javac definitely isn't allowed to do that kind of transformation -- it
> actually can't do much of anything.
>
Javac and the JIT both know that log is a pure function. They also
definit
You mean "sum * Math.log(sum)"?
That's nice, I'll go with that.
javac definitely isn't allowed to do that kind of transformation -- it
actually can't do much of anything.
ProGuard might -- it's actually a dynamite byte code optimizer and
I've been itching to get it re-integrated into the build for
I think a cap is a good thing if the error is relatively small ( < 1e-4 or
so).
Betraying my age, I usually rewrite this as this:
for (int element : elements) {
if (element > 0) {
result += element * (Math.log(element));
}
}
result -= elements.size() * Math.log(sum)
But
FWIW I had rewritten the entropy() loop to be:
for (int element : elements) {
if (element > 0) {
result += element * (Math.log(element / sum));
}
}
and then further to
double logSum = Math.log(sum);
for (int element : elements) {
if (element > 0) {
Ah yeah that's it.
So... is the better change to cap the result of logLikelihoodRatio() at 0.0?
On Thu, Apr 29, 2010 at 5:11 PM, Ted Dunning wrote:
> I suspect round-off error. In R I get this for the raw LLR:
>
>> llr(matrix(c(6,7567, 1924, 2426487), nrow=2))
> [1] 3.380607e-11
>
> A slightly
I suspect round-off error. In R I get this for the raw LLR:
> llr(matrix(c(6,7567, 1924, 2426487), nrow=2))
[1] 3.380607e-11
A slightly different implementation might well have gotten a small negative
number here.
On Thu, Apr 29, 2010 at 8:56 AM, Sean Owen wrote:
> What about Shashikant's exa
What about Shashikant's example? Unless my brain's not in gear, that
seems like a legit example, but does indeed product a negative LLR.
I was under the (perhaps incorrect) impression that negative LLR indicates
some sort of problem with the input.
On Thu, Apr 29, 2010 at 7:44 AM, Shashikant Kore wrote:
> Root LLR calculation has a minor bug. When LLR score is negative,
> square root is undefined. You can see the result for the fo
(I can easily make the fix and add a test, but is the right thing to
return 0, or instead proceed in the method with the value -sqrt(-llr)
when llr is negative?)
On Thu, Apr 29, 2010 at 12:44 PM, Shashikant Kore wrote:
> Root LLR calculation has a minor bug. When LLR score is negative,
> square r
10 matches
Mail list logo
