[jira] [Commented] (SANDBOX-377) [BeanUtils2] Implement invoke(Exact)Method(...) on DefaultBeanAccessor
[
https://issues.apache.org/jira/browse/SANDBOX-377?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13197672#comment-13197672
]
Benedikt Ritter commented on SANDBOX-377:
-
{quote}
because they are non-javadoc Eclipse-related only, and not everybody uses
Eclipse.
{quote}
ouch... sorry about that. You will not see that again.
[BeanUtils2] Implement invoke(Exact)Method(...) on DefaultBeanAccessor
--
Key: SANDBOX-377
URL: https://issues.apache.org/jira/browse/SANDBOX-377
Project: Commons Sandbox
Issue Type: Improvement
Components: BeanUtils2
Affects Versions: Nightly Builds
Reporter: Benedikt Ritter
Assignee: Simone Tripodi
Attachments: SANDBOX-377.txt
On DefaultBeanAccessor implement:
* invokeMethod( String methodName )
* invokeExactMethod( String methodName )
--
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] (DBUTILS-87) Return generated key on insert
[ https://issues.apache.org/jira/browse/DBUTILS-87?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13197710#comment-13197710 ] Sebb commented on DBUTILS-87: - Javadoc needs to be added for the new public methods. Return generated key on insert -- Key: DBUTILS-87 URL: https://issues.apache.org/jira/browse/DBUTILS-87 Project: Commons DbUtils Issue Type: New Feature Reporter: Moandji Ezana Assignee: William R. Speirs Attachments: QueryRunner_insert.txt It would be useful to have an insert method on QueryRunner that returns the id of the new record. -- 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] (DBUTILS-87) Return generated key on insert
[ https://issues.apache.org/jira/browse/DBUTILS-87?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13197766#comment-13197766 ] Moandji Ezana commented on DBUTILS-87: -- @Sebb: I agree, but I wanted to get some initial feedback on whether the functionality is desired, implemented in a sane way, etc. As soon as that is agreed, I'll fill in the documentation, fix any code style mistakes and also add this functionality to the AsyncQueryRunner and (if possible) batch methods. Return generated key on insert -- Key: DBUTILS-87 URL: https://issues.apache.org/jira/browse/DBUTILS-87 Project: Commons DbUtils Issue Type: New Feature Reporter: Moandji Ezana Assignee: William R. Speirs Attachments: QueryRunner_insert.txt It would be useful to have an insert method on QueryRunner that returns the id of the new record. -- 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-787) StringUtils.RemoveIgnoreCase desired
StringUtils.RemoveIgnoreCase desired Key: LANG-787 URL: https://issues.apache.org/jira/browse/LANG-787 Project: Commons Lang Issue Type: New Feature Components: lang.* Affects Versions: 3.1 Reporter: david cogen Priority: Minor removeStartIgnoreCase() and removeEndIgnoreCase() exist, so why not removeIgnoreCase() Specifically: String removeIgnoreCase(String str, String remove) -- 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-787) StringUtils.RemoveIgnoreCase desired
[ https://issues.apache.org/jira/browse/LANG-787?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13197768#comment-13197768 ] Gary D. Gregory commented on LANG-787: -- Maybe we should add APIs with a 'boolean ignoreCsse' to all methods that match strings. StringUtils.RemoveIgnoreCase desired Key: LANG-787 URL: https://issues.apache.org/jira/browse/LANG-787 Project: Commons Lang Issue Type: New Feature Components: lang.* Affects Versions: 3.1 Reporter: david cogen Priority: Minor removeStartIgnoreCase() and removeEndIgnoreCase() exist, so why not removeIgnoreCase() Specifically: String removeIgnoreCase(String str, String remove) -- 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-787) StringUtils.RemoveIgnoreCase desired
[ https://issues.apache.org/jira/browse/LANG-787?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13197772#comment-13197772 ] david cogen commented on LANG-787: -- That might have been preferable if starting over, but the *ignoreCase suffix was used in class String and it probably makes sense to continue this convention. StringUtils.RemoveIgnoreCase desired Key: LANG-787 URL: https://issues.apache.org/jira/browse/LANG-787 Project: Commons Lang Issue Type: New Feature Components: lang.* Affects Versions: 3.1 Reporter: david cogen Priority: Minor removeStartIgnoreCase() and removeEndIgnoreCase() exist, so why not removeIgnoreCase() Specifically: String removeIgnoreCase(String str, String remove) -- 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] (DIGESTER-161) Document thread-safety in javadoc of Rule class
[ https://issues.apache.org/jira/browse/DIGESTER-161?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Simone Tripodi resolved DIGESTER-161. - Resolution: Fixed Assignee: Simone Tripodi fixed on [r1239129|http://svn.apache.org/viewvc?rev=1239129view=rev]. For future releases, please read the [On Contributing Patches |http://commons.apache.org/patches.html] short guide. Thanks for contributing Document thread-safety in javadoc of Rule class Key: DIGESTER-161 URL: https://issues.apache.org/jira/browse/DIGESTER-161 Project: Commons Digester Issue Type: Improvement Affects Versions: 3.1 Reporter: Eduard Papa Assignee: Simone Tripodi Priority: Trivial Labels: rule, thread-safe Attachments: RuleJavadoc.txt Original Estimate: 1h Remaining Estimate: 1h I discovered a problem today with some code that was reusing a custom Rule in multiple threads, even though each thread was creating its own digester. It seems that Digester.addRule is calling rule.setDigester and if the rule is shared across multiple threads, the calls to begin/end can get tangled across threads. It is obvious that Rules are not meant to be shared, but the javadoc http://commons.apache.org/digester/apidocs/org/apache/commons/digester3/Rule.html seems to be implying the opposite and is confusing at best. It talks about the rules being stateless, even though the framework itself is changing its state with rule.setDigester(digester). It further states that since all state is part of the digester, the rule is safe under all cases, which is very misleading. ... Rule objects should be stateless, ie they should not update any instance member during the parsing process. A rule instance that changes state will encounter problems if invoked in a nested manner; this can happen if the same instance is added to digester multiple times or if a wildcard pattern is used which can match both an element and a child of the same element. The digester object stack and named stacks should be used to store any state that a rule requires, making the rule class safe under all possible uses. ... I think the statement above should be reworded to be more correct and avoid confusion. Down the line, maybe the digester accessed by the rule should be a ThreadLocal. -- 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] (DAEMON-233) Heap corruption in apxMultiSzToArrayW for windows procrun
[
https://issues.apache.org/jira/browse/DAEMON-233?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mladen Turk resolved DAEMON-233.
Resolution: Fixed
Fix Version/s: 1.0.9
Fixed in the 1.0.x branch. Will be part of 1.0.9 release
Heap corruption in apxMultiSzToArrayW for windows procrun
-
Key: DAEMON-233
URL: https://issues.apache.org/jira/browse/DAEMON-233
Project: Commons Daemon
Issue Type: Bug
Components: Procrun
Affects Versions: 1.0.8
Environment: All windows versions.
Reporter: Andy Cooper
Assignee: Mladen Turk
Fix For: 1.0.9
When I tried to use commons daemon 1.0.8 for a project, after successfully
installing the service, starting it on Windows 7 failed reliably, and it
failed sporadically on other platforms. I traced the problem to a heap
corruption bug due to an over-long pointer write in utils.c, line 321.
The original line (inside of apxMultiSzToArrayW) reads:
AplCopyMemory(p, lpString, (l + 1) * sizeof(WCHAR) + sizeof(WCHAR));
The fix is to remove the + sizeof(WCHAR) from the line, leaving it as
AplCopyMemory(p, lpString, (l + 1) * sizeof(WCHAR));
Note that you've already taken care of the terminating null inside of l.
After I'd made that change and rebuilt, things worked happily for me. Please
could you include this fix in a subsequent release.
To reproduce:
{noformat}
1. Ensure that you do NOT have a JRE or a JDK installed on the target machine.
2. Create a folder structure something like
\MyApp\Jetty
\MyApp\jre7 - copy a JRE into here, but do NOT run the JRE
installation
\MyApp\Jetty\bin -- place prunsrv.exe here
3. Ensure that you do not have the JRE on your system path
4. Install the service via the command line:
C:\MyApp\Jetty\bin\prunsrv.exe install MyService --DisplayName=My Service
--Install=C:\MyApp\Jetty\bin\prunsrv.exe
--LogPath=C:\MyApp\Jetty\logs --LogLevel=Info --StdOutput=auto
--StdError=auto --StartMode=jvm --StopMode=jvm
--JavaHome=C:\MyApp\jre7 --Jvm=C:\MyApp\jre7\bin\client\jvm.dll
--Startup=auto --StartPath=C:\MyApp\Jetty
--Classpath=C:\MyApp\Jetty\start.jar;C:\MyApp\Jetty\commons-daemon-1.0.8.jar
++StartParams=--daemon --StartClass=org.eclipse.jetty.start.Main
--StopClass=org.eclipse.jetty.start.Main ++StopParams=--stop
++JvmOptions=-Djetty.home=C:\MyApp\Jetty ++JvmOptions=-Djetty.port=80
++JvmOptions=-DSTOP.PORT=9131 ++JvmOptions=-DSTOP.KEY=stopMyApp
5. Start the service via net start MyService. Observe that it fails to
start.
Depending on the machine, sometimes it started and sometimes it failed to
start.
The joys of heap corruption ...
{noformat}
Anyway, I debugged this with Visual Studio 2010 and used the data change
breakpoint to observe the memory write (2 bytes beyond the end of the
allocated block).
--
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] (DAEMON-232) jsvc should no longer setpgrp() on startup
[
https://issues.apache.org/jira/browse/DAEMON-232?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mladen Turk resolved DAEMON-232.
Resolution: Fixed
Fix Version/s: 1.0.9
Removed the code.
You are right. We don't call kill(0) neither does JVM
jsvc should no longer setpgrp() on startup
--
Key: DAEMON-232
URL: https://issues.apache.org/jira/browse/DAEMON-232
Project: Commons Daemon
Issue Type: Bug
Components: Jsvc
Reporter: Adar Dembo
Fix For: 1.0.9
jsvc-unix.c runs the following code in the child process before
{code}
/* create a new process group to prevent kill 0 killing the monitor
process */
#if defined(OS_FREEBSD) || defined(OS_DARWIN)
setpgid(0, 0);
#else
setpgrp();
#endif
{code}
This puts the child in its own process group, breaking some process
management tools (such as supervisor) that expect to be able to kill a
logical process by sending a SIGKILL to its process group. The su binary,
which is somewhat analogous in function to jsvc, doesn't do this.
As best I can tell, there's no code in jsvc that does kill(0, ...). There's
also not enough svn history to provide more context. As for the child process
doing a kill(0, ...), I find it highly unlikely that the JVM itself sends
signals.
So is the setpgrp call still necessary? If not, can it be removed?
--
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] (DAEMON-237) ++JvmOptions processed as --JvmOptions
[ https://issues.apache.org/jira/browse/DAEMON-237?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mladen Turk resolved DAEMON-237. Resolution: Fixed Fix Version/s: 1.0.9 Patch applied. Like Sebastian said, the logic was not updated when new command was added. ++JvmOptions processed as --JvmOptions -- Key: DAEMON-237 URL: https://issues.apache.org/jira/browse/DAEMON-237 Project: Commons Daemon Issue Type: Bug Components: Procrun Affects Versions: 1.0.8 Environment: XP 64-bit, XP 32-bit, Windows 7 64-bit Reporter: Mark Thomas Fix For: 1.0.9 Attachments: DAEMON-237.patch See https://issues.apache.org/bugzilla/show_bug.cgi?id=52548 and http://tomcat.markmail.org/thread/md3ibbv2w3mxtnb2 for details -- 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] (DAEMON-237) ++JvmOptions processed as --JvmOptions
[ https://issues.apache.org/jira/browse/DAEMON-237?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13198006#comment-13198006 ] Sebb commented on DAEMON-237: - Maybe the code should use names (#define) rather than magic numbers? This should make future maintenance easier, and help document them. ++JvmOptions processed as --JvmOptions -- Key: DAEMON-237 URL: https://issues.apache.org/jira/browse/DAEMON-237 Project: Commons Daemon Issue Type: Bug Components: Procrun Affects Versions: 1.0.8 Environment: XP 64-bit, XP 32-bit, Windows 7 64-bit Reporter: Mark Thomas Fix For: 1.0.9 Attachments: DAEMON-237.patch See https://issues.apache.org/bugzilla/show_bug.cgi?id=52548 and http://tomcat.markmail.org/thread/md3ibbv2w3mxtnb2 for details -- 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] (SANDBOX-379) [BeanUtils2] Implement describe() on DefaultBeanAccessor
[BeanUtils2] Implement describe() on DefaultBeanAccessor - Key: SANDBOX-379 URL: https://issues.apache.org/jira/browse/SANDBOX-379 Project: Commons Sandbox Issue Type: Improvement Components: BeanUtils2 Affects Versions: Nightly Builds Reporter: Benedikt Ritter Implement the above mentioned method an corresponding unit tests -- 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-707) Naming confusion
[
https://issues.apache.org/jira/browse/MATH-707?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13198299#comment-13198299
]
Gilles commented on MATH-707:
-
Revision 1239390:
* {{UnivariateRealIntegrator}} renamed to {{UnivariateIntegrator}}
* {{UnivariateRealIntegratorImpl}} to {{BaseAbstractUnivariateIntegrator}}
Concerning the second point, discussed on the ML, I propose that the decision
to drop Base and/or Abstract be postponed to after 3.0 since there are
other occurrences of a similar situation (e.g. in package
o.a.c.m.optimization).
Naming confusion
Key: MATH-707
URL: https://issues.apache.org/jira/browse/MATH-707
Project: Commons Math
Issue Type: Task
Reporter: Gilles
Assignee: Gilles
Priority: Trivial
Labels: api-change
Fix For: 3.0
This issue was raised in [this
thread|http://markmail.org/thread/4h6omyqsik65rcgv] on the dev ML.
It proposes to consistently name classes/interfaces that refer to number
types (e.g. Real, Complex, ...) and structure (e.g. Scalar,
Vectorial, ...), with Real and Scalar components in names being assumed
(thus, not to be included in the name).
For example, for the Univariate... interfaces (in package analysis), the
proposal is to operate the following renaming:
* {{UnivariateRealFunction}} - {{UnivariateFunction}}
* {{UnivariateRealVectorialFunction}} - {{UnivariateVectorFunction}}
* {{UnivariateMatrixFunction}} - {{UnivariateMatrixFunction}}
Similar changes are in order in the package optimization (where Real is
sometimes included in the name and sometimes not, or used instead of
Scalar).
--
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] (MATH-677) About package transform
[
https://issues.apache.org/jira/browse/MATH-677?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sébastien Brisard resolved MATH-677.
Resolution: Fixed
Changes proposed to multidimensional FFT will be applied later.
About package transform
-
Key: MATH-677
URL: https://issues.apache.org/jira/browse/MATH-677
Project: Commons Math
Issue Type: Improvement
Reporter: Gilles
Assignee: Sébastien Brisard
Priority: Minor
Labels: api-change
Fix For: 3.0
Classes in package o.a.c.m.transform might require some changes in order to
conform to goals set for the next major release.
Some observations:
# Exceptions {color:red}done (see below){color}
## Should remove use of deprecated MathRuntimeException
## Should throw more specific Math...Exception instances instead of
standard IAE
# Interface RealTransformer (and implementations) contain non-conformant
method names (e.g. inversetransform instead of inverseTransform).
{color:red}Fixed in {{r1208293}}.{color}
# FastFourierTransformer:
## Methods mdfft and verifyDataSet take an argument of type Object (to
allow an argument with an unspecified number of dimensions)
## The RootsOfUnity helper class could be moved to the complex package.
{color:red}Done in {{r1238898}}{color}.
## For clarity, multidimensional transform should be moved to a class of its
own (and I also wonder whether the MultiDimensionalComplexMatrix name is
not misleading)
# FastFourierTransformer, FastSineTranformer and FastCosineTranformer
define public methods tranform2 and inversetransform2 but they are not
part of an interface. {color:red}As of {{r1213157}}, these methods have been
removed, and replaced by factory methods {{create()}} and {{createUnitary()}}
(FFT) or {{createOrthogonal()}} (FCT, FST).{color}
# Code uses variables that start with an uppercase. {color:red}Fixed,
together with various formatting issues.{color}
# FastHadamardTransformer contains illegible developer documentation (see
Javadoc for protected method fht). {color:red}Tried to improve things in
{{r1208986}}, but things are still a bit obscure. Besides, the link provided
is broken. Will look into that.{color}
--
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] (MATH-736) Multidimensional FFT
Multidimensional FFT
Key: MATH-736
URL: https://issues.apache.org/jira/browse/MATH-736
Project: Commons Math
Issue Type: Improvement
Reporter: Sébastien Brisard
Priority: Minor
Fix For: 3.1, 4.0
This is a continuation of MATH-677. In
{{o.a.c.m.transform.FastFourierTransformer}}
* methods {{mdfft}} and {{verifyDataSet}} take an argument of type {{Object}}
(to allow an argument with an unspecified number of dimensions)
* for clarity, multidimensional transform should be moved to a class of its own
(and I also wonder whether the {{MultiDimensionalComplexMatrix}} name is not
misleading)
--
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-732) Major Speed Improvement to 1D Discrete Fourier Transform (approximately 5x-9x improvement). Preserved public API 100%. Removed unnecessary use of instance variables and i
[
https://issues.apache.org/jira/browse/MATH-732?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13198561#comment-13198561
]
Sébastien Brisard commented on MATH-732:
Hi Kurt,
I'm willing to have a look to your proposal. As we are trying to release 3.0
soon, we need to decide if this issue is postponed to 3.1. I've been working
quite a lot on MATH-677, and the patch you provided no longer works. Would you
like to check out the latest version of CM and patch against this version ?
Alternatively (preferably), you could just attach the whole modified
{{FastFourierTransformer}} class, since I will keep both old and new
implementations side by side for the sake of my tests.
Thanks beforehand,
Sébastien
Major Speed Improvement to 1D Discrete Fourier Transform (approximately 5x-9x
improvement). Preserved public API 100%. Removed unnecessary use of instance
variables and instance state.
Key: MATH-732
URL: https://issues.apache.org/jira/browse/MATH-732
Project: Commons Math
Issue Type: Improvement
Affects Versions: 3.0
Reporter: Kurt Ostfeld
Assignee: Sébastien Brisard
Labels: api, perfomance
Fix For: 3.0
Attachments: DFTPerformanceWithPatch.png,
DFTPerformanceWithoutPatch.png, FastFourierTransformer.java.diff,
FastFourierTransformer.java.diff, FastFourierTransformerTest.java.diff,
FastFourierTransformerTest.java.diff, Main.java, Main.java
I wrote my own Discrete Fourier Transform function in Java and ran some
benchmarks and found that it ran dramatically faster than the Apache library
implementation. This is a pretty straight forward implementation of the
standard Cooley Tukey algorithm that I read out of a textbook. This passes
all the Apache library test cases plus several I had written on my own. I
created a source code library patch that preserves the public API completely
while changing the internal implementation to achieve the performance
improvement.
In addition to the performance issue, I suggest that Discrete Fourier
Transform functionality be provided as stateless pure functions (in Java this
would be implemented with static methods) just like most other math
functions. As-is, the library requires the user to instantiate a Transformer
instance which maintains instance state, which is an unecessary complexity
for a pure math function. I held off on this change since it would change the
public API and affect existing code. However, I see similar backward
compatability breaking API changes are already in the FastFourierTransformer
class in the 3.0 code base.
--
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] (MATH-692) Cumulative probability and inverse cumulative probability inconsistencies
[
https://issues.apache.org/jira/browse/MATH-692?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sébastien Brisard resolved MATH-692.
Resolution: Fixed
The issue about selection of an appropriate seed has been raised elsewhere. No
definitive answer has been provided so far, so I suggest we consider this issue
as solved for the time being.
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_integerDomain_patch1.patch,
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] [Commented] (DAEMON-237) ++JvmOptions processed as --JvmOptions
[ https://issues.apache.org/jira/browse/DAEMON-237?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13198571#comment-13198571 ] Mladen Turk commented on DAEMON-237: Well, the 1.0.x branch is frozen for new features, and 1.1.x/2.0.x (trunk) will have a java like command lines (from jsvc) ++JvmOptions processed as --JvmOptions -- Key: DAEMON-237 URL: https://issues.apache.org/jira/browse/DAEMON-237 Project: Commons Daemon Issue Type: Bug Components: Procrun Affects Versions: 1.0.8 Environment: XP 64-bit, XP 32-bit, Windows 7 64-bit Reporter: Mark Thomas Fix For: 1.0.9 Attachments: DAEMON-237.patch See https://issues.apache.org/bugzilla/show_bug.cgi?id=52548 and http://tomcat.markmail.org/thread/md3ibbv2w3mxtnb2 for details -- 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
