[jira] [Commented] (DIGESTER-158) Use Java6 annotation processing to generate RulesModule instances at compile-time
[
https://issues.apache.org/jira/browse/DIGESTER-158?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13170816#comment-13170816
]
Simone Tripodi commented on DIGESTER-158:
-
yes, definitively :)
> Use Java6 annotation processing to generate RulesModule instances at
> compile-time
> -
>
> Key: DIGESTER-158
> URL: https://issues.apache.org/jira/browse/DIGESTER-158
> Project: Commons Digester
> Issue Type: New Feature
>Affects Versions: 3.2
>Reporter: Simone Tripodi
>Assignee: Simone Tripodi
> Fix For: 3.3
>
>
> Implement a
> [http://docs.oracle.com/javase/6/docs/api/javax/annotation/processing/Processor.html]
> to process Digester annotations rules and generate {{RulesModule}} instances
> at compile time.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (DIGESTER-158) Use Java6 annotation processing to generate RulesModule instances at compile-time
[
https://issues.apache.org/jira/browse/DIGESTER-158?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Matt Benson updated DIGESTER-158:
-
Description: Implement a
[http://docs.oracle.com/javase/6/docs/api/javax/annotation/processing/Processor.html]
to process Digester annotations rules and generate {{RulesModule}} instances
at compile time. (was: Using the [APT
Tool|http://download.oracle.com/javase/1,5.0/docs/guide/apt/GettingStarted.html]
it would be possible to process Digester annotations rules and generate
{{RulesModule}} instances at compile time.)
> Use Java6 annotation processing to generate RulesModule instances at
> compile-time
> -
>
> Key: DIGESTER-158
> URL: https://issues.apache.org/jira/browse/DIGESTER-158
> Project: Commons Digester
> Issue Type: New Feature
>Affects Versions: 3.2
>Reporter: Simone Tripodi
>Assignee: Simone Tripodi
> Fix For: 3.3
>
>
> Implement a
> [http://docs.oracle.com/javase/6/docs/api/javax/annotation/processing/Processor.html]
> to process Digester annotations rules and generate {{RulesModule}} instances
> at compile time.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (DIGESTER-158) Use the APT to process Digester Annotations and generate RulesModule instances at compile-time
[
https://issues.apache.org/jira/browse/DIGESTER-158?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13170759#comment-13170759
]
Matt Benson commented on DIGESTER-158:
--
I think the problem here is that Simo and I are both such n00bs wrt annotation
processing that we erroneously referred to the newer, Java 6-based facilities
as APT. ;)
> Use the APT to process Digester Annotations and generate RulesModule
> instances at compile-time
> --
>
> Key: DIGESTER-158
> URL: https://issues.apache.org/jira/browse/DIGESTER-158
> Project: Commons Digester
> Issue Type: New Feature
>Affects Versions: 3.2
>Reporter: Simone Tripodi
>Assignee: Simone Tripodi
> Fix For: 3.3
>
>
> Using the [APT
> Tool|http://download.oracle.com/javase/1,5.0/docs/guide/apt/GettingStarted.html]
> it would be possible to process Digester annotations rules and generate
> {{RulesModule}} instances at compile time.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (DIGESTER-158) Use Java6 annotation processing to generate RulesModule instances at compile-time
[
https://issues.apache.org/jira/browse/DIGESTER-158?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Matt Benson updated DIGESTER-158:
-
Summary: Use Java6 annotation processing to generate RulesModule instances
at compile-time (was: Use the APT to process Digester Annotations and generate
RulesModule instances at compile-time)
> Use Java6 annotation processing to generate RulesModule instances at
> compile-time
> -
>
> Key: DIGESTER-158
> URL: https://issues.apache.org/jira/browse/DIGESTER-158
> Project: Commons Digester
> Issue Type: New Feature
>Affects Versions: 3.2
>Reporter: Simone Tripodi
>Assignee: Simone Tripodi
> Fix For: 3.3
>
>
> Using the [APT
> Tool|http://download.oracle.com/javase/1,5.0/docs/guide/apt/GettingStarted.html]
> it would be possible to process Digester annotations rules and generate
> {{RulesModule}} instances at compile time.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (NET-431) Site report list links to source and test xref, but they are not present
Site report list links to source and test xref, but they are not present Key: NET-431 URL: https://issues.apache.org/jira/browse/NET-431 Project: Commons Net Issue Type: Bug Affects Versions: 3.0.1 Reporter: Sebb Priority: Minor Something must have gone wrong with site generation or upload, because the xrefs are referenced but not present. This JIRA is to ensure these are checked for the next release. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MATH-717) A varied class of Array2DRowRealMatrix is needed to contain float type instead of double.
[ https://issues.apache.org/jira/browse/MATH-717?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13170687#comment-13170687 ] Dusan Ku commented on MATH-717: --- Noted well. Thanks > A varied class of Array2DRowRealMatrix is needed to contain float type > instead of double. > - > > Key: MATH-717 > URL: https://issues.apache.org/jira/browse/MATH-717 > Project: Commons Math > Issue Type: Improvement >Affects Versions: 2.2 > Environment: All >Reporter: Dusan Ku > Labels: features > > The current implementation of Array2DRowRealMatrix takes only double type as > its base element value in the matrix. > However, the memory size of double is bigger than float, the downside of > which makes the matrix dimension quite limited, compared to float type as its > base element type. For small sized problem, this does not make such a big > difference, but for large problems, this limits the usability of this library > quite severely. In my case, I easily hit an error even after I increase the > memory option to 1G. This could have been much more enhanced just by using > 'float[][]' instead of the current Array2DRowRealMatrix. > Therefore, the solution I may suggest is to add another class similar to > Array2DRowRealMatrix containing float type for its matrix variable instead of > double. Of course, a better way is welcome as long as the needs can be > fulfilled. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MATH-718) inverseCumulativeProbability of BinomialDistribution returns wrong value for large trials.
[
https://issues.apache.org/jira/browse/MATH-718?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13170599#comment-13170599
]
Christian Winter commented on MATH-718:
---
There seem to be stability problems with Beta.regularizedBeta(...) when using
extreme parameters.
{{PascalDistribution.cumulativeProbability(Integer.MAX_VALUE)}} returns {{NaN}}
instead of 1. We should look for a way to avoid both infinite values and NaNs
in the implementation of the regularized beta function.
> inverseCumulativeProbability of BinomialDistribution returns wrong value for
> large trials.
> --
>
> Key: MATH-718
> URL: https://issues.apache.org/jira/browse/MATH-718
> Project: Commons Math
> Issue Type: Bug
>Affects Versions: 2.2, 3.0
>Reporter: Yuji Uchiyama
>
> The inverseCumulativeProbability method of the BinomialDistributionImpl class
> returns wrong value for large trials. Following code will be reproduce the
> problem.
> {{System.out.println(new BinomialDistributionImpl(100,
> 0.5).inverseCumulativeProbability(0.5));}}
> This returns 499525, though it should be 49.
> I'm not sure how it should be fixed, but the cause is that the
> cumulativeProbability method returns Infinity, not NaN. As the result the
> checkedCumulativeProbability method doesn't work as expected.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MATH-692) Cumulative probability and inverse cumulative probability inconsistencies
[
https://issues.apache.org/jira/browse/MATH-692?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13170588#comment-13170588
]
Christian Winter commented on MATH-692:
---
Hi Sébastien,
my changes in the integer distributions don't solve MATH-718. Instead I found a
probably related problem with the Pascal distribution.
The integer distribution patch for this issue still isn't ready. I will provide
it next week.
Christian
> Cumulative probability and inverse cumulative probability inconsistencies
> -
>
> Key: MATH-692
> URL: https://issues.apache.org/jira/browse/MATH-692
> Project: Commons Math
> Issue Type: Bug
>Affects Versions: 1.0, 1.1, 1.2, 1.3, 2.0, 2.1, 2.2, 2.2.1, 3.0
>Reporter: Christian Winter
>Priority: Minor
> Fix For: 3.0
>
> Attachments: Math-692_realDomain_patch1.patch
>
>
> There are some inconsistencies in the documentation and implementation of
> functions regarding cumulative probabilities and inverse cumulative
> probabilities. More precisely, '<' and '<=' are not used in a consistent way.
> Besides I would move the function inverseCumulativeProbability(double) to the
> interface Distribution. A true inverse of the distribution function does
> neither exist for Distribution nor for ContinuosDistribution. Thus we need to
> define the inverse in terms of quantiles anyway, and this can already be done
> for Distribution.
> On the whole I would declare the (inverse) cumulative probability functions
> in the basic distribution interfaces as follows:
> Distribution:
> - cumulativeProbability(double x): returns P(X <= x)
> - cumulativeProbability(double x0, double x1): returns P(x0 < X <= x1) [see
> also 1)]
> - inverseCumulativeProbability(double p):
> returns the quantile function inf{x in R | P(X<=x) >= p} [see also 2), 3),
> and 4)]
> 1) An aternative definition could be P(x0 <= X <= x1). But this requires to
> put the function probability(double x) or another cumulative probability
> function into the interface Distribution in order be able to calculate P(x0
> <= X <= x1) in AbstractDistribution.
> 2) This definition is stricter than the definition in ContinuousDistribution,
> because the definition there does not specify what to do if there are
> multiple x satisfying P(X<=x) = p.
> 3) A modification could be defined for p=0: Returning sup{x in R | P(X<=x) =
> 0} would yield the infimum of the distribution's support instead of a
> mandatory -infinity.
> 4) This affects issue MATH-540. I'd prefere the definition from above for the
> following reasons:
> - This definition simplifies inverse transform sampling (as mentioned in the
> other issue).
> - It is the standard textbook definition for the quantile function.
> - For integer distributions it has the advantage that the result doesn't
> change when switching to "x in Z", i.e. the result is independent of
> considering the intergers as sole set or as part of the reals.
> ContinuousDistribution:
> nothing to be added regarding (inverse) cumulative probability functions
> IntegerDistribution:
> - cumulativeProbability(int x): returns P(X <= x)
> - cumulativeProbability(int x0, int x1): returns P(x0 < X <= x1) [see also 1)
> above]
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (JEXL-124) Array parameters to methods don't work anymore
[
https://issues.apache.org/jira/browse/JEXL-124?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Henri Biestro resolved JEXL-124.
Resolution: Fixed
Fix Version/s: 2.1.1
Fixed in 2.0 branch
> Array parameters to methods don't work anymore
> --
>
> Key: JEXL-124
> URL: https://issues.apache.org/jira/browse/JEXL-124
> Project: Commons JEXL
> Issue Type: Bug
>Affects Versions: 2.1
>Reporter: Jeff Schnitzer
>Assignee: Henri Biestro
> Fix For: 2.1.1
>
>
> I have some code that worked in 2.0.1 and fails in 2.1. It looks like this:
> ${tool.jsbuilder(['form2js', 'js2form', 'jquery.dirtyform'])}
> (it's being called from a cambridge template, but that doesn't matter). The
> jsbuilder() method simply takes a String[].
> Now it throws an exception, the exact nature of which is getting eaten by
> something. The error message looks like "Could not execute the expression:
> Error evaluating exception on line: 13, column: 15, expression:
> tool.jsbuilder(["... and then the parameters.
> Sorry about not making a nice test case out of this but I'm in a hurry and
> reverting to 2.0.1 for now.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (JEXL-124) Array parameters to methods don't work anymore
[
https://issues.apache.org/jira/browse/JEXL-124?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13170565#comment-13170565
]
Henri Biestro commented on JEXL-124:
Committed fix revision 1214986.
Seems like a regression induced by the fix for JEXL-101.
> Array parameters to methods don't work anymore
> --
>
> Key: JEXL-124
> URL: https://issues.apache.org/jira/browse/JEXL-124
> Project: Commons JEXL
> Issue Type: Bug
>Affects Versions: 2.1
>Reporter: Jeff Schnitzer
>Assignee: Henri Biestro
>
> I have some code that worked in 2.0.1 and fails in 2.1. It looks like this:
> ${tool.jsbuilder(['form2js', 'js2form', 'jquery.dirtyform'])}
> (it's being called from a cambridge template, but that doesn't matter). The
> jsbuilder() method simply takes a String[].
> Now it throws an exception, the exact nature of which is getting eaten by
> something. The error message looks like "Could not execute the expression:
> Error evaluating exception on line: 13, column: 15, expression:
> tool.jsbuilder(["... and then the parameters.
> Sorry about not making a nice test case out of this but I'm in a hurry and
> reverting to 2.0.1 for now.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (JEXL-124) Array parameters to methods don't work anymore
[
https://issues.apache.org/jira/browse/JEXL-124?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13170530#comment-13170530
]
Henri Biestro commented on JEXL-124:
Reproduced on test case, something about
org.apache.commons.jexl2.internal.MethodExecutor handleVarArgs.
> Array parameters to methods don't work anymore
> --
>
> Key: JEXL-124
> URL: https://issues.apache.org/jira/browse/JEXL-124
> Project: Commons JEXL
> Issue Type: Bug
>Affects Versions: 2.1
>Reporter: Jeff Schnitzer
>Assignee: Henri Biestro
>
> I have some code that worked in 2.0.1 and fails in 2.1. It looks like this:
> ${tool.jsbuilder(['form2js', 'js2form', 'jquery.dirtyform'])}
> (it's being called from a cambridge template, but that doesn't matter). The
> jsbuilder() method simply takes a String[].
> Now it throws an exception, the exact nature of which is getting eaten by
> something. The error message looks like "Could not execute the expression:
> Error evaluating exception on line: 13, column: 15, expression:
> tool.jsbuilder(["... and then the parameters.
> Sorry about not making a nice test case out of this but I'm in a hurry and
> reverting to 2.0.1 for now.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (JEXL-124) Array parameters to methods don't work anymore
Array parameters to methods don't work anymore
--
Key: JEXL-124
URL: https://issues.apache.org/jira/browse/JEXL-124
Project: Commons JEXL
Issue Type: Bug
Affects Versions: 2.1
Reporter: Jeff Schnitzer
I have some code that worked in 2.0.1 and fails in 2.1. It looks like this:
${tool.jsbuilder(['form2js', 'js2form', 'jquery.dirtyform'])}
(it's being called from a cambridge template, but that doesn't matter). The
jsbuilder() method simply takes a String[].
Now it throws an exception, the exact nature of which is getting eaten by
something. The error message looks like "Could not execute the expression:
Error evaluating exception on line: 13, column: 15, expression:
tool.jsbuilder(["... and then the parameters.
Sorry about not making a nice test case out of this but I'm in a hurry and
reverting to 2.0.1 for now.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MATH-717) A varied class of Array2DRowRealMatrix is needed to contain float type instead of double.
[ https://issues.apache.org/jira/browse/MATH-717?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13170156#comment-13170156 ] Gilles commented on MATH-717: - bq. Last but not the least, do you think it's worth adding 'revised simplex method' to CM for solving a typical linear programming? [...] Please post this question on the "dev" ML, where it will catch the attention of more people. If what you propose "is proven to be faster", I'm sure that it will be welcome. And if its implementation would require changes in the existing API, _now_ is the time to do it, before the upcoming release of CM version 3. Thanks. > A varied class of Array2DRowRealMatrix is needed to contain float type > instead of double. > - > > Key: MATH-717 > URL: https://issues.apache.org/jira/browse/MATH-717 > Project: Commons Math > Issue Type: Improvement >Affects Versions: 2.2 > Environment: All >Reporter: Dusan Ku > Labels: features > > The current implementation of Array2DRowRealMatrix takes only double type as > its base element value in the matrix. > However, the memory size of double is bigger than float, the downside of > which makes the matrix dimension quite limited, compared to float type as its > base element type. For small sized problem, this does not make such a big > difference, but for large problems, this limits the usability of this library > quite severely. In my case, I easily hit an error even after I increase the > memory option to 1G. This could have been much more enhanced just by using > 'float[][]' instead of the current Array2DRowRealMatrix. > Therefore, the solution I may suggest is to add another class similar to > Array2DRowRealMatrix containing float type for its matrix variable instead of > double. Of course, a better way is welcome as long as the needs can be > fulfilled. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CONFIGURATION-472) SubnodeConfigurations returned by XMLConfiguration should convert added nodes to XML nodes.
[ https://issues.apache.org/jira/browse/CONFIGURATION-472?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Raimund Klein updated CONFIGURATION-472: Description: Problem description: XMLConfiguration's configuration(s)At return regular SubnodeConfigurations which can't "really" be used for adding nodes as these won't be converted into XMLConfiguration's internal XMLNodes. More precisely, when using the SubnodeConfiguration for adding, accesses to the main XMLConfiguration can run into ClassCastExceptions later on. Workaround: Add the created nodes directly to the main XMLConfiguration (e.g. with the appropriate XPath), as this configuration's add methods convert these into the internal form. Proposed Solution: Let XMLConfiguration's configuration(s)At methods return a subclass of SubnodeConfiguration whose add methods will perform the same node conversion. Consequently, this new class' SubnodeConfigurations returned by configuration(s)At should be instances of the very same class. was: Problem description: XMLConfiguration's configuration(s)At return regular SubnodeConfigurations which can't "really" be used for adding nodes as these won't be converted into XMLConfiguration's internal XMLNodes. More precisely, when using the SubnodeConfiguration for adding, accesses to the main XMLConfiguration can run into ClassCastExceptions later on. Workaround: Add the created nodes directly to the main XMLConfiguration (e.g. with the appropriate XPath), as this configuration's add methods convert these into the internal form. Proposed Solution: Let XMLConfiguration's configuration(s)At methods return a subclass of SubnodeConfiguration, whose add methods will perform the same node conversion. Consequently, this new class' SubnodeConfigurations returned by configuration(s)At should be instances of the very same class. > SubnodeConfigurations returned by XMLConfiguration should convert added nodes > to XML nodes. > --- > > Key: CONFIGURATION-472 > URL: https://issues.apache.org/jira/browse/CONFIGURATION-472 > Project: Commons Configuration > Issue Type: Improvement >Affects Versions: 1.7 >Reporter: Raimund Klein >Priority: Minor > > Problem description: XMLConfiguration's configuration(s)At return regular > SubnodeConfigurations which can't "really" be used for adding nodes as these > won't be converted into XMLConfiguration's internal XMLNodes. More precisely, > when using the SubnodeConfiguration for adding, accesses to the main > XMLConfiguration can run into ClassCastExceptions later on. > Workaround: Add the created nodes directly to the main XMLConfiguration (e.g. > with the appropriate XPath), as this configuration's add methods convert > these into the internal form. > Proposed Solution: Let XMLConfiguration's configuration(s)At methods return a > subclass of SubnodeConfiguration whose add methods will perform the same node > conversion. Consequently, this new class' SubnodeConfigurations returned by > configuration(s)At should be instances of the very same class. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (LANG-782) Specialized StringBuilder to allow simple creating of Strings from base Strings with variable arguments and proper punctuation
[ https://issues.apache.org/jira/browse/LANG-782?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13170134#comment-13170134 ] Sebb commented on LANG-782: --- Arguments could be objects, as for String.format() > Specialized StringBuilder to allow simple creating of Strings from base > Strings with variable arguments and proper punctuation > -- > > Key: LANG-782 > URL: https://issues.apache.org/jira/browse/LANG-782 > Project: Commons Lang > Issue Type: New Feature > Components: lang.builder.* >Affects Versions: 3.x >Reporter: Darryl Smith >Priority: Minor > Attachments: EnhancedBuilder.java > > Original Estimate: 24h > Remaining Estimate: 24h > > Programmers frequently encounter a situation where there is a need to display > messages to users. This functionality is useful where there are logical rules > around how to punctuate lists of items or other situations. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CONFIGURATION-472) SubnodeConfigurations returned by XMLConfiguration should convert added nodes to XML nodes.
[ https://issues.apache.org/jira/browse/CONFIGURATION-472?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Raimund Klein updated CONFIGURATION-472: Priority: Minor (was: Major) Description: XMLConfiguration's configuration(s)At return regular SubnodeConfigurations which can't "really" be used for adding nodes as these won't be converted into XMLConfiguration's internal XMLNodes. More precisely, when using the SubnodeConfiguration for adding, accesses to the main XMLConfiguration can run into ClassCastExceptions later on. Workaround: Adding the created nodes directly to the main XMLConfiguration (e.g. with the appropriate XPath), as this configuration's add methods convert these into the internal form. Proposed Solution: Let XMLConfiguration's configuration(s)At methods return a subclass of SubnodeConfiguration, whose add methods will perform the same node conversion. Consequently, this new class' SubnodeConfigurations returned by configuration(s)At should be instances of the very same class. Issue Type: Improvement (was: Bug) Summary: SubnodeConfigurations returned by XMLConfiguration should convert added nodes to XML nodes. (was: XMLConfiguration) > SubnodeConfigurations returned by XMLConfiguration should convert added nodes > to XML nodes. > --- > > Key: CONFIGURATION-472 > URL: https://issues.apache.org/jira/browse/CONFIGURATION-472 > Project: Commons Configuration > Issue Type: Improvement >Affects Versions: 1.7 >Reporter: Raimund Klein >Priority: Minor > > XMLConfiguration's configuration(s)At return regular SubnodeConfigurations > which can't "really" be used for adding nodes as these won't be converted > into XMLConfiguration's internal XMLNodes. More precisely, when using the > SubnodeConfiguration for adding, accesses to the main XMLConfiguration can > run into ClassCastExceptions later on. > Workaround: Adding the created nodes directly to the main XMLConfiguration > (e.g. with the appropriate XPath), as this configuration's add methods > convert these into the internal form. > Proposed Solution: Let XMLConfiguration's configuration(s)At methods return a > subclass of SubnodeConfiguration, whose add methods will perform the same > node conversion. Consequently, this new class' SubnodeConfigurations returned > by configuration(s)At should be instances of the very same class. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CONFIGURATION-472) SubnodeConfigurations returned by XMLConfiguration should convert added nodes to XML nodes.
[ https://issues.apache.org/jira/browse/CONFIGURATION-472?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Raimund Klein updated CONFIGURATION-472: Description: Problem description: XMLConfiguration's configuration(s)At return regular SubnodeConfigurations which can't "really" be used for adding nodes as these won't be converted into XMLConfiguration's internal XMLNodes. More precisely, when using the SubnodeConfiguration for adding, accesses to the main XMLConfiguration can run into ClassCastExceptions later on. Workaround: Add the created nodes directly to the main XMLConfiguration (e.g. with the appropriate XPath), as this configuration's add methods convert these into the internal form. Proposed Solution: Let XMLConfiguration's configuration(s)At methods return a subclass of SubnodeConfiguration, whose add methods will perform the same node conversion. Consequently, this new class' SubnodeConfigurations returned by configuration(s)At should be instances of the very same class. was: XMLConfiguration's configuration(s)At return regular SubnodeConfigurations which can't "really" be used for adding nodes as these won't be converted into XMLConfiguration's internal XMLNodes. More precisely, when using the SubnodeConfiguration for adding, accesses to the main XMLConfiguration can run into ClassCastExceptions later on. Workaround: Adding the created nodes directly to the main XMLConfiguration (e.g. with the appropriate XPath), as this configuration's add methods convert these into the internal form. Proposed Solution: Let XMLConfiguration's configuration(s)At methods return a subclass of SubnodeConfiguration, whose add methods will perform the same node conversion. Consequently, this new class' SubnodeConfigurations returned by configuration(s)At should be instances of the very same class. > SubnodeConfigurations returned by XMLConfiguration should convert added nodes > to XML nodes. > --- > > Key: CONFIGURATION-472 > URL: https://issues.apache.org/jira/browse/CONFIGURATION-472 > Project: Commons Configuration > Issue Type: Improvement >Affects Versions: 1.7 >Reporter: Raimund Klein >Priority: Minor > > Problem description: XMLConfiguration's configuration(s)At return regular > SubnodeConfigurations which can't "really" be used for adding nodes as these > won't be converted into XMLConfiguration's internal XMLNodes. More precisely, > when using the SubnodeConfiguration for adding, accesses to the main > XMLConfiguration can run into ClassCastExceptions later on. > Workaround: Add the created nodes directly to the main XMLConfiguration (e.g. > with the appropriate XPath), as this configuration's add methods convert > these into the internal form. > Proposed Solution: Let XMLConfiguration's configuration(s)At methods return a > subclass of SubnodeConfiguration, whose add methods will perform the same > node conversion. Consequently, this new class' SubnodeConfigurations returned > by configuration(s)At should be instances of the very same class. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (LANG-782) Specialized StringBuilder to allow simple creating of Strings from base Strings with variable arguments and proper punctuation
[ https://issues.apache.org/jira/browse/LANG-782?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13170130#comment-13170130 ] Darryl Smith commented on LANG-782: --- List of arguments makes sense if all the items are the same type. I personally don't use it in the single shot fashion like String#format, instead I use it throughout a Servlet while testing passed in parameters. > Specialized StringBuilder to allow simple creating of Strings from base > Strings with variable arguments and proper punctuation > -- > > Key: LANG-782 > URL: https://issues.apache.org/jira/browse/LANG-782 > Project: Commons Lang > Issue Type: New Feature > Components: lang.builder.* >Affects Versions: 3.x >Reporter: Darryl Smith >Priority: Minor > Attachments: EnhancedBuilder.java > > Original Estimate: 24h > Remaining Estimate: 24h > > Programmers frequently encounter a situation where there is a need to display > messages to users. This functionality is useful where there are logical rules > around how to punctuate lists of items or other situations. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CONFIGURATION-472) XMLConfiguration
XMLConfiguration Key: CONFIGURATION-472 URL: https://issues.apache.org/jira/browse/CONFIGURATION-472 Project: Commons Configuration Issue Type: Bug Affects Versions: 1.7 Reporter: Raimund Klein -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (LANG-782) Specialized StringBuilder to allow simple creating of Strings from base Strings with variable arguments and proper punctuation
[ https://issues.apache.org/jira/browse/LANG-782?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13170125#comment-13170125 ] Sebb commented on LANG-782: --- List of arguments might be easier to use (and simpler to implement) if it were an array; the toString() method could then be dropped. It would then be more like String#format(). > Specialized StringBuilder to allow simple creating of Strings from base > Strings with variable arguments and proper punctuation > -- > > Key: LANG-782 > URL: https://issues.apache.org/jira/browse/LANG-782 > Project: Commons Lang > Issue Type: New Feature > Components: lang.builder.* >Affects Versions: 3.x >Reporter: Darryl Smith >Priority: Minor > Attachments: EnhancedBuilder.java > > Original Estimate: 24h > Remaining Estimate: 24h > > Programmers frequently encounter a situation where there is a need to display > messages to users. This functionality is useful where there are logical rules > around how to punctuate lists of items or other situations. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (POOL-206) GOP/GKOP close() - incorrect behaviour with evict() ?
GOP/GKOP close() - incorrect behaviour with evict() ? - Key: POOL-206 URL: https://issues.apache.org/jira/browse/POOL-206 Project: Commons Pool Issue Type: Bug Reporter: Sebb GOP/GKOP close() methods close the pool before stopping the evictor; that seems wrong. The evict() method calls assertOpen() so the evictor thread should be stopped before closing the pool. Also, the evictor thread should probably be allowed to complete if currently active. Not sure about calling clear() before the evictor is cancelled; should perhaps be run afterwards? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (LANG-782) Specialized StringBuilder to allow simple creating of Strings from base Strings with variable arguments and proper punctuation
[ https://issues.apache.org/jira/browse/LANG-782?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darryl Smith updated LANG-782: -- Attachment: EnhancedBuilder.java A working PoC with a 'test case ' in the main method. > Specialized StringBuilder to allow simple creating of Strings from base > Strings with variable arguments and proper punctuation > -- > > Key: LANG-782 > URL: https://issues.apache.org/jira/browse/LANG-782 > Project: Commons Lang > Issue Type: New Feature > Components: lang.builder.* >Affects Versions: 3.x >Reporter: Darryl Smith >Priority: Minor > Attachments: EnhancedBuilder.java > > Original Estimate: 24h > Remaining Estimate: 24h > > Programmers frequently encounter a situation where there is a need to display > messages to users. This functionality is useful where there are logical rules > around how to punctuate lists of items or other situations. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (LANG-782) Specialized StringBuilder to allow simple creating of Strings from base Strings with variable arguments and proper punctuation
Specialized StringBuilder to allow simple creating of Strings from base Strings with variable arguments and proper punctuation -- Key: LANG-782 URL: https://issues.apache.org/jira/browse/LANG-782 Project: Commons Lang Issue Type: New Feature Components: lang.builder.* Affects Versions: 3.x Reporter: Darryl Smith Priority: Minor Programmers frequently encounter a situation where there is a need to display messages to users. This functionality is useful where there are logical rules around how to punctuate lists of items or other situations. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CLI-224) OptionBuilder only has static methods, yet many return an OptionBuilder instance
[
https://issues.apache.org/jira/browse/CLI-224?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13170117#comment-13170117
]
Emmanuel Bourg commented on CLI-224:
Thank you for the code Brian, a revamped builder could be included in the 1.x
line, but I'm still hesitating on the proper way do to it. The existing
OptionBuilder can't be changed due to binary compatibility issues, so another
class has to provide the builder mechanism. I haven't found an elegant solution
yet: "DefaultOptionBuilder" looks a bit heavy, "Options" is already used,
"OptBuilder" is shorter but probably less explicit.
The solution might be to add chained withXXX() setters to the Option class.
Building an option would then look like this:
{code}new Option("f").withLongOpt("file").withDescription("Input
file").withArg();{code}
Any input on this matter is welcome.
> OptionBuilder only has static methods, yet many return an OptionBuilder
> instance
>
>
> Key: CLI-224
> URL: https://issues.apache.org/jira/browse/CLI-224
> Project: Commons CLI
> Issue Type: Bug
> Components: CLI-1.x
>Affects Versions: 1.2
>Reporter: Brian Blount
> Attachments: DefaultOptionBuilder.java, DefaultOptionBuilderTest.java
>
>
> CLI-83 was closed as fixed in 2.0, but it seems that there is no current plan
> to release CLI 2.0. Could this fix be rolled into the 1.x line? I'm
> attaching a new version of option builder that addresses the issue (named
> DefaultOptionBuilder to maintain backwards compatability) and a unit test for
> it.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (POOL-205) GKOP - inconsistent synchronisation of poolKeyList
GKOP - inconsistent synchronisation of poolKeyList -- Key: POOL-205 URL: https://issues.apache.org/jira/browse/POOL-205 Project: Commons Pool Issue Type: Bug Reporter: Sebb poolKeyList is an ArrayList - which is not thread-safe. Updates are performed whilst holding the keyLock.writeLock. However, the list is read in evict() without using the same lock, so there's a potential for evict() to see stale or inconsistent state. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (POOL-205) GKOP - inconsistent synchronisation of poolKeyList
[ https://issues.apache.org/jira/browse/POOL-205?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebb updated POOL-205: -- Affects Version/s: 2.0 > GKOP - inconsistent synchronisation of poolKeyList > -- > > Key: POOL-205 > URL: https://issues.apache.org/jira/browse/POOL-205 > Project: Commons Pool > Issue Type: Bug >Affects Versions: 2.0 >Reporter: Sebb > > poolKeyList is an ArrayList - which is not thread-safe. > Updates are performed whilst holding the keyLock.writeLock. > However, the list is read in evict() without using the same lock, so there's > a potential for evict() to see stale or inconsistent state. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (POOL-204) GKOP encapsulate poolMap/poolKeyList to ensure invariants?
GKOP encapsulate poolMap/poolKeyList to ensure invariants? -- Key: POOL-204 URL: https://issues.apache.org/jira/browse/POOL-204 Project: Commons Pool Issue Type: Improvement Affects Versions: 2.0 Reporter: Sebb Priority: Minor In GKOP, poolMap and poolKeyList must be kept in step otherwise "bad things will happen!". Might be worth considering encapsulating the data structures in a private class that ensures this. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Issue Comment Edited] (MATH-644) for the class of hyper-geometric distribution, for some number the method "upperCumulativeProbability" return a probability greater than 1 which is impossible.
[
https://issues.apache.org/jira/browse/MATH-644?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13159987#comment-13159987
]
Thomas Neidhart edited comment on MATH-644 at 12/15/11 8:53 AM:
I digged a bit into the problem. The HypergeometricDistribution calculates the
probability for a given x using the following formula:
{code:java}
private double probability(int n, int m, int k, int x) {
return FastMath.exp(ArithmeticUtils.binomialCoefficientLog(m, x) +
ArithmeticUtils.binomialCoefficientLog(n - m, k - x) -
ArithmeticUtils.binomialCoefficientLog(n, k));
}
{code}
Thus it transforms the binomial coefficients to a logarithmic scale in order to
cope with the possibly large results (and to be able to compute the bincoeff at
all). But, imho, the reverse transformation is broken, as it does not take any
scaling into account. As the coefficients get larger (e.g. due to a large n),
the differences between the terms will become smaller in log scale, and thus
incorrectly transformed back to linear scale. Taking scaling into account, the
exp function will most likely fail for large n.
I have created a simple test to illustrate the problem, the t{x} correspond to
the binomial coeff terms from the formula, diff is the input the the exp
function. This loop simulates an increasing n, and the expectation is that the
result should get smaller with increasing n:
{code}
t1=0.0, t2=4547.288942497606, t3=4770.9627189150215, diff=-223.67377641741587,
result=7.23957639711833E-98
t1=0.0, t2=12183.221706275828, t3=12186.968419291079, diff=-3.7467130152508616,
result=0.023595175513309037
t1=0.0, t2=13444.672093808651, t3=13446.561352727935, diff=-1.8892589192837477,
result=0.15118380673528464
t1=0.0, t2=14186.229425843805, t3=14187.492505971342, diff=-1.2630801275372505,
result=0.2827816800804864
t1=0.0, t2=14713.395226772875, t3=14714.343882929534, diff=-0.9486561566591263,
result=0.3872610921706871
t1=0.0, t2=15122.726785860956, t3=15123.486358374357, diff=-0.7595725134015083,
result=0.46786639087791215
t1=0.0, t2=15457.396298892796, t3=15458.029636271298, diff=-0.673785018921,
result=0.5308173033122051
t1=0.0, t2=15740.484181590378, t3=15741.027263000607, diff=-0.5430814102292061,
result=0.5809553297318205
t1=0.0, t2=15985.787659011781, t3=15986.263000234962,
diff=-0.47534122318029404, result=0.6216728910682101
t1=0.0, t2=16202.21559868753, t3=16202.638224512339, diff=-0.4226258248090744,
result=0.6553237931479635
t1=0.0, t2=16395.855738580227, t3=16396.236174091697, diff=-0.380435511469841,
result=0.6835636445695273
{code}
hmm, after some second thoughts, I am not sure if the analysis is correct, and
the problem is hidden somewhere else.
was (Author: tn):
I digged a bit into the problem. The HypergeometricDistribution calculates
the probability for a given x using the following formula:
{code:java}
private double probability(int n, int m, int k, int x) {
return FastMath.exp(ArithmeticUtils.binomialCoefficientLog(m, x) +
ArithmeticUtils.binomialCoefficientLog(n - m, k - x) -
ArithmeticUtils.binomialCoefficientLog(n, k));
}
{code}
Thus it transforms the binomial coefficients to a logarithmic scale in order to
cope with the possibly large results (and to be able to compute the bincoeff at
all). But, imho, the reverse transformation is broken, as it does not take any
scaling into account. As the coefficients get larger (e.g. due to a large n),
the differences between the terms will become smaller in log scale, and thus
incorrectly transformed back to linear scale. Taking scaling into account, the
exp function will most likely fail for large n.
I have created a simple test to illustrate the problem, the t{x} correspond to
the binomial coeff terms from the formula, diff is the input the the exp
function. This loop simulates an increasing n, and the expectation is that the
result should get smaller with increasing n:
{code}
t1=0.0, t2=4547.288942497606, t3=4770.9627189150215, diff=-223.67377641741587,
result=7.23957639711833E-98
t1=0.0, t2=12183.221706275828, t3=12186.968419291079, diff=-3.7467130152508616,
result=0.023595175513309037
t1=0.0, t2=13444.672093808651, t3=13446.561352727935, diff=-1.8892589192837477,
result=0.15118380673528464
t1=0.0, t2=14186.229425843805, t3=14187.492505971342, diff=-1.2630801275372505,
result=0.2827816800804864
t1=0.0, t2=14713.395226772875, t3=14714.343882929534, diff=-0.9486561566591263,
result=0.3872610921706871
t1=0.0, t2=15122.726785860956, t3=15123.486358374357, diff=-0.7595725134015083,
result=0.46786639087791215
t1=0.0, t2=15457.396298892796, t3=15458.029636271298, diff=-0.673785018921,
result=0.5308173033122051
t1=0.0, t2=15740.484181590378, t3=15741.027263000607, diff=-0.5430814102292061,
result=0.5809553297318205
t1=0.0, t2=15985.787659011781, t3=15986.26300
[jira] [Issue Comment Edited] (MATH-724) RandomDataImpl.nextInt does not distribute uniformly for negative lower bound
[ https://issues.apache.org/jira/browse/MATH-724?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13170025#comment-13170025 ] Dennis Hendriks edited comment on MATH-724 at 12/15/11 8:24 AM: bq. Double.Min_VALUE is a positive number. Oops... OK, I uploaded a third version of the patch (math-724-v3.patch), which also applies the new formula for nextUniform. I included two test files (NextUniformTest3.java and NextIntTest3.java), that show the results for nextInt and nextUniform, for both the old and new formulas. As for as I can see, the new formula works equally well or better in all cases. Also, all existing unit tests pass. was (Author: dhendriks): bq. Double.Min_VALUE is a positive number. Oops... OK, I uploaded a third version of the patch, which also applies the new formula for nextUniform. I included two test files, that show the results for the old and new formulas. As for as I can see, the new formula works equally well or better in all cases. All existing unit tests pass. > RandomDataImpl.nextInt does not distribute uniformly for negative lower bound > - > > Key: MATH-724 > URL: https://issues.apache.org/jira/browse/MATH-724 > Project: Commons Math > Issue Type: Bug >Affects Versions: Nightly Builds >Reporter: Dennis Hendriks > Attachments: NextIntTest3.java, NextIntUniformTest.java, > NextUniformTest3.java, math-724-v2.patch, math-724-v3.patch, math-724.patch > > > When using the RandomDataImpl.nextInt function to get a uniform sample in a > [lower, upper] interval, when the lower value is less than zero, the output > is not uniformly distributed, as the lowest value is practically never > returned. > See the attached NextIntUniformTest.java file. It uses a [-3, 5] interval. > For several values between 0 and 1, testNextIntUniform1 prints the return > value of RandomDataImpl.nextInt (as double and as int). We see that -2 > through 5 are returned several times. The -3 value however, is only returned > for 0.0, and is thus under-respresented in the integer samples. The output of > test method testNextIntUniform2 also clearly shows that value -3 is never > sampled. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (MATH-724) RandomDataImpl.nextInt does not distribute uniformly for negative lower bound
[ https://issues.apache.org/jira/browse/MATH-724?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dennis Hendriks updated MATH-724: - Attachment: math-724-v3.patch NextUniformTest3.java NextIntTest3.java bq. Double.Min_VALUE is a positive number. Oops... OK, I uploaded a third version of the patch, which also applies the new formula for nextUniform. I included two test files, that show the results for the old and new formulas. As for as I can see, the new formula works equally well or better in all cases. All existing unit tests pass. > RandomDataImpl.nextInt does not distribute uniformly for negative lower bound > - > > Key: MATH-724 > URL: https://issues.apache.org/jira/browse/MATH-724 > Project: Commons Math > Issue Type: Bug >Affects Versions: Nightly Builds >Reporter: Dennis Hendriks > Attachments: NextIntTest3.java, NextIntUniformTest.java, > NextUniformTest3.java, math-724-v2.patch, math-724-v3.patch, math-724.patch > > > When using the RandomDataImpl.nextInt function to get a uniform sample in a > [lower, upper] interval, when the lower value is less than zero, the output > is not uniformly distributed, as the lowest value is practically never > returned. > See the attached NextIntUniformTest.java file. It uses a [-3, 5] interval. > For several values between 0 and 1, testNextIntUniform1 prints the return > value of RandomDataImpl.nextInt (as double and as int). We see that -2 > through 5 are returned several times. The -3 value however, is only returned > for 0.0, and is thus under-respresented in the integer samples. The output of > test method testNextIntUniform2 also clearly shows that value -3 is never > sampled. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
