[jira] [Comment Edited] (MATH-1381) BinomialTest P-value > 1
[
https://issues.apache.org/jira/browse/MATH-1381?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15453154#comment-15453154
]
Kexin Xie edited comment on MATH-1381 at 8/31/16 8:01 PM:
--
Hi [~erans], thanks for looking at the PR. I agree with you that this does
seems like it's a dirty fix and mask a potential bug in the computation.
However, the main problem here is that there is one corner case that the
current algorithm did not consider. Which is that if the probability is large
enough and the success is the same as the number of trials and both numbers are
small enough, it will cause the {{criticalValueLow}} to rise too quickly and be
the same as {{criticalValueHigh}}. The if condition in L138 is suppose to check
the symmetry case when {{pLow == pHigh}}, but is not for the case when
{{criticalValueLow == criticalValueHigh}}. At that point the probability will
always jump to above 1, but it should really be 1 because {{criticalLow}} is
the same as {{criticalHigh}} already (maybe I should return 1 there?).
It may seem like a dirty fix, but I have checked against results in R, and
Python's scipy equivalent, and they produce the same value. I implemented this
way because it actually works in handling this boundary condition, and it's the
least change to the original implementation. Note that Python's scipy also uses
a similar approach to deal with estimated value rising above 1
https://github.com/scipy/scipy/blob/v0.14.0/scipy/stats/morestats.py#L1661
I've also updated the PR with more exhaustive test cases (with results cross
checked with R and scipy), please have a look again. Also I think the current
implementation is correct as explained above, but I'm happy to change the
estimation algorithm if that's required.
was (Author: kexinxie):
Hi [~erans], thanks for looking at the PR. I agree with you that this does
seems like it's a dirty fix and mask a potential bug in the computation.
However, the main problem here is that there is one corner case that the
current algorithm did not consider. Which is that if the probability is large
enough and the success is the same as the number of trials and both numbers are
small enough, it will cause the {{criticalValueLow}} to rise too quickly and be
the same as {{criticalValueHigh}}. The if condition in L138 is suppose to check
the symmetry case when {{pLow == pHigh}}, but is not for the case when
{{criticalValueLow == criticalValueHigh}}. At that point the probability will
always jump to above 1, but it should really be 1 because {{criticalLow}} is
the same as {{criticalHigh}} already (maybe I should return 1 there?).
It may seem like a dirty fix, but I have checked against results in R, and
Python's scipy equivalent, and they produce the same value. I implemented this
way because it actually works in handling this boundary condition, and it's the
least change to the original implementation. Note that Python's scipy also uses
a similar approach to deal with estimated value rising above 1
https://github.com/scipy/scipy/blob/v0.14.0/scipy/stats/morestats.py#L1661
I've also updated the PR with more exhaustive test cases, please have a look
again. Also I think the current implementation is correct as explained above,
but I'm happy to change the estimation algorithm if that's required.
> BinomialTest P-value > 1
>
>
> Key: MATH-1381
> URL: https://issues.apache.org/jira/browse/MATH-1381
> Project: Commons Math
> Issue Type: Bug
>Reporter: Wang Qiang
>
> When I use the Binomial Test, I got p-value > 1 for two sided check.
> Example:
> (new BinomialTest()).binomialTest(200, 200, 0.9950429,
> AlternativeHypothesis.TWO_SIDED) == 1.3701357550780435
> In my case, if the expected p-value is 1 (calculated by package in other
> language, scipy in this case), the p-value returned could be > 1
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (MATH-1381) BinomialTest P-value > 1
[
https://issues.apache.org/jira/browse/MATH-1381?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15453154#comment-15453154
]
Kexin Xie edited comment on MATH-1381 at 8/31/16 7:37 PM:
--
Hi [~erans], thanks for looking at the PR. I agree with you that this does
seems like it's a dirty fix and mask a potential bug in the computation.
However, the main problem here is that there is one corner case that the
current algorithm did not consider. Which is that if the probability is large
enough and the success is the same as the number of trials and both numbers are
small enough, it will cause the {{criticalValueLow}} to rise too quickly and be
the same as {{criticalValueHigh}}. The if condition in L138 is suppose to check
the symmetry case when {{pLow == pHigh}}, but is not for the case when
{{criticalValueLow == criticalValueHigh}}. At that point the probability will
always jump to above 1, but it should really be 1 because {{criticalLow}} is
the same as {{criticalHigh}} already (maybe I should return 1 there?).
It may seem like a dirty fix, but I have checked against results in R, and
Python's scipy equivalent, and they produce the same value. I implemented this
way because it actually works in handling this boundary condition, and it's the
least change to the original implementation. Note that Python's scipy also uses
a similar approach to deal with estimated value rising above 1
https://github.com/scipy/scipy/blob/v0.14.0/scipy/stats/morestats.py#L1661
I've also updated with more exhaustive test cases, please have a look again.
Also I think the current implementation is correct as explained above, but I'm
happy to change the estimation algorithm if that's required.
was (Author: kexinxie):
Hi [~erans], thanks for looking at the PR. I agree with you that this does
seems like it's a dirty fix and mask a potential bug in the computation.
However, the main problem here is that there is one corner case that the
current algorithm did not consider. Which is that if the probability is large
enough and the success is the same as the number of trials and both numbers are
small enough, it will cause the {{criticalValueLow}} to rise too quickly and be
the same as {{criticalValueHigh}}. The if condition in L138 is suppose to check
the symmetry case when {{pLow == pHigh}}, but is not for the case when
{{criticalValueLow == criticalValueHigh}}. At that point the probability will
always jump to above 1.
It may seem like a dirty fix, but I have checked against results in R, and
Python's scipy equivalent, and they produce the same value. I implemented this
way because it actually works in handling this boundary condition, and it's the
least change to the original implementation. Note that Python's scipy also uses
a similar approach to deal with estimated value rising above 1
https://github.com/scipy/scipy/blob/v0.14.0/scipy/stats/morestats.py#L1661
I've also updated with more exhaustive test cases, please have a look again.
Also I think the current implementation is correct as explained above, but I'm
happy to change the estimation algorithm if that's required.
> BinomialTest P-value > 1
>
>
> Key: MATH-1381
> URL: https://issues.apache.org/jira/browse/MATH-1381
> Project: Commons Math
> Issue Type: Bug
>Reporter: Wang Qiang
>
> When I use the Binomial Test, I got p-value > 1 for two sided check.
> Example:
> (new BinomialTest()).binomialTest(200, 200, 0.9950429,
> AlternativeHypothesis.TWO_SIDED) == 1.3701357550780435
> In my case, if the expected p-value is 1 (calculated by package in other
> language, scipy in this case), the p-value returned could be > 1
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (MATH-1381) BinomialTest P-value > 1
[
https://issues.apache.org/jira/browse/MATH-1381?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15453154#comment-15453154
]
Kexin Xie edited comment on MATH-1381 at 8/31/16 7:38 PM:
--
Hi [~erans], thanks for looking at the PR. I agree with you that this does
seems like it's a dirty fix and mask a potential bug in the computation.
However, the main problem here is that there is one corner case that the
current algorithm did not consider. Which is that if the probability is large
enough and the success is the same as the number of trials and both numbers are
small enough, it will cause the {{criticalValueLow}} to rise too quickly and be
the same as {{criticalValueHigh}}. The if condition in L138 is suppose to check
the symmetry case when {{pLow == pHigh}}, but is not for the case when
{{criticalValueLow == criticalValueHigh}}. At that point the probability will
always jump to above 1, but it should really be 1 because {{criticalLow}} is
the same as {{criticalHigh}} already (maybe I should return 1 there?).
It may seem like a dirty fix, but I have checked against results in R, and
Python's scipy equivalent, and they produce the same value. I implemented this
way because it actually works in handling this boundary condition, and it's the
least change to the original implementation. Note that Python's scipy also uses
a similar approach to deal with estimated value rising above 1
https://github.com/scipy/scipy/blob/v0.14.0/scipy/stats/morestats.py#L1661
I've also updated the PR with more exhaustive test cases, please have a look
again. Also I think the current implementation is correct as explained above,
but I'm happy to change the estimation algorithm if that's required.
was (Author: kexinxie):
Hi [~erans], thanks for looking at the PR. I agree with you that this does
seems like it's a dirty fix and mask a potential bug in the computation.
However, the main problem here is that there is one corner case that the
current algorithm did not consider. Which is that if the probability is large
enough and the success is the same as the number of trials and both numbers are
small enough, it will cause the {{criticalValueLow}} to rise too quickly and be
the same as {{criticalValueHigh}}. The if condition in L138 is suppose to check
the symmetry case when {{pLow == pHigh}}, but is not for the case when
{{criticalValueLow == criticalValueHigh}}. At that point the probability will
always jump to above 1, but it should really be 1 because {{criticalLow}} is
the same as {{criticalHigh}} already (maybe I should return 1 there?).
It may seem like a dirty fix, but I have checked against results in R, and
Python's scipy equivalent, and they produce the same value. I implemented this
way because it actually works in handling this boundary condition, and it's the
least change to the original implementation. Note that Python's scipy also uses
a similar approach to deal with estimated value rising above 1
https://github.com/scipy/scipy/blob/v0.14.0/scipy/stats/morestats.py#L1661
I've also updated with more exhaustive test cases, please have a look again.
Also I think the current implementation is correct as explained above, but I'm
happy to change the estimation algorithm if that's required.
> BinomialTest P-value > 1
>
>
> Key: MATH-1381
> URL: https://issues.apache.org/jira/browse/MATH-1381
> Project: Commons Math
> Issue Type: Bug
>Reporter: Wang Qiang
>
> When I use the Binomial Test, I got p-value > 1 for two sided check.
> Example:
> (new BinomialTest()).binomialTest(200, 200, 0.9950429,
> AlternativeHypothesis.TWO_SIDED) == 1.3701357550780435
> In my case, if the expected p-value is 1 (calculated by package in other
> language, scipy in this case), the p-value returned could be > 1
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (MATH-1381) BinomialTest P-value > 1
[
https://issues.apache.org/jira/browse/MATH-1381?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15453154#comment-15453154
]
Kexin Xie edited comment on MATH-1381 at 8/31/16 7:35 PM:
--
Hi [~erans], thanks for looking at the PR. I agree with you that this does
seems like it's a dirty fix and mask a potential bug in the computation.
However, the main problem here is that there is one corner case that the
current algorithm did not consider. Which is that if the probability is large
enough and the success is the same as the number of trials and both numbers are
small enough, it will cause the {{criticalValueLow}} to rise too quickly and be
the same as {{criticalValueHigh}}. The if condition in L138 is suppose to check
the symmetry case when {{pLow == pHigh}}, but is not for the case when
{{criticalValueLow == criticalValueHigh}}. At that point the probability will
always jump to above 1.
It may seem like a dirty fix, but I have checked against results in R, and
Python's scipy equivalent, and they produce the same value. I implemented this
way because it actually works in handling this boundary condition, and it's the
least change to the original implementation. Note that Python's scipy also uses
a similar approach to deal with estimated value rising above 1
https://github.com/scipy/scipy/blob/v0.14.0/scipy/stats/morestats.py#L1661
I've also updated with more exhaustive test cases, please have a look again.
Also I think the current implementation is correct as explained above, but I'm
happy to change the estimation algorithm if that's required.
was (Author: kexinxie):
Hi [~erans], thanks for looking at the PR. I agree with you that this does
seems like it's a dirty fix and mask a potential bug in the computation.
However, the main problem here is that there is one corner case that the
current algorithm did not consider. Which is that if the probability is large
enough and the success is the same as the number of trials and both numbers are
small enough, it will cause the {{criticalValueLow}} to rise too quickly and be
the same as {{criticalValueHigh}}. The if condition in L138 is suppose to check
the symmetry case when {{pLow == pHigh}}, but is not for the case when
{{criticalValueLow == criticalValueHigh}}. At that point the probability will
always jump to above 1.
It may seem like a dirty fix, but I have checked against results in R, and
Python's scipy equivalent, and they produce the same value. I implemented this
way because it actually works in handling this boundary condition, and it's the
least change to the original implementation. Note that Python's scipy also uses
a similar approach to deal with estimated value rising above 1
https://github.com/scipy/scipy/blob/v0.14.0/scipy/stats/morestats.py#L1661
I've also updated with more exhaustive test cases, please have a look again.
> BinomialTest P-value > 1
>
>
> Key: MATH-1381
> URL: https://issues.apache.org/jira/browse/MATH-1381
> Project: Commons Math
> Issue Type: Bug
>Reporter: Wang Qiang
>
> When I use the Binomial Test, I got p-value > 1 for two sided check.
> Example:
> (new BinomialTest()).binomialTest(200, 200, 0.9950429,
> AlternativeHypothesis.TWO_SIDED) == 1.3701357550780435
> In my case, if the expected p-value is 1 (calculated by package in other
> language, scipy in this case), the p-value returned could be > 1
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MATH-1381) BinomialTest P-value > 1
[
https://issues.apache.org/jira/browse/MATH-1381?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15453154#comment-15453154
]
Kexin Xie commented on MATH-1381:
-
Hi [~erans], thanks for looking at the PR. I agree with you that this does
seems like it's a dirty fix and mask a potential bug in the computation.
However, the main problem here is that there is one corner case that the
current algorithm did not consider. Which is that if the probability is large
enough and the success is the same as the number of trials and both numbers are
small enough, it will cause the {{criticalValueLow}} to rise too quickly and be
the same as {{criticalValueHigh}}. The if condition in L138 is suppose to check
the symmetry case when {{pLow == pHigh}}, but is not for the case when
{{criticalValueLow == criticalValueHigh}}. At that point the probability will
always jump to above 1.
It may seem like a dirty fix, but I have checked against results in R, and
Python's scipy equivalent, and they produce the same value. I implemented this
way because it actually works in handling this boundary condition, and it's the
least change to the original implementation. Note that Python's scipy also uses
a similar approach to deal with estimated value rising above 1
https://github.com/scipy/scipy/blob/v0.14.0/scipy/stats/morestats.py#L1661
I've also updated with more exhaustive test cases, please have a look again.
> BinomialTest P-value > 1
>
>
> Key: MATH-1381
> URL: https://issues.apache.org/jira/browse/MATH-1381
> Project: Commons Math
> Issue Type: Bug
>Reporter: Wang Qiang
>
> When I use the Binomial Test, I got p-value > 1 for two sided check.
> Example:
> (new BinomialTest()).binomialTest(200, 200, 0.9950429,
> AlternativeHypothesis.TWO_SIDED) == 1.3701357550780435
> In my case, if the expected p-value is 1 (calculated by package in other
> language, scipy in this case), the p-value returned could be > 1
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (LANG-992) NumberUtils#isNumber() returns false for "0.0", "0.4790", et al
[
https://issues.apache.org/jira/browse/LANG-992?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15453122#comment-15453122
]
Pascal Schumacher commented on LANG-992:
Commons is completely volunteer based. Issues are closed when somebody
contributes a fix.
> NumberUtils#isNumber() returns false for "0.0", "0.4790", et al
> ---
>
> Key: LANG-992
> URL: https://issues.apache.org/jira/browse/LANG-992
> Project: Commons Lang
> Issue Type: Bug
> Components: lang.math.*
>Affects Versions: 3.3.1
> Environment: Java 8, Windows 7
>Reporter: Adam Rauch
> Fix For: 3.3.2
>
> Attachments: LANG-992 Refactor.patch, LANG-992-v2.patch
>
>
> After upgrading from 3.1 to 3.3.1, it seems that {{isNumber(String str)}}
> returns false for decimal numbers with leading zeros. In other words:
> {code:java}
> boolean ret = NumberUtils.isNumber("0.4790");
> {code}
> On 3.1, {{ret}} was true. In 3.3.1, {{ret}} is false.
> Guessing that LANG-972 is related... comment in the code states:
> {code:java}
> // leading 0, but not hex, must be octal
> {code}
> This is clearly a case where leading 0 means neither hex nor octal.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (DAEMON-353) Websocket is not working in service installed with Apache common daemon 64 bit
Manish Prajapati created DAEMON-353: --- Summary: Websocket is not working in service installed with Apache common daemon 64 bit Key: DAEMON-353 URL: https://issues.apache.org/jira/browse/DAEMON-353 Project: Commons Daemon Issue Type: Bug Components: Procrun Affects Versions: 1.0.15 Environment: Windows Server 2008 64 bit Reporter: Manish Prajapati I am installing a service using Apache Common Daemons. When I used 32 bit jvm and 32 bit prunsrv, the service worked fine. Now I want to change it to 64 bit, so for this I used 64 bit jvm and 64 bit prunsrv. From this service got started but it is getting stuck at some point where service needs to be connected to wss url. So at below code it get stuck and not gave any error: webSocket = asyncHttpClient.prepareGet(url) .execute(new WebSocketUpgradeHandler.Builder().build()) .get(); Also service is working fine with command prompt and 64 bit Java. Seems to be an issue with prunsrv uses. Thanks. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (JEXL-215) JexlEngine.createInfo() is redundantly called when debug and caching is enabled leading to sub-optimal performance
[
https://issues.apache.org/jira/browse/JEXL-215?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Henri Biestro resolved JEXL-215.
Resolution: Fixed
Assignee: Henri Biestro
Fix Version/s: 3.1
Create default jexlinfo in parse() rather than in multiple places.
src/main/java/org/apache/commons/jexl3/internal/Engine.java
Committed revision 1758579.
> JexlEngine.createInfo() is redundantly called when debug and caching is
> enabled leading to sub-optimal performance
> --
>
> Key: JEXL-215
> URL: https://issues.apache.org/jira/browse/JEXL-215
> Project: Commons JEXL
> Issue Type: Improvement
>Affects Versions: 3.0
>Reporter: Dmitri Blinov
>Assignee: Henri Biestro
> Fix For: 3.1
>
>
> The following two methods {{Engine.createScript()}} and
> {{Engine.createExpression()}} are calling {{JexlEngine.createInfo()}} when
> debug mode is enabled and JexlInfo is not provided. But if caching is enabled
> the method {{Engine.parse()}} will not use provided JexlInfo if the requested
> statement is already in the cache. This leads to sub-optimal performance, in
> my measurements up to 100 times slower. The suggestion is to refactor by
> removing the following code
> {code}
> if (info == null && debug) {
> info = createInfo();
> }
> {code}
> from methods {{Engine.createScript()}} and {{Engine.createExpression()}} and
> adding to the method {{Engine.parse()}} after the cache check, like this
> {code}
> protected ASTJexlScript parse(JexlInfo info, String src, Scope scope,
> boolean registers, boolean expression) {
> final boolean cached = src.length() < cacheThreshold && cache != null;
> ASTJexlScript script;
> synchronized (parser) {
> if (cached) {
> script = cache.get(src);
> if (script != null) {
> Scope f = script.getScope();
> if ((f == null && scope == null) || (f != null &&
> f.equals(scope))) {
> return script;
> }
> }
> }
> if (info == null && debug) {
> info = createInfo();
> }
> script = parser.parse(info, src, scope, registers, expression);
> if (cached) {
> cache.put(src, script);
> }
> }
> return script;
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (JEXL-213) rename JexlBuilder.loader(Charset arg) to JexlBuilder.charset(Charset arg)
[
https://issues.apache.org/jira/browse/JEXL-213?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Henri Biestro resolved JEXL-213.
Resolution: Fixed
Assignee: Henri Biestro
Fix Version/s: 3.1
Add charset(Charset arg) to JexlBuilder, deprecated loader(Charset...) which is
indeed a mistake (but public API).
src/main/java/org/apache/commons/jexl3/JexlBuilder.java
Committed revision 1758578.
> rename JexlBuilder.loader(Charset arg) to JexlBuilder.charset(Charset arg)
> --
>
> Key: JEXL-213
> URL: https://issues.apache.org/jira/browse/JEXL-213
> Project: Commons JEXL
> Issue Type: Bug
>Affects Versions: 3.0
>Reporter: Dmitri Blinov
>Assignee: Henri Biestro
>Priority: Minor
> Fix For: 3.1
>
>
> There seems to be a copy-paste bug in method in {{JexlBuilder}} class
> {code}
> public JexlBuilder loader(Charset arg) {
> this.charset = arg;
> return this;
> }
> {code}
> obviously the method should be named {{charset}}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (JEXL-214) Redundant call of fillInStackTrace() in JexlEngine.createInfo() ?
[
https://issues.apache.org/jira/browse/JEXL-214?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Henri Biestro resolved JEXL-214.
Resolution: Fixed
Assignee: Henri Biestro
Fix Version/s: 3.1
src/main/java/org/apache/commons/jexl3/JexlEngine.java
Committed revision 1758577.
> Redundant call of fillInStackTrace() in JexlEngine.createInfo() ?
> -
>
> Key: JEXL-214
> URL: https://issues.apache.org/jira/browse/JEXL-214
> Project: Commons JEXL
> Issue Type: Bug
>Affects Versions: 3.0
>Reporter: Dmitri Blinov
>Assignee: Henri Biestro
> Fix For: 3.1
>
>
> I wonder what is the call of {{fillInStackTrace()}} for ?
> {code}
> public JexlInfo createInfo() {
> JexlInfo info = null;
> Throwable xinfo = new Throwable();
> xinfo.fillInStackTrace();
> ...
> {code}
> As far as I know the constructor of Throwable is implemented already calling
> this method.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (JEXL-217) Interpreter.getAttribute() raises exception in non-strict mode when cached property resolver is used
[
https://issues.apache.org/jira/browse/JEXL-217?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Henri Biestro resolved JEXL-217.
Resolution: Fixed
Assignee: Henri Biestro
Cached and non-cached calls are now protected by the same try/catch block.
src/main/java/org/apache/commons/jexl3/internal/Interpreter.java
src/main/java/org/apache/commons/jexl3/internal/Operators.java
src/test/java/org/apache/commons/jexl3/IssuesTest.java
Committed revision 1758541.
> Interpreter.getAttribute() raises exception in non-strict mode when cached
> property resolver is used
>
>
> Key: JEXL-217
> URL: https://issues.apache.org/jira/browse/JEXL-217
> Project: Commons JEXL
> Issue Type: Bug
>Affects Versions: 3.0
>Reporter: Dmitri Blinov
>Assignee: Henri Biestro
>
> I'm chasing strange bug where regardless of the {{JexlContext}} operating in
> non-strict mode the {{ArrayIndexOutOfBoundsException}} is thrown in the
> script like this
> {code}
> entity = args[0]; @lenient {copy = args[1]; xwsp = args[2]}
> {code}
> here is the stack trace
> {quote}
> Caused by: java.lang.ArrayIndexOutOfBoundsException
> at java.lang.reflect.Array.get(Native Method)
> at
> org.apache.commons.jexl3.internal.introspection.ListGetExecutor.tryInvoke(ListGetExecutor.java:88)
>
> at
> org.apache.commons.jexl3.internal.Interpreter.getAttribute(Interpreter.java:1700)
>
> at
> org.apache.commons.jexl3.internal.Interpreter.visit(Interpreter.java:945)
> at
> org.apache.commons.jexl3.parser.ASTArrayAccess.jjtAccept(ASTArrayAccess.java:18)
>
> at
> org.apache.commons.jexl3.internal.Interpreter.visit(Interpreter.java:1013)
> at
> org.apache.commons.jexl3.parser.ASTReference.jjtAccept(ASTReference.java:18)
> at
> org.apache.commons.jexl3.internal.Interpreter.executeAssign(Interpreter.java:1119)
>
> at
> org.apache.commons.jexl3.internal.Interpreter.visit(Interpreter.java:1062)
> at
> org.apache.commons.jexl3.parser.ASTAssignment.jjtAccept(ASTAssignment.java:18)
>
> at
> org.apache.commons.jexl3.internal.Interpreter.visit(Interpreter.java:578)
> at org.apache.commons.jexl3.parser.ASTBlock.jjtAccept(ASTBlock.java:18)
> at
> org.apache.commons.jexl3.internal.Interpreter.processAnnotation(Interpreter.java:1848)
>
> at
> org.apache.commons.jexl3.internal.Interpreter$1.call(Interpreter.java:1856)
> {quote}
> Unfortunately I haven't managed to create and provide reproducible test case,
> but from looking into the code I think the problem fires when the Interpreter
> tries to call cached method {{ListGetExecutor.tryInvoke()}} but does not
> catch subsequent exception.
> I rewrote the code as follows and the problem seemed to go away
> {code:title=Interpreter.java}
> ...
> Exception xcause = null;
> // attempt to reuse last executor cached in volatile JexlNode.value
> if (node != null && cache) {
> Object cached = node.jjtGetValue();
> if (cached instanceof JexlPropertyGet) {
> JexlPropertyGet vg = (JexlPropertyGet) cached;
> try {
>Object value = vg.tryInvoke(object, attribute);
>if (!vg.tryFailed(value)) {
>return value;
>}
> } catch (Exception xany) {
> xcause = xany;
> }
> }
> }
> if (xcause == null) {
>// resolve that property
>List resolvers =
> uberspect.getResolvers(operator, object);
>JexlPropertyGet vg = uberspect.getPropertyGet(resolvers, object,
> attribute);
>if (vg != null) {
>try {
>Object value = vg.invoke(object);
>// cache executor in volatile JexlNode.value
>if (node != null && cache && vg.isCacheable()) {
>node.jjtSetValue(vg);
>}
>return value;
>} catch (Exception xany) {
>xcause = xany;
>}
>}
> }
> ...
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MATH-1381) BinomialTest P-value > 1
[ https://issues.apache.org/jira/browse/MATH-1381?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15451537#comment-15451537 ] Gilles commented on MATH-1381: -- Having just looked at your proposed, I can't be sure that it fixes a potential bug in the computation. The wrong value being so much larger than the expected 1, it seems quite possible that wrong results could also be lower than 1, which your fix wouldn't fix. At first sight, it would be useful to test a whole range of values against the results provided by another implementation. > BinomialTest P-value > 1 > > > Key: MATH-1381 > URL: https://issues.apache.org/jira/browse/MATH-1381 > Project: Commons Math > Issue Type: Bug >Reporter: Wang Qiang > > When I use the Binomial Test, I got p-value > 1 for two sided check. > Example: > (new BinomialTest()).binomialTest(200, 200, 0.9950429, > AlternativeHypothesis.TWO_SIDED) == 1.3701357550780435 > In my case, if the expected p-value is 1 (calculated by package in other > language, scipy in this case), the p-value returned could be > 1 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
