No reason to resolve the issue first if you are the reporter or you are sure the issue is done.
The resolve state is usually used to get a verification that the issue is fixed from the one who actually encountered the problem. Typically case to use the resolve is when a user finds a bug, reports it, then we resolve the issue, and the users closes it after testing that the fix really solves his problem. Jörn On 1/19/11 12:30 PM, William Colen (JIRA) wrote:
[ https://issues.apache.org/jira/browse/OPENNLP-59?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] William Colen resolved OPENNLP-59. ---------------------------------- Resolution: FixedBad precision using FMeasure ---------------------------- Key: OPENNLP-59 URL: https://issues.apache.org/jira/browse/OPENNLP-59 Project: OpenNLP Issue Type: Bug Affects Versions: tools-1.5.1-incubating Reporter: William Colen Assignee: William Colen Fix For: tools-1.5.1-incubating I noticed bad precision in FMeasure results. I think the issue is that the current implementation is summing divisions. It computes the precision and recall for every sample, and after adds the results for each sample to compute the overall result. By doing that, the error related to each division are summed and can impact the final result. I found the problem while implementing the ChunkerEvaluator. To verify the evaluator I tried to compare the results we get using OpenNLP and the Perl script conlleval available at http://www.cnts.ua.ac.be/conll2000/chunking/output.html. The results were always different if I process more than one sentence, because the implementation was using FMeasure.updateScores() that was summing divisions. To solve that and have the same results provided by conll I basically stopped using the Mean class.
