Re: [statistics] Poisson distribution using a normal approximation
Le mar. 3 août 2021 à 00:09, Alex Herbert a écrit :
>
> The PoissonDistribution defines the method:
>
> /**
> * Calculates the Poisson distribution function using a normal
> * approximation. The {@code N(mean, sqrt(mean))} distribution is used
> * to approximate the Poisson distribution. The computation uses
> * "half-correction" (evaluating the normal distribution function at
> * {@code x + 0.5}).
> *
> * @param x Upper bound, inclusive.
> * @return the distribution function value calculated using a normal
> * approximation.
> */
> public double normalApproximateProbability(int x) {
> // Calculate the probability using half-correction.
> return normal.cumulativeProbability(x + 0.5);
> }
>
> This method does not seem to add value. A user would have to choose to use
> it when they know the approximation is good, typically if the mean is
> large. I would recommend removing it from the API.
+1
>
> Alex
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
Re: [Statistics] Log normal distribution parameters
Le lun. 2 août 2021 à 23:52, Alex Herbert a écrit : > > The LogNormalDistribution takes in parameters scale and shape. > > The parameters are the mean and standard deviation of the logarithm of the > random value X. Other libraries use mean (mu) and sigma for the parameters. > These are the parameters used on: > > - Wikipedia: mu, sigma [1] > - Matlab: mu, sigma [2] > - R: meanLog, sdLog [3] > - Wolfram: mu, sigma [4] > > The distribution defines a mean and variance. These are not directly the > values of mu and sigma^2. So using mean as a parameter name is misleading. > However using shape and scale is not standard. No references I found refer > to these parameters as shape and scale parameters. > > I would suggest changing to mu and sigma with the getters getMu and > getSigma. These can be documented as returning the mean and standard > deviation of the logarithm of the random variable X. Just a name change? +1 Gilles > > Alex > > > [1] https://en.wikipedia.org/wiki/Log-normal_distribution > [2] https://uk.mathworks.com/help/stats/prob.lognormaldistribution.html > [3] https://stat.ethz.ch/R-manual/R-devel/library/stats/html/Lognormal.html > [4] https://reference.wolfram.com/language/ref/LogNormalDistribution.html - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
[statistics] Poisson distribution using a normal approximation
The PoissonDistribution defines the method:
/**
* Calculates the Poisson distribution function using a normal
* approximation. The {@code N(mean, sqrt(mean))} distribution is used
* to approximate the Poisson distribution. The computation uses
* "half-correction" (evaluating the normal distribution function at
* {@code x + 0.5}).
*
* @param x Upper bound, inclusive.
* @return the distribution function value calculated using a normal
* approximation.
*/
public double normalApproximateProbability(int x) {
// Calculate the probability using half-correction.
return normal.cumulativeProbability(x + 0.5);
}
This method does not seem to add value. A user would have to choose to use
it when they know the approximation is good, typically if the mean is
large. I would recommend removing it from the API.
Alex
[Statistics] Log normal distribution parameters
The LogNormalDistribution takes in parameters scale and shape. The parameters are the mean and standard deviation of the logarithm of the random value X. Other libraries use mean (mu) and sigma for the parameters. These are the parameters used on: - Wikipedia: mu, sigma [1] - Matlab: mu, sigma [2] - R: meanLog, sdLog [3] - Wolfram: mu, sigma [4] The distribution defines a mean and variance. These are not directly the values of mu and sigma^2. So using mean as a parameter name is misleading. However using shape and scale is not standard. No references I found refer to these parameters as shape and scale parameters. I would suggest changing to mu and sigma with the getters getMu and getSigma. These can be documented as returning the mean and standard deviation of the logarithm of the random variable X. Alex [1] https://en.wikipedia.org/wiki/Log-normal_distribution [2] https://uk.mathworks.com/help/stats/prob.lognormaldistribution.html [3] https://stat.ethz.ch/R-manual/R-devel/library/stats/html/Lognormal.html [4] https://reference.wolfram.com/language/ref/LogNormalDistribution.html
Re: [rng] Release 1.4 blocked by a maven build issue
On Mon, 2 Aug 2021 at 16:52, Gilles Sadowski wrote: > Le lun. 2 août 2021 à 17:29, Gary Gregory a > écrit : > > > > IMO make Java 8 the platform requirement. > > +0.5 (if the cause is not obvious). > > [I don't think that we'll get complaints from people running on Java 1.6 > or 1.7 (?).] > A checkout of the previous release tag RNG_1_3 shows a requirement for Maven 3.3.9. It uses commons parent 49. A checkout of release tag RNG_1_2 shows a requirement for Maven 3.1.1. It uses commons parent 47. If RNG_1_3 is changed to parent 48 it still has the issue. A change to parent 47 fixes it. So some upgrade of parent from 47 to 48 brings in a dependency on a plugin that requires Maven 3.3.9, and with this Java 7 is required for the build. So the last release was technically incorrect as a source distribution that can be built by the platform it targets. This stems from using an old version of Java as the target while trying to use more up-to-date build tools and a lack of a CI environment to test the build on the target platform. I've built a version map for the project when using both parents. There are 23 plugins that change versions from CP 47 to 48. I do not feel inclined to find which one is the issue. Rolling back to parent 47 for the current code does appear to fix the requirement for Maven 3.3.9. I have not done a full build dryRun but the version checks are OK. Since Java 1.6 is not openly supported [1] I think moving the build to Java 1.7 (still supported until 2022) should suffice for this release. I am going to update the code to Java 1.7 and all the plugins to recommended versions. The SonarCloud analysis should pick up all places where Java 1.7 code constructs should be used (e.g. diamond operator). These can be fixed before releasing the code. An update to Java 1.8 can be done for the next release (1.5) allowing some time to be taken to integrate features of Java 1.8 into the code. It would also allow an update to JUnit 5 where the surefire plugin now supports rerunning failing tests which is a key feature of the RNG test suite. Alex [1] https://en.wikipedia.org/wiki/Java_version_history
Re: [rng] Release 1.4 blocked by a maven build issue
Le lun. 2 août 2021 à 17:29, Gary Gregory a écrit : > > IMO make Java 8 the platform requirement. +0.5 (if the cause is not obvious). [I don't think that we'll get complaints from people running on Java 1.6 or 1.7 (?).] Regards, Gilles > > Gary > > On Mon, Aug 2, 2021, 11:06 Alex Herbert wrote: > > > I have been looking at releasing RNG 1.4. > > > > I did a check to update the plugins using: > > > > mvn versions:display-plugin-updates -U -N > > > > I get an issue about requiring Maven 3.3.9 as a minimum version which > > requires JDK 7 [1]. Since the project targets JDK 6 this is not ideal. > > > > Very few versions have been updated since I did the last release. I checked > > out tag RNG_1_3 and I get the same issue. So either my current build > > environment is now mandating maven 3.3.9 or this was an issue on the last > > release and I did not notice it. Since I last updated plugins before the > > last release I think this is some third party dependency that is not > > explicitly controlled in the POM. FYI I am using: > > > > mvn -v > > Apache Maven 3.6.3 (cecedd343002696d0abb50b32b541b8a6ba2883f) > > Maven home: /usr/local/apache-maven-3.6.3 > > Java version: 1.8.0_241, vendor: Oracle Corporation, runtime: > > /usr/lib/jvm/jdk1.8.0_241/jre > > Default locale: en_GB, platform encoding: UTF-8 > > OS name: "linux", version: "4.15.0-151-generic", arch: "amd64", family: > > "unix" > > > > If we require Java 1.6 as the target then this will require: > > > > 1. Tracking down what has created a requirement for Maven 3.3.9 > > 2. A toolchain to configure Maven running under JDK 1.7+ to build the code > > using JDK 1.6 [2] > > 3. Updating the project to use Java 1.7 > > 4. Documenting that Java 1.7 is required to build the project even though > > the target is 1.6 > > > > Currently we use a profile for JDK 1.8+ plugins to run code checks. Travis > > CI runs a build on JDK 1.7 so the project will build on that platform. But > > there is no CI build available to run on JDK 1.6. > > > > There is nothing in the code to mandate an upgrade to 1.7. So an update > > would be just for convenience. > > > > My preference would be to update the documentation to state that it > > requires building with Java 1.7 and do at least this release targeting 1.6. > > Then update the code to 1.8 to take advantage of the new features there and > > skip 1.7. > > > > Is there a requirement that the platform that is targeted must be able to > > be used to build the code from source? > > > > Any opinions? > > > > Alex > > > > [1] https://maven.apache.org/docs/3.3.9/release-notes.html > > [2] https://maven.apache.org/guides/mini/guide-using-toolchains.html > > - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [rng] Release 1.4 blocked by a maven build issue
Le lun. 2 août 2021 à 17:06, Alex Herbert a écrit : > > I have been looking at releasing RNG 1.4. > > I did a check to update the plugins using: > > mvn versions:display-plugin-updates -U -N > > I get an issue about requiring Maven 3.3.9 as a minimum version which > requires JDK 7 [1]. Since the project targets JDK 6 this is not ideal. > > [...] > > Is there a requirement that the platform that is targeted must be able to > be used to build the code from source? I seem to recall that Sebb mentioned that it must be the case (TBC). [At least, it would be consistent with the official release material being source code.] Gilles > > Any opinions? > > Alex > > [1] https://maven.apache.org/docs/3.3.9/release-notes.html > [2] https://maven.apache.org/guides/mini/guide-using-toolchains.html - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [rng] Release 1.4 blocked by a maven build issue
IMO make Java 8 the platform requirement. Gary On Mon, Aug 2, 2021, 11:06 Alex Herbert wrote: > I have been looking at releasing RNG 1.4. > > I did a check to update the plugins using: > > mvn versions:display-plugin-updates -U -N > > I get an issue about requiring Maven 3.3.9 as a minimum version which > requires JDK 7 [1]. Since the project targets JDK 6 this is not ideal. > > Very few versions have been updated since I did the last release. I checked > out tag RNG_1_3 and I get the same issue. So either my current build > environment is now mandating maven 3.3.9 or this was an issue on the last > release and I did not notice it. Since I last updated plugins before the > last release I think this is some third party dependency that is not > explicitly controlled in the POM. FYI I am using: > > mvn -v > Apache Maven 3.6.3 (cecedd343002696d0abb50b32b541b8a6ba2883f) > Maven home: /usr/local/apache-maven-3.6.3 > Java version: 1.8.0_241, vendor: Oracle Corporation, runtime: > /usr/lib/jvm/jdk1.8.0_241/jre > Default locale: en_GB, platform encoding: UTF-8 > OS name: "linux", version: "4.15.0-151-generic", arch: "amd64", family: > "unix" > > If we require Java 1.6 as the target then this will require: > > 1. Tracking down what has created a requirement for Maven 3.3.9 > 2. A toolchain to configure Maven running under JDK 1.7+ to build the code > using JDK 1.6 [2] > 3. Updating the project to use Java 1.7 > 4. Documenting that Java 1.7 is required to build the project even though > the target is 1.6 > > Currently we use a profile for JDK 1.8+ plugins to run code checks. Travis > CI runs a build on JDK 1.7 so the project will build on that platform. But > there is no CI build available to run on JDK 1.6. > > There is nothing in the code to mandate an upgrade to 1.7. So an update > would be just for convenience. > > My preference would be to update the documentation to state that it > requires building with Java 1.7 and do at least this release targeting 1.6. > Then update the code to 1.8 to take advantage of the new features there and > skip 1.7. > > Is there a requirement that the platform that is targeted must be able to > be used to build the code from source? > > Any opinions? > > Alex > > [1] https://maven.apache.org/docs/3.3.9/release-notes.html > [2] https://maven.apache.org/guides/mini/guide-using-toolchains.html >
[rng] Release 1.4 blocked by a maven build issue
I have been looking at releasing RNG 1.4. I did a check to update the plugins using: mvn versions:display-plugin-updates -U -N I get an issue about requiring Maven 3.3.9 as a minimum version which requires JDK 7 [1]. Since the project targets JDK 6 this is not ideal. Very few versions have been updated since I did the last release. I checked out tag RNG_1_3 and I get the same issue. So either my current build environment is now mandating maven 3.3.9 or this was an issue on the last release and I did not notice it. Since I last updated plugins before the last release I think this is some third party dependency that is not explicitly controlled in the POM. FYI I am using: mvn -v Apache Maven 3.6.3 (cecedd343002696d0abb50b32b541b8a6ba2883f) Maven home: /usr/local/apache-maven-3.6.3 Java version: 1.8.0_241, vendor: Oracle Corporation, runtime: /usr/lib/jvm/jdk1.8.0_241/jre Default locale: en_GB, platform encoding: UTF-8 OS name: "linux", version: "4.15.0-151-generic", arch: "amd64", family: "unix" If we require Java 1.6 as the target then this will require: 1. Tracking down what has created a requirement for Maven 3.3.9 2. A toolchain to configure Maven running under JDK 1.7+ to build the code using JDK 1.6 [2] 3. Updating the project to use Java 1.7 4. Documenting that Java 1.7 is required to build the project even though the target is 1.6 Currently we use a profile for JDK 1.8+ plugins to run code checks. Travis CI runs a build on JDK 1.7 so the project will build on that platform. But there is no CI build available to run on JDK 1.6. There is nothing in the code to mandate an upgrade to 1.7. So an update would be just for convenience. My preference would be to update the documentation to state that it requires building with Java 1.7 and do at least this release targeting 1.6. Then update the code to 1.8 to take advantage of the new features there and skip 1.7. Is there a requirement that the platform that is targeted must be able to be used to build the code from source? Any opinions? Alex [1] https://maven.apache.org/docs/3.3.9/release-notes.html [2] https://maven.apache.org/guides/mini/guide-using-toolchains.html
Re: [geometry] 1.0 release (take 2)
On Mon, 2 Aug 2021 at 02:32, Matt Juntunen wrote: > > > Then, as a matter of preference, I'd still suggest that "Commons RNG" > > be released first (if the latter's next release is pending). > > Ok. Any thoughts on a timeline for that? > I am currently looking at it. The dryRun build of the release profile now works under JDK 11.0.11. This is good. Previously JDK 11 complained about the JPMS modules using code from packages in the unnamed module and this errored the build. It had to be released using JDK 9. Now the latest JDK has a more lenient javadoc tool and the warnings are printed but it does not fail the build. I am going to try updating the modules to use Java 11 in-place of Java 9 and see if that works. It would be preferable to release the example JPMS modules built using the first LTS version to support modules (i.e. JDK 11 not not JDK 9). Alex
Re: [commons-compress] branch master updated: COMPRESS-583: update the changelog of COMPRESS-404
Ah, I forgot about the RELEASE-NOTES. Thanks for your help. cheers, Lee On Sat, Jul 31, 2021 at 7:52 PM Gary Gregory wrote: > Doing the site is good too. I will try to look... > > On Sat, Jul 31, 2021, 07:51 Gary Gregory wrote: > > > I was just talking about the readme html file from the svn repo. > > > > Gary > > > > On Fri, Jul 30, 2021, 22:20 PeterLee wrote: > > > >> > You might want to regenerate the release notes that are served on the > >> > download site. > >> > >> Yes. I do want to update the website, but I have no idea how to do this. > >> Can anyone give me a hand? > >> > >> cheers, > >> Lee > >> > >> On Sat, Jul 31, 2021 at 10:02 AM Gary Gregory > >> wrote: > >> > >> > You might want to regenerate the release notes that are served on the > >> > download site. > >> > > >> > Gary > >> > > >> > On Fri, Jul 30, 2021, 21:44 wrote: > >> > > >> > > This is an automated email from the ASF dual-hosted git repository. > >> > > > >> > > peterlee pushed a commit to branch master > >> > > in repository > >> https://gitbox.apache.org/repos/asf/commons-compress.git > >> > > > >> > > > >> > > The following commit(s) were added to refs/heads/master by this > push: > >> > > new 7bc8679 COMPRESS-583: update the changelog of COMPRESS-404 > >> > > 7bc8679 is described below > >> > > > >> > > commit 7bc86793d2533ef314550efe2b79df752abdc8d4 > >> > > Author: PeterAlfredLee > >> > > AuthorDate: Sat Jul 31 09:38:52 2021 +0800 > >> > > > >> > > COMPRESS-583: update the changelog of COMPRESS-404 > >> > > --- > >> > > src/changes/changes.xml | 4 > >> > > 1 file changed, 4 insertions(+) > >> > > > >> > > diff --git a/src/changes/changes.xml b/src/changes/changes.xml > >> > > index 24b28c5..ee52465 100644 > >> > > --- a/src/changes/changes.xml > >> > > +++ b/src/changes/changes.xml > >> > > @@ -149,6 +149,10 @@ you relied on the recovery attempt."> > >> > > Update the class of variable file in TarArchiveEntry from > >> > > java.io.File to java.nio.file.Path. Corresponding > >> constructors > >> > > and methods are also modified/added. > >> > > + > >> > > +NOTE: The UserID and GroupID will also be read if they are > >> > > +available. The previous default value UserID:GroupdID of > was > >> > 0:0. > >> > > +This may cause a reproducibility problem. > >> > > Github Pull Request #97. > >> > > > >> > > >> > > due-to="Robin Schimpf"> > >> > > > >> > > >> > > >
