[jira] [Commented] (MATH-1668) RandomDataGenerator produces the same result for different upper bounds
[
https://issues.apache.org/jira/browse/MATH-1668?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17867091#comment-17867091
]
Gilles Sadowski commented on MATH-1668:
---
As of version 4.0, class {{RandomDataGenerator}} has been removed from Commons
Math.
Functionality was moved to Commons RNG.
> RandomDataGenerator produces the same result for different upper bounds
> ---
>
> Key: MATH-1668
> URL: https://issues.apache.org/jira/browse/MATH-1668
> Project: Commons Math
> Issue Type: Bug
>Affects Versions: 3.6.1
>Reporter: Arman Sharif
>Priority: Major
>
> {{I noticed the RandomDataGenerator is producing the same result for
> different upper bounds when the upper bound belongs to a certain range.}}
> I created a sample project with a test replicating the problem:
> [https://github.com/armandino/commons-math3-bug]
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IO-808) FileUtils.moveFile, copyFile and others can throw undocumened IllegalArgumentException
[
https://issues.apache.org/jira/browse/IO-808?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17847784#comment-17847784
]
Gilles Sadowski commented on IO-808:
We already had this discussion; IMO, the burden brought by checked exceptions
vastly overweight its supposed benefit:
https://stackoverflow.com/questions/58639126/whats-the-idea-behind-kotlin-removing-checked-exceptions
IIUC the description of the report, the issue is caused by an API change; the
pain would exist for any such change, irrespective of it being a move away from
checked exceptions.
> FileUtils.moveFile, copyFile and others can throw undocumened
> IllegalArgumentException
> --
>
> Key: IO-808
> URL: https://issues.apache.org/jira/browse/IO-808
> Project: Commons IO
> Issue Type: Bug
> Components: Utilities
>Affects Versions: 2.12.0
> Environment: Windows 10
>Reporter: Phil D
>Priority: Major
> Attachments: MakyAckyBreaky.java, TestMoveFileIAE.java
>
>
> Several of the functions in FileUtils are throwing undocumented
> IllegalArgumentException such as moveFile, copyFile and other locations.
> If the desire is to maintain backwards compatibility with the 1.4 branch for
> these functions, then the 2.12 (and 2.13) versions are throwing
> IllegalArgumentException in cases where 1.4 is not. In fact, it seems like
> 1.4 was coded to specifically avoid IllegalArgumentException and throws
> IOExceptions instead.
> There are several different cases where this is possible. In the most basic,
> I've attached TestMoveFileIAE, where this can be reproduced by simple running:
> {code:bash}
> mkdir one
> java -cp TestMoveFileIAE one two
> Exception in thread "main" java.lang.IllegalArgumentException: Parameter
> 'srcFile' is not a file: one
> at org.apache.commons.io.FileUtils.requireFile(FileUtils.java:2824)
> at org.apache.commons.io.FileUtils.moveFile(FileUtils.java:2395)
> at org.apache.commons.io.FileUtils.moveFile(FileUtils.java:2374)
> at TestMoveFileIAE.main(TestMoveFileIAE.java:13)
> {code}
> In a less likely scenario (which is how I found this issue because this
> happened on a production system); If the srcFile is removed at a certain
> point during moveFile() execution then IllegalArgumentException is throws:
> https://github.com/apache/commons-io/blob/master/src/main/java/org/apache/commons/io/FileUtils.java#L2392
> {code:java}
> 2392public static void moveFile(final File srcFile, final File destFile,
> final CopyOption... copyOptions) throws IOException {
> 2393validateMoveParameters(srcFile, destFile); // checks srcFile.exists()
> /// srcFile deleted here!!!
> 2394requireFile(srcFile, "srcFile"); // checks srcFile.isFile()
> and throws IAE
> 2395requireAbsent(destFile, "destFile");
> /// srcFile could also be deleted here
> 2396... // renameTo or copyFile() which also calls requireCopyFile() and
> requireFile()
> {code}
> This pattern of calling validateMoveParameters() and requireFile() will throw
> IllegalArgumentException every when the srcFile is removed between between
> validateMoveParameters() and requireFile() or requireFileCopy() and
> requireFile()
> Preferably, it would be best if the 2.x versions of FileUtils were backwards
> compatible with 1.x and IllegalArgumentException would not be thrown, but
> IOException (or one of its derivatives) would be. IAE is an unchecked
> exception and can cause unexpected issues.
> I would also suggest that unit tests be created to ensure that these
> functions behave as expected in error conditions.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (RNG-186) Commons-RNG Simple imports package that Commons-RNG Core does not export
[
https://issues.apache.org/jira/browse/RNG-186?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17840396#comment-17840396
]
Gilles Sadowski commented on RNG-186:
-
bq. For my purposes, I have switched simply to using the Java Random class at
the moment.
https://commons.apache.org/proper/commons-rng/userguide/why_not_java_random.html
bq. You might consider using the
https://github.com/bndtools/bnd/blob/master/maven-plugins/bnd-testing-maven-plugin
[...]
Thanks for the suggestion
PR welcome that would set this up...
> Commons-RNG Simple imports package that Commons-RNG Core does not export
>
>
> Key: RNG-186
> URL: https://issues.apache.org/jira/browse/RNG-186
> Project: Commons RNG
> Issue Type: Task
> Components: core, simple
>Affects Versions: 1.5
>Reporter: Richard Eckart de Castilho
>Priority: Major
>
> Commons RNG Simple imports the following packages:
> {noformat}
> Bundle-SymbolicName: org.apache.commons.rng.simple
> Implementation-Version: 1.5
> Import-Package:
> org.apache.commons.rng,org.apache.commons.rng.core,
> org.apache.commons.rng.core.source32,
> org.apache.commons.rng.core.source64,
> org.apache.commons.rng.core.util
> {noformat}
> However, Commons RNG Core does not export the source packages:
> {noformat}
> Bundle-SymbolicName: org.apache.commons.rng.core
> Implementation-Version: 1.5
> Export-Package:
>
> org.apache.commons.rng.core;x-friends:="org.apache.commons.rng.simple";version="1.5.0"
> Private-Package:
> org.apache.commons.rng.core.source32,
> org.apache.commons.rng.core.source64,
> org.apache.commons.rng.core.util
> {noformat}
> Consequently, using Commons RNG simple fails in an OSGi environment as the
> bundle cannot be resolved.
> {noformat}
> [ERROR] Resolution failed. Capabilities satisfying the following requirements
> could not be found:
> [<>]
> ...
> ⇒ osgi.wiring.package:
> (&(osgi.wiring.package=org.apache.commons.rng.simple)(version>=1.5.0)(!(version>=2.0.0)))
> ⇒ [org.apache.commons.rng.simple version=1.5.0]
> ⇒ osgi.wiring.package:
> (osgi.wiring.package=org.apache.commons.rng.core.source32)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MATH-1667) none of the documentation api links work
[
https://issues.apache.org/jira/browse/MATH-1667?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17834259#comment-17834259
]
Gilles Sadowski commented on MATH-1667:
---
Commit ffcdf39f8fa7ccd19c5c21a73fccb90c753592cd has fixed some of the links.
Broken ones remain after the refactoring and some of the functionality having
been moved to other components (e.g. ["Commons
Statistics"|https://commons.apache.org/statistics]).
The editable source files of the userguide are the "xml" files in directory
{{src/site/xdoc/userguide}}.
You are most welcome to review them and provide fixes in a pull request.
> none of the documentation api links work
>
>
> Key: MATH-1667
> URL: https://issues.apache.org/jira/browse/MATH-1667
> Project: Commons Math
> Issue Type: Bug
>Reporter: robert engels
>Priority: Major
>
> Visit [https://commons.apache.org/proper/commons-math/userguide/fitting.html]
> and click on any of the links in the documentation on the right. None work.
> Makes it extremely difficult to use.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (COMPRESS-671) Commons-compress 1.26.0 is failing to compress files/directories
[
https://issues.apache.org/jira/browse/COMPRESS-671?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17827074#comment-17827074
]
Gilles Sadowski commented on COMPRESS-671:
--
Please have a look at the [release
notes|https://commons.apache.org/proper/commons-compress/changes-report.html].
> Commons-compress 1.26.0 is failing to compress files/directories
> -
>
> Key: COMPRESS-671
> URL: https://issues.apache.org/jira/browse/COMPRESS-671
> Project: Commons Compress
> Issue Type: Bug
>Reporter: Santhosh Kumar K
>Priority: Major
>
> We are using commons-compress to compress files and with latest 1.26.0 we are
> getting the following exception where in it was working fine with 1.24.0
> {*}API being used:{*}ArchiveOutputStream jos = new ArchiveStreamFactory()
> .createArchiveOutputStream(ArchiveStreamFactory.ZIP,
> Files.newOutputStream(WrapperFactory.getNioServiceWrapper().getPath(jarName)));
> *Stack trace:*
> [Feb 28, 2024 5:42:32 PM] [INFO] Stack Description:
> java.lang.RuntimeException: ApplySession failed but Oracle Home has not been
> modified.org/apache/commons/io/Charsets
> at
> org.apache.commons.compress.archivers.zip.ZipEncodingHelper.getZipEncoding(ZipEncodingHelper.java:69)
> at
> org.apache.commons.compress.archivers.zip.ZipEncodingHelper.(ZipEncodingHelper.java:37)
> at
> org.apache.commons.compress.archivers.zip.ZipArchiveOutputStream.(ZipArchiveOutputStream.java:331)
> at
> org.apache.commons.compress.archivers.ArchiveStreamFactory.createArchiveOutputStream(ArchiveStreamFactory.java:516)
> at
> org.apache.commons.compress.archivers.ArchiveStreamFactory.createArchiveOutputStream(ArchiveStreamFactory.java:498)
> at
> oracle.opatch.ZipUtilities.compressZip(ZipUtilities.java:306)
> at
> oracle.opatch.opatchactions.DeleteAction.backupForRollback(DeleteAction.java:1262)
> at
> oracle.opatch.PatchObject.backupForRollback(PatchObject.java:5492)
> at
> oracle.opatch.ApplySession.processLocal(ApplySession.java:4027)
> at
> oracle.opatch.ApplySession.process(ApplySession.java:4989)
> at
> oracle.opatch.ApplySession.process(ApplySession.java:4842)
> at
> oracle.opatch.OPatchACL.processApply(OPatchACL.java:310)
> at
> oracle.opatch.opatchutil.NApply.legacy_process(NApply.java:1469)
> at
> oracle.opatch.opatchutil.NApply.legacy_process(NApply.java:373)
> at
> oracle.opatch.opatchutil.NApply.process(NApply.java:353)
> at
> oracle.opatch.opatchutil.OUSession.napply(OUSession.java:1139)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at
> java.lang.reflect.Method.invoke(Method.java:498)
> at
> oracle.opatch.UtilSession.process(UtilSession.java:355)
> at
> oracle.opatch.OPatchSession.process(OPatchSession.java:2640)
> at
> oracle.opatch.OPatch.process(OPatch.java:873)
> at
> oracle.opatch.OPatch.main(OPatch.java:930)
> Caused by: java.lang.RuntimeException:
> ApplySession failed but Oracle Home has not been
> modified.org/apache/commons/io/Charsets
> ... 24 more
> Caused by:
> java.lang.NoClassDefFoundError: org/apache/commons/io/Charsets
> ... 24 more
> Caused by:
> java.lang.ClassNotFoundException: org.apache.commons.io.Charsets
> at
> java.net.URLClassLoader.findClass(URLClassLoader.java:387)
> at
> java.lang.ClassLoader.loadClass(ClassLoader.java:418)
> at
>
[jira] [Moved] (COMPRESS-671) Commons-compress 1.26.0 is failing to compress files/directories
[
https://issues.apache.org/jira/browse/COMPRESS-671?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gilles Sadowski moved COMMONSSITE-170 to COMPRESS-671:
--
Key: COMPRESS-671 (was: COMMONSSITE-170)
Project: Commons Compress (was: Apache Commons All)
> Commons-compress 1.26.0 is failing to compress files/directories
> -
>
> Key: COMPRESS-671
> URL: https://issues.apache.org/jira/browse/COMPRESS-671
> Project: Commons Compress
> Issue Type: Bug
>Reporter: Santhosh Kumar K
>Priority: Major
>
> We are using commons-compress to compress files and with latest 1.26.0 we are
> getting the following exception where in it was working fine with 1.24.0
> {*}API being used:{*}ArchiveOutputStream jos = new ArchiveStreamFactory()
> .createArchiveOutputStream(ArchiveStreamFactory.ZIP,
> Files.newOutputStream(WrapperFactory.getNioServiceWrapper().getPath(jarName)));
> *Stack trace:*
> [Feb 28, 2024 5:42:32 PM] [INFO] Stack Description:
> java.lang.RuntimeException: ApplySession failed but Oracle Home has not been
> modified.org/apache/commons/io/Charsets
> at
> org.apache.commons.compress.archivers.zip.ZipEncodingHelper.getZipEncoding(ZipEncodingHelper.java:69)
> at
> org.apache.commons.compress.archivers.zip.ZipEncodingHelper.(ZipEncodingHelper.java:37)
> at
> org.apache.commons.compress.archivers.zip.ZipArchiveOutputStream.(ZipArchiveOutputStream.java:331)
> at
> org.apache.commons.compress.archivers.ArchiveStreamFactory.createArchiveOutputStream(ArchiveStreamFactory.java:516)
> at
> org.apache.commons.compress.archivers.ArchiveStreamFactory.createArchiveOutputStream(ArchiveStreamFactory.java:498)
> at
> oracle.opatch.ZipUtilities.compressZip(ZipUtilities.java:306)
> at
> oracle.opatch.opatchactions.DeleteAction.backupForRollback(DeleteAction.java:1262)
> at
> oracle.opatch.PatchObject.backupForRollback(PatchObject.java:5492)
> at
> oracle.opatch.ApplySession.processLocal(ApplySession.java:4027)
> at
> oracle.opatch.ApplySession.process(ApplySession.java:4989)
> at
> oracle.opatch.ApplySession.process(ApplySession.java:4842)
> at
> oracle.opatch.OPatchACL.processApply(OPatchACL.java:310)
> at
> oracle.opatch.opatchutil.NApply.legacy_process(NApply.java:1469)
> at
> oracle.opatch.opatchutil.NApply.legacy_process(NApply.java:373)
> at
> oracle.opatch.opatchutil.NApply.process(NApply.java:353)
> at
> oracle.opatch.opatchutil.OUSession.napply(OUSession.java:1139)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at
> java.lang.reflect.Method.invoke(Method.java:498)
> at
> oracle.opatch.UtilSession.process(UtilSession.java:355)
> at
> oracle.opatch.OPatchSession.process(OPatchSession.java:2640)
> at
> oracle.opatch.OPatch.process(OPatch.java:873)
> at
> oracle.opatch.OPatch.main(OPatch.java:930)
> Caused by: java.lang.RuntimeException:
> ApplySession failed but Oracle Home has not been
> modified.org/apache/commons/io/Charsets
> ... 24 more
> Caused by:
> java.lang.NoClassDefFoundError: org/apache/commons/io/Charsets
> ... 24 more
> Caused by:
> java.lang.ClassNotFoundException: org.apache.commons.io.Charsets
> at
> java.net.URLClassLoader.findClass(URLClassLoader.java:387)
> at
> java.lang.ClassLoader.loadClass(ClassLoader.java:418)
> at
>
[jira] [Commented] (MATH-1661) Support Java module/automatic module
[ https://issues.apache.org/jira/browse/MATH-1661?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17825711#comment-17825711 ] Gilles Sadowski commented on MATH-1661: --- bq. This isn't full Java Module support, and is not usable for users who are trying to use jlink. Please report (and explain) the issue to the "dev" ML. Patches (compatible with Java 8) welcome. > Support Java module/automatic module > > > Key: MATH-1661 > URL: https://issues.apache.org/jira/browse/MATH-1661 > Project: Commons Math > Issue Type: Improvement >Reporter: Mark Woon >Priority: Major > Attachments: MANIFEST.MF > > > Please support java modules (with module-info.java) or add > Automatic-Module-Name to MANIFEST.MF. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MATH-1667) none of the documentation api links work
[ https://issues.apache.org/jira/browse/MATH-1667?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17821819#comment-17821819 ] Gilles Sadowski commented on MATH-1667: --- Thanks for the report and sorry about that. I think that the issue is related to the modularization (and the links still point to where the targets were before the modularization). > none of the documentation api links work > > > Key: MATH-1667 > URL: https://issues.apache.org/jira/browse/MATH-1667 > Project: Commons Math > Issue Type: Bug >Reporter: robert engels >Priority: Major > > Visit [https://commons.apache.org/proper/commons-math/userguide/fitting.html] > and click on any of the links in the documentation on the right. None work. > Makes it extremely difficult to use. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MATH-1656) Classical multivariate optimizers (gradient descent, Raphson-Newton, BFGS) are missing
[ https://issues.apache.org/jira/browse/MATH-1656?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17810950#comment-17810950 ] Gilles Sadowski commented on MATH-1656: --- Hi. Before being diverted, I performed several local changes, following the discussion about incremental modification and overall current design of the "optim" package. I'm afraid that your new patch will likely be quite incompatible with what I intended to commit. I'll try to sort that out ASAP, and we'll then resume from there. Sorry for the inconvenience! > Classical multivariate optimizers (gradient descent, Raphson-Newton, BFGS) > are missing > -- > > Key: MATH-1656 > URL: https://issues.apache.org/jira/browse/MATH-1656 > Project: Commons Math > Issue Type: Wish > Components: legacy >Affects Versions: 4.0-beta1 >Reporter: François Laferrière >Priority: Major > Labels: features > Attachments: MATH-1656-GradientDescent-Newton-BFGS-v2.0.zip, > MATH-1656-GradientDescent-Newton-BFGS-v4.0.patch.zip, > MATH-1658-GradientDescent-Newton-BFGS-v3.0.patch, > MATH-1658-GradientDescent-Newton-BFGS-v3.1.patch.zip, > MATH-1658-GradientDescent-Newton-BFGS.patch, Screenshot from 2023-07-10 > 12-13-38.png > > > Some classical multivariate such as > * gradient descent, > * Raphson-Newton, > * BFGS > are missing. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (GEOMETRY-162) Hash collision for vectors symmetrical about coordinate hyperplanes
[
https://issues.apache.org/jira/browse/GEOMETRY-162?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17807259#comment-17807259
]
Gilles Sadowski commented on GEOMETRY-162:
--
Hi.
Please edit the description and enclose code excerpts between "\{code}" tags
(this will avoid spurious interpretation of certain character sequences by the
JIRA software).
{quote}I've prepared a couple of simple unit tests in `Vector2DTest` and
`Vector3DTest` classes illustrating the issue.
{quote}
To help the reviewers, could you please attach "patch" files to this report, or
open pull requests (one with unit tests failing with the current code, and one
with the proposed fix)?
{quote}[...] same value of hash code is returned where it is expected to be
different for non-identical instances [...]
{quote}
When 2 instances are deemed equal (according to the
[{{equals}}|https://docs.oracle.com/javase/8/docs/api/java/lang/Object.html#equals-java.lang.Object-]
method), their hash codes must be equal.
Although desirable, the hash code is not _required_ to be different for
different instances (excerpt from
[{{hashCode}}|https://docs.oracle.com/javase/8/docs/api/java/lang/Object.html#hashCode--]
doc):
{noformat}
As much as is reasonably practical, the hashCode method defined by class Object
does return distinct integers for distinct objects.
{noformat}
However, what you noticed is probably unintentional, and should thus be
addressed. Thank you for the report!
> Hash collision for vectors symmetrical about coordinate hyperplanes
> ---
>
> Key: GEOMETRY-162
> URL: https://issues.apache.org/jira/browse/GEOMETRY-162
> Project: Commons Geometry
> Issue Type: Bug
> Components: euclidean2D, euclidean3D
>Reporter: Ivan Shuba
>Priority: Minor
> Labels: Bug
>
> h1. Overview
> This issue is related to that the same value of hash code is returned where
> it is expected to be different for non-identical instances of `Vector2D` and
> `Vector3D` classes.
> In particular, for 2D case, if we generate a pair of vectors which are
> symmetrical about the X, or Y coordinate axes, then both such vectors will
> return same hash code value. For 3D case, the hash code seems to be equal
> only if the vectors are symmetrical about YZ plane.
> h2. Examples
> The following examples illustrate the problem and can be easily reproduced.
> h4. The Vector2D case, symmetrical about Y axis
> For example, if we have a following pair of collinear `Vector2D` instances:
> {{Vector2D a = Vector2D.of(-10.0, 0); //400556032}}
> {{Vector2D b = Vector2D.of(+10.0, 0); //400556032}}
> Then they both will return a value of 400556032 if the `hashCode()` method is
> called.
> The same will happen if we make non-collinear pair of symmetrical vectors (
> with non-zero value of Y coordinate ):
> {{Vector2D a = Vector2D.of(-20.0, 10.0); //-326631424}}
> {{Vector2D b = Vector2D.of(+20.0, 10.0); //-326631424}}
> h4. The Vector2D case, symmetrical about X axis
> The same holds if we consider a pair of vectors symmetrical about X axis
> {{Vector2D a = Vector2D.of(10.0, -30.0); //-1251213312}}
> {{Vector2D b = Vector2D.of(10.0, +30.0); //-1251213312}}
> Even if we generate arbitrary random number to test the issue, the vectors
> will still return the same hash code value.
> final double ANY = Math.random();
> {{int hashA = Vector2D.of(10.0, ANY); }}
> {{int hashB = Vector2D.of(10.0, ANY); }}
> {{Assertions.assertNotEquals(hashA, hashB); // fails}}
> h4. The Vector3D case
> For Vector3D class, the issue seems to arise only if the instances are
> symmetrical about YZ plane.
>
> {{final double ANY = Math.random();}}
> {{final double NEG = -ANY;}}
> {{final double POS = +ANY;}}
> {{int negX = Vector3D.of(NEG, 0.0, 0.0);}}
> {{int posX = Vector3D.of(POS, 0.0, 0.0);}}
> int negY = Vector3D.of(0.0, NEG, 0.0);{{int posY = Vector3D.of(0.0, POS,
> 0.0);}}
> {{int negZ = Vector3D.of(0.0, 0.0, NEG);}}
> {{int posZ = Vector3D.of(0.0, 0.0, POS);}}
> {{Assertions.assertNotEquals(negX, posX); // fails}}
> {{Assertions.assertNotEquals(negY, posY); // passes}}
> {{Assertions.assertNotEquals(negZ, posZ); // passes}}
> h2. Possible solution
> To avoid clashes one could use modified version of the `hashCode` method.
> Here's one for Vector3D class:
>
> {{@Override}}
> {{public int hashCode() {}}
> {{ int result;}}
> {{ long temp;}}
> {{ temp = Double.doubleToLongBits(x);}}
> {{ result = (int) (temp ^ (temp >>> 32));}}
> {{ temp = Double.doubleToLongBits(y);}}
> {{ result = 31 * result + (int) (temp ^ (temp >>> 32));}}
> {{ temp = Double.doubleToLongBits(z);}}
> {{ result = 31 * result + (int) (temp ^ (temp >>> 32));}}
> {{ return result;}}
> {{}}}
>
> P.S. I've prepared a couple of simple unit tests in `Vector2DTest` and
>
[jira] [Commented] (CLI-322) Allow kabab-case options
[ https://issues.apache.org/jira/browse/CLI-322?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17804293#comment-17804293 ] Gilles Sadowski commented on CLI-322: - bq. Says who? FTR, many, many years ago, I suggested changes to Commons CLI (to allow less awkward/more standard usage, I vaguely recall); it had been rejected; I don't remember the detailed reason but it could have been equated to "no new features" indeed. Since then, I turned to "picocli". > Allow kabab-case options > > > Key: CLI-322 > URL: https://issues.apache.org/jira/browse/CLI-322 > Project: Commons CLI > Issue Type: New Feature > Components: Parser >Affects Versions: 1.6.0 >Reporter: Claude Warren >Assignee: Claude Warren >Priority: Minor > Fix For: 1.7.0 > > > Currently the '-' is not allowed in the option name. This change is to allow > '-' as an option name. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MATH-1656) Classical multivariate optimizers (gradient descent, Raphson-Newton, BFGS) are missing
[ https://issues.apache.org/jira/browse/MATH-1656?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17788592#comment-17788592 ] Gilles Sadowski commented on MATH-1656: --- I'll resume reviewing... (sorry for the delay). > Classical multivariate optimizers (gradient descent, Raphson-Newton, BFGS) > are missing > -- > > Key: MATH-1656 > URL: https://issues.apache.org/jira/browse/MATH-1656 > Project: Commons Math > Issue Type: Wish > Components: legacy >Affects Versions: 4.0-beta1 >Reporter: François Laferrière >Priority: Major > Labels: features > Attachments: MATH-1656-GradientDescent-Newton-BFGS-v2.0.zip, > MATH-1658-GradientDescent-Newton-BFGS-v3.0.patch, > MATH-1658-GradientDescent-Newton-BFGS-v3.1.patch.zip, > MATH-1658-GradientDescent-Newton-BFGS.patch, Screenshot from 2023-07-10 > 12-13-38.png > > > Some classical multivariate such as > * gradient descent, > * Raphson-Newton, > * BFGS > are missing. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MATH-1666) Hide "LineSearch"
[
https://issues.apache.org/jira/browse/MATH-1666?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17788591#comment-17788591
]
Gilles Sadowski commented on MATH-1666:
---
Commit aaa39b8fd5a2b1dbe4e883e027e932aa8703e55d (in "master").
> Hide "LineSearch"
> -
>
> Key: MATH-1666
> URL: https://issues.apache.org/jira/browse/MATH-1666
> Project: Commons Math
> Issue Type: Task
> Components: legacy
>Affects Versions: 4.0-beta1
>Reporter: Gilles Sadowski
>Assignee: Gilles Sadowski
>Priority: Minor
> Labels: API
> Fix For: 4.0-beta2
>
>
> The
> [{{LineSearch}}|https://github.com/apache/commons-math/blob/master/commons-math-legacy/src/main/java/org/apache/commons/math4/legacy/optim/nonlinear/scalar/LineSearch.java]
> class is a sort of a hack in that in holds a reference to the "main"
> optimizer. It is an implementation detail that should be removed from the
> public API.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (LANG-1719) RandomStringUtils.random outputs strings that are equal over and over
[
https://issues.apache.org/jira/browse/LANG-1719?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17788006#comment-17788006
]
Gilles Sadowski commented on LANG-1719:
---
bq. I can confirm that java.util.concurrent.ThreadLocalRandom keeps printing
the same number sequence after an app restart on Android version 33 and below.
[Stunning|https://xkcd.com/221/].
bq. Every Android app developer who expects RandomUtils.random() to return
random strings will run into the same issue as I have as soon as they update
commons-lang3 from version 3.12.0 to 3.13.0.
Sad; and pretty dangerous!
> RandomStringUtils.random outputs strings that are equal over and over
> -
>
> Key: LANG-1719
> URL: https://issues.apache.org/jira/browse/LANG-1719
> Project: Commons Lang
> Issue Type: Bug
> Components: lang.*
>Affects Versions: 3.13.0
> Environment: Samsung Smartphone
> Product name: Galaxy A53 5G
> Model name: SM-A536B/DS
> Software info:
> One UI version 5.1
> Android version 13
>Reporter: Benjamin Glatzeder
>Priority: Major
> Fix For: 3.12.0
>
>
> The following line of code outputs equal strings over and over:
> {code:java}
> RandomStringUtils.random(12,"abcdefghijklmnopqrstuvwxyz0123456789") {code}
> Steps to reproduce:
> 1) Create a new Android project in Android Studio
> 2) Add the following dependency to your gradle file
> {code:bash}
> implementation("org.apache.commons:commons-lang3:3.13.0") {code}
> 3) Use the following code in your MainActivity:
> {code:java}
> package test.randomstringutils
> import android.os.Bundle
> import android.util.Log
> import androidx.activity.ComponentActivity
> import org.apache.commons.lang3.RandomStringUtils
> class MainActivity : ComponentActivity() {
> override fun onCreate(savedInstanceState : Bundle?) {
> super.onCreate(savedInstanceState)
> val randomString =
> RandomStringUtils.random(12,"abcdefghijklmnopqrstuvwxyz0123456789")
> Log.d(TAG, randomString)
> }
> companion object {
> private const val TAG = "TAG"
> }
> }
> {code}
> 4) Run project and note the string in Logcat
> 5) Run project again and compare the new random string in Logcat
> One will note that the strings are equal. The expected result should be that
> the strings are not equal. Here's an example output:
> {code:java}
> 09:33:10.154 TAG tes...tringutils D m9mcx5ywuxdc
> 09:33:28.561 TAG tes...tringutils D m9mcx5ywuxdc
> {code}
> Using the previous commons-lang3 version in the project resolves the issue.
> Here are the steps to reproduce:
> 1) Replace
> {code:bash}
> implementation("org.apache.commons:commons-lang3:3.13.0") {code}
> with
> {code:bash}
> implementation("org.apache.commons:commons-lang3:3.12.0") {code}
> 2) Click on "Sync now"
> 3) Run project and note the string in Logcat
> 4) Run project again and compare the new random string in Logcat
> One will note that the strings are not equal. This is the expected result.
> Here's an example output:
> {code:java}
> 09:40:50.268 TAG tes...tringutils D 1tjkvkta6ibi
> 09:40:55.324 TAG tes...tringutils D 02nfvrf9pfgl{code}
>
> I was able to consistently reproduce this issue using a Samsung Galaxy A53 5G
> smartphone as well as on an Android Virtual Device (AVD). To the best of my
> knowledge the smartphone runs on an ARM processor and the AVD has an emulated
> ARM processor.
> I was *not* able to reproduce this issue when I created a Kotlin project in
> IntelliJ with similar lines of code which was running on my Windows machine
> with an x64 processor.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (LANG-1719) RandomStringUtils.random outputs strings that are equal over and over
[
https://issues.apache.org/jira/browse/LANG-1719?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17787962#comment-17787962
]
Gilles Sadowski commented on LANG-1719:
---
Do you mean that {{ThreadLocalRandom}} is buggy in "Android"?
> RandomStringUtils.random outputs strings that are equal over and over
> -
>
> Key: LANG-1719
> URL: https://issues.apache.org/jira/browse/LANG-1719
> Project: Commons Lang
> Issue Type: Bug
> Components: lang.*
>Affects Versions: 3.13.0
> Environment: Samsung Smartphone
> Product name: Galaxy A53 5G
> Model name: SM-A536B/DS
> Software info:
> One UI version 5.1
> Android version 13
>Reporter: Benjamin Glatzeder
>Priority: Major
> Fix For: 3.12.0
>
>
> The following line of code outputs equal strings over and over:
> {code:java}
> RandomStringUtils.random(12,"abcdefghijklmnopqrstuvwxyz0123456789") {code}
> Steps to reproduce:
> 1) Create a new Android project in Android Studio
> 2) Add the following dependency to your gradle file
> {code:bash}
> implementation("org.apache.commons:commons-lang3:3.13.0") {code}
> 3) Use the following code in your MainActivity:
> {code:java}
> package test.randomstringutils
> import android.os.Bundle
> import android.util.Log
> import androidx.activity.ComponentActivity
> import org.apache.commons.lang3.RandomStringUtils
> class MainActivity : ComponentActivity() {
> override fun onCreate(savedInstanceState : Bundle?) {
> super.onCreate(savedInstanceState)
> val randomString =
> RandomStringUtils.random(12,"abcdefghijklmnopqrstuvwxyz0123456789")
> Log.d(TAG, randomString)
> }
> companion object {
> private const val TAG = "TAG"
> }
> }
> {code}
> 4) Run project and note the string in Logcat
> 5) Run project again and compare the new random string in Logcat
> One will note that the strings are equal. The expected result should be that
> the strings are not equal. Here's an example output:
> {code:java}
> 09:33:10.154 TAG tes...tringutils D m9mcx5ywuxdc
> 09:33:28.561 TAG tes...tringutils D m9mcx5ywuxdc
> {code}
> Using the previous commons-lang3 version in the project resolves the issue.
> Here are the steps to reproduce:
> 1) Replace
> {code:bash}
> implementation("org.apache.commons:commons-lang3:3.13.0") {code}
> with
> {code:bash}
> implementation("org.apache.commons:commons-lang3:3.12.0") {code}
> 2) Click on "Sync now"
> 3) Run project and note the string in Logcat
> 4) Run project again and compare the new random string in Logcat
> One will note that the strings are not equal. This is the expected result.
> Here's an example output:
> {code:java}
> 09:40:50.268 TAG tes...tringutils D 1tjkvkta6ibi
> 09:40:55.324 TAG tes...tringutils D 02nfvrf9pfgl{code}
>
> I was able to consistently reproduce this issue using a Samsung Galaxy A53 5G
> smartphone as well as on an Android Virtual Device (AVD). To the best of my
> knowledge the smartphone runs on an ARM processor and the AVD has an emulated
> ARM processor.
> I was *not* able to reproduce this issue when I created a Kotlin project in
> IntelliJ with similar lines of code which was running on my Windows machine
> with an x64 processor.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (LANG-1719) RandomStringUtils.random outputs strings that are equal over and over
[
https://issues.apache.org/jira/browse/LANG-1719?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17787691#comment-17787691
]
Gilles Sadowski commented on LANG-1719:
---
Maybe related: https://issuetracker.google.com/issues/234631055?pli=1
> RandomStringUtils.random outputs strings that are equal over and over
> -
>
> Key: LANG-1719
> URL: https://issues.apache.org/jira/browse/LANG-1719
> Project: Commons Lang
> Issue Type: Bug
> Components: lang.*
>Affects Versions: 3.13.0
> Environment: Samsung Smartphone
> Product name: Galaxy A53 5G
> Model name: SM-A536B/DS
> Software info:
> One UI version 5.1
> Android version 13
>Reporter: Benjamin Glatzeder
>Priority: Major
> Fix For: 3.12.0
>
>
> The following line of code outputs equal strings over and over:
> {code:java}
> RandomStringUtils.random(12,"abcdefghijklmnopqrstuvwxyz0123456789") {code}
> Steps to reproduce:
> 1) Create a new Android project in Android Studio
> 2) Add the following dependency to your gradle file
> {code:bash}
> implementation("org.apache.commons:commons-lang3:3.13.0") {code}
> 3) Use the following code in your MainActivity:
> {code:java}
> package test.randomstringutils
> import android.os.Bundle
> import android.util.Log
> import androidx.activity.ComponentActivity
> import org.apache.commons.lang3.RandomStringUtils
> class MainActivity : ComponentActivity() {
> override fun onCreate(savedInstanceState : Bundle?) {
> super.onCreate(savedInstanceState)
> val randomString =
> RandomStringUtils.random(12,"abcdefghijklmnopqrstuvwxyz0123456789")
> Log.d(TAG, randomString)
> }
> companion object {
> private const val TAG = "TAG"
> }
> }
> {code}
> 4) Run project and note the string in Logcat
> 5) Run project again and compare the new random string in Logcat
> One will note that the strings are equal. The expected result should be that
> the strings are not equal. Here's an example output:
> {code:java}
> 09:33:10.154 TAG tes...tringutils D m9mcx5ywuxdc
> 09:33:28.561 TAG tes...tringutils D m9mcx5ywuxdc
> {code}
> Using the previous commons-lang3 version in the project resolves the issue.
> Here are the steps to reproduce:
> 1) Replace
> {code:bash}
> implementation("org.apache.commons:commons-lang3:3.13.0") {code}
> with
> {code:bash}
> implementation("org.apache.commons:commons-lang3:3.12.0") {code}
> 2) Click on "Sync now"
> 3) Run project and note the string in Logcat
> 4) Run project again and compare the new random string in Logcat
> One will note that the strings are not equal. This is the expected result.
> Here's an example output:
> {code:java}
> 09:40:50.268 TAG tes...tringutils D 1tjkvkta6ibi
> 09:40:55.324 TAG tes...tringutils D 02nfvrf9pfgl{code}
>
> I was able to consistently reproduce this issue using a Samsung Galaxy A53 5G
> smartphone as well as on an Android Virtual Device (AVD). To the best of my
> knowledge the smartphone runs on an ARM processor and the AVD has an emulated
> ARM processor.
> I was *not* able to reproduce this issue when I created a Kotlin project in
> IntelliJ with similar lines of code which was running on my Windows machine
> with an x64 processor.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (MATH-1666) Hide "LineSearch"
[
https://issues.apache.org/jira/browse/MATH-1666?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gilles Sadowski updated MATH-1666:
--
Fix Version/s: 4.0-beta2
> Hide "LineSearch"
> -
>
> Key: MATH-1666
> URL: https://issues.apache.org/jira/browse/MATH-1666
> Project: Commons Math
> Issue Type: Task
> Components: legacy
>Affects Versions: 4.0-beta1
>Reporter: Gilles Sadowski
>Assignee: Gilles Sadowski
>Priority: Minor
> Labels: API
> Fix For: 4.0-beta2
>
>
> The
> [{{LineSearch}}|https://github.com/apache/commons-math/blob/master/commons-math-legacy/src/main/java/org/apache/commons/math4/legacy/optim/nonlinear/scalar/LineSearch.java]
> class is a sort of a hack in that in holds a reference to the "main"
> optimizer. It is an implementation detail that should be removed from the
> public API.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MATH-1661) Support Java module/automatic module
[ https://issues.apache.org/jira/browse/MATH-1661?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17785590#comment-17785590 ] Gilles Sadowski commented on MATH-1661: --- Does it mean that whether the file will exist or not, depends on the release manager's environment? > Support Java module/automatic module > > > Key: MATH-1661 > URL: https://issues.apache.org/jira/browse/MATH-1661 > Project: Commons Math > Issue Type: Improvement >Reporter: Mark Woon >Priority: Major > Attachments: MANIFEST.MF > > > Please support java modules (with module-info.java) or add > Automatic-Module-Name to MANIFEST.MF. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MATH-1661) Support Java module/automatic module
[ https://issues.apache.org/jira/browse/MATH-1661?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17785499#comment-17785499 ] Gilles Sadowski commented on MATH-1661: --- A (too) quick look on the web reveals that it should be possible with "multi-release" JAR files. However, I recollect from several threads on the ML that Commons components should not use this feature (?). Some feedback, [~ggregory] on where we stand now? > Support Java module/automatic module > > > Key: MATH-1661 > URL: https://issues.apache.org/jira/browse/MATH-1661 > Project: Commons Math > Issue Type: Improvement >Reporter: Mark Woon >Priority: Major > Attachments: MANIFEST.MF > > > Please support java modules (with module-info.java) or add > Automatic-Module-Name to MANIFEST.MF. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CRYPTO-176) Drop dependency on Commons IO?
[ https://issues.apache.org/jira/browse/CRYPTO-176?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17784770#comment-17784770 ] Gilles Sadowski commented on CRYPTO-176: IMHO, there is no such thing as "unnecessary dependencies" (aka "do not reinvent the wheel"). Code duplication should occur only if a dependency is forbidden for a specific reason, not just to avoid it per se. If that were a good reason, no software would have them. Having "large quantities of duplicated code" is often the result of "Oh, let's not add a dependency for just a few lines". We already had those discussions. My focus was/is on sharing and maintainability being primary virtues; "no dependency" is only a virtue if it serves a purpose other than itself. Of course, there will be code duplication across different projects, but across components of the same project, we should avoid it by default. > Drop dependency on Commons IO? > -- > > Key: CRYPTO-176 > URL: https://issues.apache.org/jira/browse/CRYPTO-176 > Project: Commons Crypto > Issue Type: Improvement >Reporter: Sebb >Priority: Minor > > Commons IO is currently a dependency, but the only reference is to a single > method: > IOUtils.contentEquals > Consider whether to replace the dependency with local code. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CRYPTO-176) Drop dependency on Commons IO?
[ https://issues.apache.org/jira/browse/CRYPTO-176?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17784566#comment-17784566 ] Gilles Sadowski commented on CRYPTO-176: IMO, the issue is rather the code duplication. Those examples demonstrate that not all components are equally "low-level" (I once proposed to delineate a "hierarchy" of the components that would clearly _define_ which can depend on which). > Drop dependency on Commons IO? > -- > > Key: CRYPTO-176 > URL: https://issues.apache.org/jira/browse/CRYPTO-176 > Project: Commons Crypto > Issue Type: Improvement >Reporter: Sebb >Priority: Minor > > Commons IO is currently a dependency, but the only reference is to a single > method: > IOUtils.contentEquals > Consider whether to replace the dependency with local code. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (MATH-1666) Hide "LineSearch"
[
https://issues.apache.org/jira/browse/MATH-1666?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gilles Sadowski updated MATH-1666:
--
Component/s: legacy
(was: legacy-core)
> Hide "LineSearch"
> -
>
> Key: MATH-1666
> URL: https://issues.apache.org/jira/browse/MATH-1666
> Project: Commons Math
> Issue Type: Task
> Components: legacy
>Affects Versions: 4.0-beta1
>Reporter: Gilles Sadowski
>Assignee: Gilles Sadowski
>Priority: Minor
> Labels: API
>
> The
> [{{LineSearch}}|https://github.com/apache/commons-math/blob/master/commons-math-legacy/src/main/java/org/apache/commons/math4/legacy/optim/nonlinear/scalar/LineSearch.java]
> class is a sort of a hack in that in holds a reference to the "main"
> optimizer. It is an implementation detail that should be removed from the
> public API.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (MATH-1666) Hide "LineSearch"
Gilles Sadowski created MATH-1666:
-
Summary: Hide "LineSearch"
Key: MATH-1666
URL: https://issues.apache.org/jira/browse/MATH-1666
Project: Commons Math
Issue Type: Task
Components: legacy-core
Affects Versions: 4.0-beta1
Reporter: Gilles Sadowski
Assignee: Gilles Sadowski
The
[{{LineSearch}}|https://github.com/apache/commons-math/blob/master/commons-math-legacy/src/main/java/org/apache/commons/math4/legacy/optim/nonlinear/scalar/LineSearch.java]
class is a sort of a hack in that in holds a reference to the "main"
optimizer. It is an implementation detail that should be removed from the
public API.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (COMMONSSITE-150) Maven Central link/badge for "Commons Numbers" v1.0
[ https://issues.apache.org/jira/browse/COMMONSSITE-150?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gilles Sadowski resolved COMMONSSITE-150. - Resolution: Cannot Reproduce bq. mail link is broken :-( I forgot what this was about, and I don't readily find the link in the other archive. Thus closing. > Maven Central link/badge for "Commons Numbers" v1.0 > --- > > Key: COMMONSSITE-150 > URL: https://issues.apache.org/jira/browse/COMMONSSITE-150 > Project: Apache Commons All > Issue Type: Task > Components: Site >Reporter: Gilles Sadowski >Priority: Major > > See [post on the "dev" ML|https://markmail.org/message/njrhacbh3begxclj]. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (STATISTICS-71) Implementation of Univariate Statistics
[
https://issues.apache.org/jira/browse/STATISTICS-71?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17772554#comment-17772554
]
Gilles Sadowski commented on STATISTICS-71:
---
Hi [~aherbert].
Can this work lead to some cleanup in Commons Math (classes to delete, code to
replace with calls to [Statistics])?
> Implementation of Univariate Statistics
> ---
>
> Key: STATISTICS-71
> URL: https://issues.apache.org/jira/browse/STATISTICS-71
> Project: Commons Statistics
> Issue Type: Task
> Components: descriptive
>Reporter: Anirudh Joshi
>Assignee: Anirudh Joshi
>Priority: Minor
> Labels: gsoc, gsoc2023
>
> Jira ticket to track the implementation of the Univariate statistics required
> for the updated SummaryStatistics API.
> The implementation would be "storeless". It should be used for calculating
> statistics that can be computed in one pass through the data without storing
> the sample values.
> Currently I have the definition of API as (this might evolve as I continue
> working)
> {code:java}
> public interface DoubleStorelessUnivariateStatistic extends DoubleSupplier {
> DoubleStorelessUnivariateStatistic add(double v);
> long getCount();
> void combine(DoubleStorelessUnivariateStatistic other);
> } {code}
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IO-814) FileUtils.deleteDirectory can throw UncheckedIOException
[ https://issues.apache.org/jira/browse/IO-814?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17771526#comment-17771526 ] Gilles Sadowski commented on IO-814: bq. This was a behavior breaking change, [...] There is no denying that it is not nice to users who relied on the previous behaviour. bq. [...] an incorrect one to boot. Although it could/should have occurred in a new major version, it is not incorrect if one assumes that the API should switch to not using checked exceptions. bq. Operations that can have I/O errors should throw IOException if they can't directly handle the I/O error. As discussed previously, there is no agreement on when to use a checked exception. IMHO, checked exceptions bring (much) more pain than (supposed) robustness. bq. UncheckedIOException is not a reasonable alternative. Why was it introduced in the JDK? bq. A method that can neither handle nor throw IOException must not perform I/O operations. A developer could decide to never use checked exceptions; writing a program will still be possible. Some programming languages even made that decision for all developers. ;-) bq. It's worth noting that functional programming, not just in Java but in general, does not allow I/O. As soon as a method performs I/O, it's no longer a pure function and should not be written in a functional style. Such a rule could indeed be useful to limit the trend that everything is "forced" into functional style seemingly to save a couple of lines (while a side-effect is often that it becomes much less readable). > FileUtils.deleteDirectory can throw UncheckedIOException > > > Key: IO-814 > URL: https://issues.apache.org/jira/browse/IO-814 > Project: Commons IO > Issue Type: Bug >Affects Versions: 2.13.0, 2.14.0 >Reporter: Elliotte Rusty Harold >Priority: Critical > > This was a behavior breaking change, and an incorrect one to boot. > Operations that can have I/O errors should throw IOException if they can't > directly handle the I/O error. UncheckedIOException is not a reasonable > alternative. > A method that can neither handle nor throw IOException must not perform I/O > operations. > It's worth noting that functional programming, not just in Java but in > general, does not allow I/O. As soon as a method performs I/O, it's no longer > a pure function and should not be written in a functional style. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (NUMBERS-203) Add a field for the DD number
[ https://issues.apache.org/jira/browse/NUMBERS-203?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17762803#comment-17762803 ] Gilles Sadowski commented on NUMBERS-203: - bq. It is difficult to code an algorithm for any value type. [...] I'm referring to implementations such as [FieldBracketingNthOrderBrentSolver|https://commons.apache.org/proper/commons-math/javadocs/api-4.0-beta1/org/apache/commons/math4/legacy/analysis/solvers/FieldBracketingNthOrderBrentSolver.html]. > Add a field for the DD number > - > > Key: NUMBERS-203 > URL: https://issues.apache.org/jira/browse/NUMBERS-203 > Project: Commons Numbers > Issue Type: New Feature > Components: field >Reporter: Alex Herbert >Priority: Minor > Fix For: 1.2 > > > The field module can add a DDField class to allow using the double-double > number as a field. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MATH-1656) Classical multivariate optimizers (gradient descent, Raphson-Newton, BFGS) are missing
[
https://issues.apache.org/jira/browse/MATH-1656?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17760898#comment-17760898
]
Gilles Sadowski commented on MATH-1656:
---
bq. [...] It is not practical to extends MathRuntimeException that require
Localizable in constructor.
Quite right.
Eventually we concluded that following the JDK semantics was more useful than a
shared infrastructure (requiring that all CM exceptions inherit from
{{MathRuntimeException}}) imposing a maintenance burden for a feature (French
localization) which no one uses (anymore).
bq. [...] exemple of new style *Exception.
All the new (recent) math-related components/modules try to only expose the
standard exception types.
See e.g. how
[{{FastFourierTransform}}|https://github.com/apache/commons-math/blob/master/commons-math-transform/src/main/java/org/apache/commons/math4/transform/FastFourierTransform.java]
uses
[{{TransformException}}|https://github.com/apache/commons-math/blob/master/commons-math-transform/src/main/java/org/apache/commons/math4/transform/TransformException.java]
but the latter is package-private.
The same pattern is at play in "Commons Numbers" (see e.g. the
[commons-numers-gamma|https://github.com/apache/commons-numbers/tree/master/commons-numbers-gamma/src/main/java/org/apache/commons/numbers/gamma]
module).
Alternatively, "Commons Geometry" directly throws instances of the standard JDK
exception in most cases; sometimes, it defines custom types in an "internal"
package (not to be used by application developers): See e.g.
[{{GeometryInternalError}}|https://github.com/apache/commons-geometry/blob/master/commons-geometry-core/src/main/java/org/apache/commons/geometry/core/internal/GeometryInternalError.java]
in
[{{WelzlEncloser}}|https://github.com/apache/commons-geometry/blob/master/commons-geometry-enclosing/src/main/java/org/apache/commons/geometry/enclosing/WelzlEncloser.java]
class.
> Classical multivariate optimizers (gradient descent, Raphson-Newton, BFGS)
> are missing
> --
>
> Key: MATH-1656
> URL: https://issues.apache.org/jira/browse/MATH-1656
> Project: Commons Math
> Issue Type: Wish
> Components: legacy
>Affects Versions: 4.0-beta1
>Reporter: François Laferrière
>Priority: Major
> Labels: features
> Attachments: MATH-1656-GradientDescent-Newton-BFGS-v2.0.zip,
> MATH-1658-GradientDescent-Newton-BFGS-v3.0.patch,
> MATH-1658-GradientDescent-Newton-BFGS.patch, Screenshot from 2023-07-10
> 12-13-38.png
>
>
> Some classical multivariate such as
> * gradient descent,
> * Raphson-Newton,
> * BFGS
> are missing.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MATH-1656) Classical multivariate optimizers (gradient descent, Raphson-Newton, BFGS) are missing
[
https://issues.apache.org/jira/browse/MATH-1656?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17759397#comment-17759397
]
Gilles Sadowski commented on MATH-1656:
---
* Javadoc
** Cf. MATH-1665
** Please try and follow the style used e.g. in {{SimplexOptimizer}}.
* {{MathArrays}}
** See utilities in "Commons Numbers" (e.g. "Norm" in "core" module)
** Methods never ({{scaleInPlace}}), or rarely ({{unitaryVector}}), used
should not be "public"
* {{BaseOptimizer}}
** Visibility of method {{resetCounters}} (needlessly?) increased from
"private" to "protected"
* {{DoubleData}}, {{DoubleStrictlyPositiveData}},
{{ObjectiveFunctionDimension}}, {{SearchRange}}
** Cf. previous review.
* {{DebugMode}}
** Rather than storing debugging info (cf. {{trajectory}} field), maybe add a
callback interface, like in {{SimplexOptimizer}} (?)
* {{MinDirectionNorm}}
** Should be clarified, renamed, better documented (reference)
** Perhaps moved as an inner class of {{GradientLikeOptimizer}}
* {{OptimizationStatus}}
** To be discussed, as it departs from current usage.
If agreed on, it should be applied in all implementations (not only in
{{GradientLikeOptimizer}}).
* Remove commented-out code (e.g. "MultivariateCalliper")
* Usage of "LocalizedFormats" is being abandoned (not used in new modules)
* Better add new exception classes close to where they are used (dedicated
"exception" package is being abandoned)
* {{MultivariateOptimizer}}
** Visiblity of {{getObjectiveFunction}} increased to "public" (to be
discussed)
* Constant must declared "final" and private, and its name be uppercase (e.g.
{{MIN_GRADIENT_NORM}}, not {{minGradientNorm}})
* {{minGradientNorm}} should be private as it is used only once.
* {{TestFunction}}, {{TestFunctionGradient}}, {{TestFunctionHessian}}
** Should be a single "enum" with accessors to the objective, gradient and
Hessian functions.
> Classical multivariate optimizers (gradient descent, Raphson-Newton, BFGS)
> are missing
> --
>
> Key: MATH-1656
> URL: https://issues.apache.org/jira/browse/MATH-1656
> Project: Commons Math
> Issue Type: Wish
> Components: legacy
>Affects Versions: 4.0-beta1
>Reporter: François Laferrière
>Priority: Major
> Labels: features
> Attachments: MATH-1656-GradientDescent-Newton-BFGS-v2.0.zip,
> MATH-1658-GradientDescent-Newton-BFGS-v3.0.patch,
> MATH-1658-GradientDescent-Newton-BFGS.patch, Screenshot from 2023-07-10
> 12-13-38.png
>
>
> Some classical multivariate such as
> * gradient descent,
> * Raphson-Newton,
> * BFGS
> are missing.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MATH-1656) Classical multivariate optimizers (gradient descent, Raphson-Newton, BFGS) are missing
[ https://issues.apache.org/jira/browse/MATH-1656?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17759254#comment-17759254 ] Gilles Sadowski commented on MATH-1656: --- Sorry for the delay in responding; I had started reviewing but then stumbled on a "no-go" (see MATH-1665) which I thought was enforced by the default build. IIRC, there were also other issues (some of which I had already listed previously, like some of the new "OptimizationData" classes). On the one hand, this is all in the "legacy" package, so the API "cleanliness" is not that important maybe; but still, adding to the public API should, in principle, be discussed if just in case someone finds a better way... > Classical multivariate optimizers (gradient descent, Raphson-Newton, BFGS) > are missing > -- > > Key: MATH-1656 > URL: https://issues.apache.org/jira/browse/MATH-1656 > Project: Commons Math > Issue Type: Wish > Components: legacy >Affects Versions: 4.0-beta1 >Reporter: François Laferrière >Priority: Major > Labels: features > Attachments: MATH-1656-GradientDescent-Newton-BFGS-v2.0.zip, > MATH-1658-GradientDescent-Newton-BFGS-v3.0.patch, > MATH-1658-GradientDescent-Newton-BFGS.patch, Screenshot from 2023-07-10 > 12-13-38.png > > > Some classical multivariate such as > * gradient descent, > * Raphson-Newton, > * BFGS > are missing. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (NUMBERS-203) Add a field for the DD number
[ https://issues.apache.org/jira/browse/NUMBERS-203?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17759249#comment-17759249 ] Gilles Sadowski commented on NUMBERS-203: - Thanks for pointing out "113 bits vs 106 bits". Perhaps the link to the "quadruple-precision" article would be useful in the Javadoc as a "caveat". It's great that "Commons Numbers" provides higher-precision so that users don't have to worry about the implementation and just try out whether it helps with their actual application. :-) Would it make sense to create a new "field" module in "Commons Math" whose scope would be implementations of miscellaneous algorithms based on the "Field" interface? A low-priority "new feature" that could be (?) an interesting first task for a would-be contributor... > Add a field for the DD number > - > > Key: NUMBERS-203 > URL: https://issues.apache.org/jira/browse/NUMBERS-203 > Project: Commons Numbers > Issue Type: New Feature > Components: field >Reporter: Alex Herbert >Priority: Minor > > The field module can add a DDField class to allow using the double-double > number as a field. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (NUMBERS-203) Add a field for the DD number
[
https://issues.apache.org/jira/browse/NUMBERS-203?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17759114#comment-17759114
]
Gilles Sadowski commented on NUMBERS-203:
-
Thanks for the DD implementation, [~aherbert].
I was going to ask about the "field" feature; for completeness. :-)
bq. DDField class
Should {{DD}} be wrapped in a new {{FP128}} class in the
{{org.apache.commons.numbers.field}} package, and the corresponding "field" be
named {{FP128Field}} (mirroring {{FP64Field}})?
> Add a field for the DD number
> -
>
> Key: NUMBERS-203
> URL: https://issues.apache.org/jira/browse/NUMBERS-203
> Project: Commons Numbers
> Issue Type: New Feature
> Components: field
>Reporter: Alex Herbert
>Priority: Minor
>
> The field module can add a DDField class to allow using the double-double
> number as a field.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (LANG-1707) Syntactic sugar to concatenate arrays
[
https://issues.apache.org/jira/browse/LANG-1707?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17756196#comment-17756196
]
Gilles Sadowski commented on LANG-1707:
---
bq. common sense
Seriously. Commons sense would rather be to _first_ decide whether such
functionality is worth including.
> Syntactic sugar to concatenate arrays
> -
>
> Key: LANG-1707
> URL: https://issues.apache.org/jira/browse/LANG-1707
> Project: Commons Lang
> Issue Type: Wish
> Components: lang.*
>Affects Versions: 3.13.0
>Reporter: Gilles Sadowski
>Priority: Trivial
> Labels: suggestion
> Fix For: 3.14.0
>
>
> In {{ArrayUtils}}, a method such as {{addAll(T[], T ... others)}} makes it
> easy to concatenate two arrays.
> Then, one can concatenate several arrays:
> {code}
> /**
> * @param Type.
> * @param arrays Arrays.
> * @return an array that contains all the elements in the input arrays.
> */
> private static T[] concat(T[] ... arrays) {
> final int numArr = arrays.length;
> T[] concatenated = null;
> for (int i = numArr; i > 0; i--) {
> concatenated = ArrayUtils.addAll(arrays[i - 1], concatenated);
> }
> return concatenated;
> }
> {code}
> Shouldn't {{concat(T[] ...)}} be part of {{ArrayUtils}}?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (LANG-1707) Syntactic sugar to concatenate arrays
[
https://issues.apache.org/jira/browse/LANG-1707?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gilles Sadowski updated LANG-1707:
--
Summary: Syntactic sugar to concatenate arrays (was: Syntactic suger to
concatenate arrays)
> Syntactic sugar to concatenate arrays
> -
>
> Key: LANG-1707
> URL: https://issues.apache.org/jira/browse/LANG-1707
> Project: Commons Lang
> Issue Type: Wish
> Components: lang.*
>Affects Versions: 3.13.0
>Reporter: Gilles Sadowski
>Priority: Trivial
> Labels: suggestion
> Fix For: 3.14.0
>
>
> In {{ArrayUtils}}, a method such as {{addAll(T[], T ... others)}} makes it
> easy to concatenate two arrays.
> Then, one can concatenate several arrays:
> {code}
> /**
> * @param Type.
> * @param arrays Arrays.
> * @return an array that contains all the elements in the input arrays.
> */
> private static T[] concat(T[] ... arrays) {
> final int numArr = arrays.length;
> T[] concatenated = null;
> for (int i = numArr; i > 0; i--) {
> concatenated = ArrayUtils.addAll(arrays[i - 1], concatenated);
> }
> return concatenated;
> }
> {code}
> Shouldn't {{concat(T[] ...)}} be part of {{ArrayUtils}}?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (LANG-1707) Syntactic suger to concatenate arrays
[
https://issues.apache.org/jira/browse/LANG-1707?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17756015#comment-17756015
]
Gilles Sadowski commented on LANG-1707:
---
bq. Maybe [...]
If not "for sure", why discuss implementation details?
bq. [...] implementation should allocate a single array, not a temporary array
for each input element.
Of course, I agree that it would be a performance improvement; the "prototype"
calls existing methods so that it automatically provides the same functionality
(e.g. handling of certain arguments like {{null}}). Modifications can be made
after unit tests have ensured that the simple implementation works as intended
(even if "slowly").
Perhaps the functionality should be implemented via "Stream" (?).
> Syntactic suger to concatenate arrays
> -
>
> Key: LANG-1707
> URL: https://issues.apache.org/jira/browse/LANG-1707
> Project: Commons Lang
> Issue Type: Wish
> Components: lang.*
>Affects Versions: 3.13.0
>Reporter: Gilles Sadowski
>Priority: Trivial
> Labels: suggestion
> Fix For: 3.14.0
>
>
> In {{ArrayUtils}}, a method such as {{addAll(T[], T ... others)}} makes it
> easy to concatenate two arrays.
> Then, one can concatenate several arrays:
> {code}
> /**
> * @param Type.
> * @param arrays Arrays.
> * @return an array that contains all the elements in the input arrays.
> */
> private static T[] concat(T[] ... arrays) {
> final int numArr = arrays.length;
> T[] concatenated = null;
> for (int i = numArr; i > 0; i--) {
> concatenated = ArrayUtils.addAll(arrays[i - 1], concatenated);
> }
> return concatenated;
> }
> {code}
> Shouldn't {{concat(T[] ...)}} be part of {{ArrayUtils}}?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (LANG-1708) Usage of "ReflectionDiffBuilder"
[
https://issues.apache.org/jira/browse/LANG-1708?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gilles Sadowski updated LANG-1708:
--
Issue Type: Bug (was: Wish)
> Usage of "ReflectionDiffBuilder"
>
>
> Key: LANG-1708
> URL: https://issues.apache.org/jira/browse/LANG-1708
> Project: Commons Lang
> Issue Type: Bug
> Components: lang.builder.*
>Affects Versions: 3.13.0
>Reporter: Gilles Sadowski
>Priority: Major
> Labels: functional, utility
> Fix For: 3.14.0
>
> Attachments: LANG-1708.unit_test.patch
>
>
> If we have either this class
> {code}
> private static class MyDirect {
> private float value;
> MyDirect(float a) {
> value = a;
> }
> }
> {code}
> or this class
> {code}
> private static class MyReference {
> private MyDirect value;
> MyReference(float a) {
> value = new MyDirect(a);
> }
> }
> {code}
> it could be argued that they are _functionally_ equivalent; IOW, code that
> uses one or the other (say, via a library) would consider it an
> implementation detail (e.g. if that library changed one for the other in some
> internal object).
> [{{ReflectionDiffBuilder}}|https://commons.apache.org/proper/commons-lang/apidocs/org/apache/commons/lang3/builder/ReflectionDiffBuilder.html]
> however behaves differently: Two instances with the same information
> contents (a primitive {{float}} value, from the caller POV) are considered
> the same in the former case and *not the same* in the latter.
> It will be noted that neither class defines an {{equals(Object)}} method;
> were it the case, the documentation of {{ReflectionDiffBuilder}}
> [constructor|https://commons.apache.org/proper/commons-lang/apidocs/org/apache/commons/lang3/builder/ReflectionDiffBuilder.html#ReflectionDiffBuilder-T-T-org.apache.commons.lang3.builder.ToStringStyle-]
> says:
> {noformat}
> If lhs == rhs or lhs.equals(rhs) then the builder will not evaluate any calls
> to append(...) and will return an empty DiffResult when build() is executed.
> {noformat}
> However there are the use-cases
> # (as above) where {{equals}} was not overridden (and the source code cannot
> be modified by the user who wants to list the differences, or ensure there
> are none, functionally), and
> # where one would want to list (potential) differences that could exist even
> if {{equals}} would return {{true}} (e.g. if {{equals}} is buggy).
> IMHO:
> * Current behaviour is inconsistent (even if intended).
> * There should be a way to disable the equality check (i.e. *always* use
> reflection to list the differences).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (LANG-1709) Check for "deep" copy
Gilles Sadowski created LANG-1709:
-
Summary: Check for "deep" copy
Key: LANG-1709
URL: https://issues.apache.org/jira/browse/LANG-1709
Project: Commons Lang
Issue Type: Wish
Components: lang.builder.*
Reporter: Gilles Sadowski
Wouldn't it be useful to have a way to easily check whether some object is a
deep copy of another? I.e. the two instances could be "equal" but the utility
function would return "false" if they share a mutable field.
More generally, how about a function like
{code:java}
public SomeUtils {
/**
* @return true if "a" and "b" do not share any mutable field.
*/
public static boolean areIndependent(T a, T b) { /* ... */ }
// ...
}
{code}
?
It seems that this could (?) be built upon
[{{ReflectionDiffBuilder}}|https://commons.apache.org/proper/commons-lang/apidocs/org/apache/commons/lang3/builder/ReflectionDiffBuilder.html].
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (LANG-1708) Usage of "ReflectionDiffBuilder"
[
https://issues.apache.org/jira/browse/LANG-1708?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17755954#comment-17755954
]
Gilles Sadowski commented on LANG-1708:
---
[Attachment|^LANG-1708.unit_test.patch] is a patch for the unit tests class
that demonstrates the described behaviour.
> Usage of "ReflectionDiffBuilder"
>
>
> Key: LANG-1708
> URL: https://issues.apache.org/jira/browse/LANG-1708
> Project: Commons Lang
> Issue Type: Wish
> Components: lang.builder.*
>Affects Versions: 3.13.0
>Reporter: Gilles Sadowski
>Priority: Major
> Labels: functional, utility
> Fix For: 3.14.0
>
> Attachments: LANG-1708.unit_test.patch
>
>
> If we have either this class
> {code}
> private static class MyDirect {
> private float value;
> MyDirect(float a) {
> value = a;
> }
> }
> {code}
> or this class
> {code}
> private static class MyReference {
> private MyDirect value;
> MyReference(float a) {
> value = new MyDirect(a);
> }
> }
> {code}
> it could be argued that they are _functionally_ equivalent; IOW, code that
> uses one or the other (say, via a library) would consider it an
> implementation detail (e.g. if that library changed one for the other in some
> internal object).
> [{{ReflectionDiffBuilder}}|https://commons.apache.org/proper/commons-lang/apidocs/org/apache/commons/lang3/builder/ReflectionDiffBuilder.html]
> however behaves differently: Two instances with the same information
> contents (a primitive {{float}} value, from the caller POV) are considered
> the same in the former case and *not the same* in the latter.
> It will be noted that neither class defines an {{equals(Object)}} method;
> were it the case, the documentation of {{ReflectionDiffBuilder}}
> [constructor|https://commons.apache.org/proper/commons-lang/apidocs/org/apache/commons/lang3/builder/ReflectionDiffBuilder.html#ReflectionDiffBuilder-T-T-org.apache.commons.lang3.builder.ToStringStyle-]
> says:
> {noformat}
> If lhs == rhs or lhs.equals(rhs) then the builder will not evaluate any calls
> to append(...) and will return an empty DiffResult when build() is executed.
> {noformat}
> However there are the use-cases
> # (as above) where {{equals}} was not overridden (and the source code cannot
> be modified by the user who wants to list the differences, or ensure there
> are none, functionally), and
> # where one would want to list (potential) differences that could exist even
> if {{equals}} would return {{true}} (e.g. if {{equals}} is buggy).
> IMHO:
> * Current behaviour is inconsistent (even if intended).
> * There should be a way to disable the equality check (i.e. *always* use
> reflection to list the differences).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (LANG-1708) Usage of "ReflectionDiffBuilder"
[
https://issues.apache.org/jira/browse/LANG-1708?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gilles Sadowski updated LANG-1708:
--
Attachment: LANG-1708.unit_test.patch
> Usage of "ReflectionDiffBuilder"
>
>
> Key: LANG-1708
> URL: https://issues.apache.org/jira/browse/LANG-1708
> Project: Commons Lang
> Issue Type: Wish
> Components: lang.builder.*
>Affects Versions: 3.13.0
>Reporter: Gilles Sadowski
>Priority: Major
> Labels: functional, utility
> Fix For: 3.14.0
>
> Attachments: LANG-1708.unit_test.patch
>
>
> If we have either this class
> {code}
> private static class MyDirect {
> private float value;
> MyDirect(float a) {
> value = a;
> }
> }
> {code}
> or this class
> {code}
> private static class MyReference {
> private MyDirect value;
> MyReference(float a) {
> value = new MyDirect(a);
> }
> }
> {code}
> it could be argued that they are _functionally_ equivalent; IOW, code that
> uses one or the other (say, via a library) would consider it an
> implementation detail (e.g. if that library changed one for the other in some
> internal object).
> [{{ReflectionDiffBuilder}}|https://commons.apache.org/proper/commons-lang/apidocs/org/apache/commons/lang3/builder/ReflectionDiffBuilder.html]
> however behaves differently: Two instances with the same information
> contents (a primitive {{float}} value, from the caller POV) are considered
> the same in the former case and *not the same* in the latter.
> It will be noted that neither class defines an {{equals(Object)}} method;
> were it the case, the documentation of {{ReflectionDiffBuilder}}
> [constructor|https://commons.apache.org/proper/commons-lang/apidocs/org/apache/commons/lang3/builder/ReflectionDiffBuilder.html#ReflectionDiffBuilder-T-T-org.apache.commons.lang3.builder.ToStringStyle-]
> says:
> {noformat}
> If lhs == rhs or lhs.equals(rhs) then the builder will not evaluate any calls
> to append(...) and will return an empty DiffResult when build() is executed.
> {noformat}
> However there are the use-cases
> # (as above) where {{equals}} was not overridden (and the source code cannot
> be modified by the user who wants to list the differences, or ensure there
> are none, functionally), and
> # where one would want to list (potential) differences that could exist even
> if {{equals}} would return {{true}} (e.g. if {{equals}} is buggy).
> IMHO:
> * Current behaviour is inconsistent (even if intended).
> * There should be a way to disable the equality check (i.e. *always* use
> reflection to list the differences).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (LANG-1708) Usage of "ReflectionDiffBuilder"
Gilles Sadowski created LANG-1708:
-
Summary: Usage of "ReflectionDiffBuilder"
Key: LANG-1708
URL: https://issues.apache.org/jira/browse/LANG-1708
Project: Commons Lang
Issue Type: Wish
Components: lang.builder.*
Affects Versions: 3.13.0
Reporter: Gilles Sadowski
Fix For: 3.14.0
If we have either this class
{code}
private static class MyDirect {
private float value;
MyDirect(float a) {
value = a;
}
}
{code}
or this class
{code}
private static class MyReference {
private MyDirect value;
MyReference(float a) {
value = new MyDirect(a);
}
}
{code}
it could be argued that they are _functionally_ equivalent; IOW, code that uses
one or the other (say, via a library) would consider it an implementation
detail (e.g. if that library changed one for the other in some internal object).
[{{ReflectionDiffBuilder}}|https://commons.apache.org/proper/commons-lang/apidocs/org/apache/commons/lang3/builder/ReflectionDiffBuilder.html]
however behaves differently: Two instances with the same information contents
(a primitive {{float}} value, from the caller POV) are considered the same in
the former case and *not the same* in the latter.
It will be noted that neither class defines an {{equals(Object)}} method; were
it the case, the documentation of {{ReflectionDiffBuilder}}
[constructor|https://commons.apache.org/proper/commons-lang/apidocs/org/apache/commons/lang3/builder/ReflectionDiffBuilder.html#ReflectionDiffBuilder-T-T-org.apache.commons.lang3.builder.ToStringStyle-]
says:
{noformat}
If lhs == rhs or lhs.equals(rhs) then the builder will not evaluate any calls
to append(...) and will return an empty DiffResult when build() is executed.
{noformat}
However there are the use-cases
# (as above) where {{equals}} was not overridden (and the source code cannot be
modified by the user who wants to list the differences, or ensure there are
none, functionally), and
# where one would want to list (potential) differences that could exist even if
{{equals}} would return {{true}} (e.g. if {{equals}} is buggy).
IMHO:
* Current behaviour is inconsistent (even if intended).
* There should be a way to disable the equality check (i.e. *always* use
reflection to list the differences).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (LANG-1707) Syntactic suger to concatenate arrays
Gilles Sadowski created LANG-1707:
-
Summary: Syntactic suger to concatenate arrays
Key: LANG-1707
URL: https://issues.apache.org/jira/browse/LANG-1707
Project: Commons Lang
Issue Type: Wish
Components: lang.*
Affects Versions: 3.13.0
Reporter: Gilles Sadowski
Fix For: 3.14.0
In {{ArrayUtils}}, a method such as {{addAll(T[], T ... others)}} makes it easy
to concatenate two arrays.
Then, one can concatenate several arrays:
{code}
/**
* @param Type.
* @param arrays Arrays.
* @return an array that contains all the elements in the input arrays.
*/
private static T[] concat(T[] ... arrays) {
final int numArr = arrays.length;
T[] concatenated = null;
for (int i = numArr; i > 0; i--) {
concatenated = ArrayUtils.addAll(arrays[i - 1], concatenated);
}
return concatenated;
}
{code}
Shouldn't {{concat(T[] ...)}} be part of {{ArrayUtils}}?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Closed] (CLI-319) Is there a plan to release a new version?
[ https://issues.apache.org/jira/browse/CLI-319?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gilles Sadowski closed CLI-319. --- Resolution: Feedback Received JIRA is the issue-tracking tool. Please [subscribe|https://commons.apache.org/mail-lists.html] to the "user" mailing list and ask there. > Is there a plan to release a new version? > - > > Key: CLI-319 > URL: https://issues.apache.org/jira/browse/CLI-319 > Project: Commons CLI > Issue Type: Wish >Reporter: Radar wen >Priority: Major > > It has been a long time since the previous software version was released. Is > there any plan to release a new software version? -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (COLLECTIONS-845) Is there a plan to release a new version?
[ https://issues.apache.org/jira/browse/COLLECTIONS-845?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gilles Sadowski closed COLLECTIONS-845. --- Resolution: Feedback Received JIRA is the issue-tracking tool. Please [subscribe|https://commons.apache.org/mail-lists.html] to the "user" mailing list and ask there. > Is there a plan to release a new version? > - > > Key: COLLECTIONS-845 > URL: https://issues.apache.org/jira/browse/COLLECTIONS-845 > Project: Commons Collections > Issue Type: Wish >Reporter: Radar wen >Priority: Major > > It has been a long time since the previous software version was released. Is > there any plan to release a new software version? -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (MATH-1664) interpolate should return Map instead of double[]
[ https://issues.apache.org/jira/browse/MATH-1664?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gilles Sadowski resolved MATH-1664. --- Resolution: Feedback Received > interpolate should return Map instead of double[] > - > > Key: MATH-1664 > URL: https://issues.apache.org/jira/browse/MATH-1664 > Project: Commons Math > Issue Type: Improvement > Components: core >Affects Versions: 3.6.1 >Reporter: Hasan Diwan >Priority: Minor > > It should be considered to have the interpolate method return a Map Double> (or Map where the key would be a descriptive label of > what it means. There doesn't seem to be any indication of what the various > elements represent, either in the javadocs, nor the source code. > If someone would be so kind and tell me what the numbers represent, I am > willing to patch the project myself and issue a pull request. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MATH-1663) GuassianCurveFitter interpolate
[ https://issues.apache.org/jira/browse/MATH-1663?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17753567#comment-17753567 ] Gilles Sadowski commented on MATH-1663: --- [~hd1]? > GuassianCurveFitter interpolate > > > Key: MATH-1663 > URL: https://issues.apache.org/jira/browse/MATH-1663 > Project: Commons Math > Issue Type: Bug > Components: core >Affects Versions: 3.6.1 >Reporter: Hasan Diwan >Priority: Minor > > If the mean of my data is 1.54 and its standard deviation is 0.24, how is the > interpolation using the GaussianCurveFitter yielding 5.58, when all the > x-values differ by 1? -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (NUMBERS-193) Add support for extended precision floating-point numbers
[
https://issues.apache.org/jira/browse/NUMBERS-193?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17751963#comment-17751963
]
Gilles Sadowski commented on NUMBERS-193:
-
{quote}
* Adding the DD class in its current state to a new module
{quote}
It seems that it belongs to the {{core}} module.
{quote}
* Exposing the accurate versions of arithmetic operators in a helper class. A
use case may exist that I have not considered and these methods are still
reasonably fast (compared to BigDecimal) and are mostly double-double exact (or
within 1 rounding error).
{quote}
If no use-case is currently known, I'd delay the delay the decision to make
those part of the "public" API.
{quote}
* Any use of DD as a field would require a wrapper class to implement the
required NativeOperators interface
{quote}
As you noted, it would be fixed with the class being in {{core}}.
{quote}
* Updating downstream projects to use DD when possible
{quote}
+1
{quote}
* Possibly extending the current public API to expose more raw building block
methods for extended floating point arithmetic (fast-two-sum; two-sum;
two-product).
{quote}
Are these lower-level than {{DD}}?
IOW: What's the added value wrt {{DD}}?
{quote}
* Possibly adding a triple-double and/or quad double and/or arbitrary length
implementation. I currently have no use case for these so it would be an
academic exercise. The possible existence of e.g. a quad-double does possibly
impact package location and names for the parts of the number by allowing
standardising across implementations in a single package location.
{quote}
I imagine that the relative benefits of adding more components would not
increase as dramatically as with {{DD}}.
The question is indeed whether there are use cases where
# {{BigDecimal}} would be too slow, and
# users in those domains would be interested in a Java implementation.
{quote}
* Putting DD in numbers core
{quote}
+1
{quote}
* Names for factory constructor methods, i.e. of and from
{quote}
Should all be public?
An unsuspecting user like me might not understand why do
{code}
double a = ...
double b = ...
DD v = DD.ofSum(a, b);
{code}
instead of
{code}
DD v = DD.of(a).add(DD.of(b));
{code}
{quote}
* Names for the parts of the number: (x, xx) vs (x0, x1) vs (hi, lo) vs other
{quote}
(hi, lo) is self-documenting, and less error-prone.
Also, for searching within the code, it will be slightly easier that the two
fields have completely different names.
{quote}
* Hiding the accurate arithmetic methods
* Hiding the scaled power method (but is required for Statistics inference)
* Hiding the accurate scaled power method (this would require it remaining in
Statistics inference package)
{quote}
As argued elsewhere, I'd strongly prefer that quite non-obvious algorithms are
implemented in a single place.
> Add support for extended precision floating-point numbers
> -
>
> Key: NUMBERS-193
> URL: https://issues.apache.org/jira/browse/NUMBERS-193
> Project: Commons Numbers
> Issue Type: New Feature
> Components: ext
>Reporter: Alex Herbert
>Assignee: Alex Herbert
>Priority: Major
> Labels: full-time, gsoc2023, part-time
>
> Add implementations of extended precision floating point numbers.
> An extended precision floating point number is a series of floating-point
> numbers that are non-overlapping such that:
> {noformat}
> double-double (a, b):
> |a| > |b|
> a == a + b{noformat}
> Common representations are double-double and quad-double (see for example
> David Bailey's paper on a quad-double library:
> [QD|https://www.davidhbailey.com/dhbpapers/qd.pdf]).
> Many computations in the Commons Numbers and Statistics libraries use
> extended precision computations where the accumulated error of a double would
> lead to complete cancellation of all significant bits; or create intermediate
> overflow of integer values.
> This project would formalise the code underlying these use cases with a
> generic library applicable for use in the case where the result is expected
> to be a finite value and using Java's BigDecimal and/or BigInteger negatively
> impacts performance.
> An example would be the average of long values where the intermediate sum
> overflows or the conversion to a double loses bits:
> {code:java}
> long[] values = {Long.MAX_VALUE, Long.MAX_VALUE};
> System.out.println(Arrays.stream(values).average().getAsDouble());
> System.out.println(Arrays.stream(values).mapToObj(BigDecimal::valueOf)
> .reduce(BigDecimal.ZERO, BigDecimal::add)
> .divide(BigDecimal.valueOf(values.length)).doubleValue());
> long[] values2 = {Long.MAX_VALUE, Long.MIN_VALUE};
> System.out.println(Arrays.stream(values2).asDoubleStream().average().getAsDouble());
>
[jira] [Commented] (MATH-1665) Shouldn't the build fail on missing Javadoc?
[
https://issues.apache.org/jira/browse/MATH-1665?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17751322#comment-17751322
]
Gilles Sadowski commented on MATH-1665:
---
Setting added in commit 9e02432e06501f94690e172f3856450cd3a55a20 (on "master").
> Shouldn't the build fail on missing Javadoc?
>
>
> Key: MATH-1665
> URL: https://issues.apache.org/jira/browse/MATH-1665
> Project: Commons Math
> Issue Type: Task
> Components: legacy, legacy-core
>Reporter: Gilles Sadowski
>Priority: Minor
>
> Running maven (default goal) results in a successful build, even though some
> Javadoc is (partly) missing; e.g.
> {code}
> /**
> * @param lineSearcher
> */
> protected void setLineSearcher(LineSearch lineSearcher) {
> this.lineSearcher = lineSearcher;
> }
> {code}
> results in
> {noformat}
> [WARNING] * @param lineSearcher
> [WARNING] ^
> [WARNING]
> /home/gilles/gilles/devel/java/apache/commons-math/trunk/commons-math-legacy/src/main/java/org/apache/commons/math4/legacy/optim/nonlinear/scalar/gradient/GradientLikeOptimizer.java:209:
> warning: no description for @param
> {noformat}
> whereas, according to our "full documentation" requirement, the build should
> fail.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MATH-1665) Shouldn't the build fail on missing Javadoc?
[
https://issues.apache.org/jira/browse/MATH-1665?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17751321#comment-17751321
]
Gilles Sadowski commented on MATH-1665:
---
Yes, I remember about CheckStyle having been made more lenient.
But I'm actually referring to this property:
{noformat}
true
{noformat}
of the "maven-javadoc-plugin". On current "master" the build passes with this
setting, but will fail on subsequent changes that feature incomplete Javadoc:
{noformat}
6 warnings
[WARNING] Javadoc Warnings
[WARNING]
/home/gilles/gilles/devel/java/apache/commons-math/trunk/commons-math-legacy-core/src/main/java/org/apache/commons/math4/legacy/core/MathArrays.java:79:
warning: no description for @param
[WARNING] * @param x
[WARNING] ^
[WARNING]
/home/gilles/gilles/devel/java/apache/commons-math/trunk/commons-math-legacy-core/src/main/java/org/apache/commons/math4/legacy/core/MathArrays.java:124:
warning: no description for @param
[WARNING] * @param factor
[WARNING] ^
[WARNING]
/home/gilles/gilles/devel/java/apache/commons-math/trunk/commons-math-legacy-core/src/main/java/org/apache/commons/math4/legacy/core/MathArrays.java:125:
warning: no description for @param
[WARNING] * @param src
[WARNING] ^
[WARNING]
/home/gilles/gilles/devel/java/apache/commons-math/trunk/commons-math-legacy-core/src/main/java/org/apache/commons/math4/legacy/core/MathArrays.java:142:
warning: no description for @param
[WARNING] * @param factor
[WARNING] ^
[WARNING]
/home/gilles/gilles/devel/java/apache/commons-math/trunk/commons-math-legacy-core/src/main/java/org/apache/commons/math4/legacy/core/MathArrays.java:143:
warning: no description for @param
[WARNING] * @param src
[WARNING] ^
[WARNING]
/home/gilles/gilles/devel/java/apache/commons-math/trunk/commons-math-legacy-core/src/main/java/org/apache/commons/math4/legacy/core/MathArrays.java:156:
warning: no description for @param
[WARNING] * @param vector
[WARNING] ^
[INFO]
[INFO] Reactor Summary for Apache Commons Math 4.0-SNAPSHOT:
[INFO]
[INFO] Apache Commons Math SUCCESS [ 5.543 s]
[INFO] Miscellaneous core classes . SUCCESS [ 12.863 s]
[INFO] Artificial neural networks . SUCCESS [ 6.210 s]
[INFO] Transforms . SUCCESS [ 5.113 s]
[INFO] Exception classes (Legacy) . SUCCESS [ 5.121 s]
[INFO] Miscellaneous core classes (Legacy) FAILURE [ 14.014 s]
[INFO] Apache Commons Math (Legacy) ... SKIPPED
[INFO] Apache Commons Math Documentation .. SKIPPED
[INFO] Example applications ... SKIPPED
[INFO] SOFM ... SKIPPED
[INFO] SOFM: Chinese Rings SKIPPED
[INFO] SOFM: Traveling Salesman Problem ... SKIPPED
[INFO] K-Means SKIPPED
[INFO] K-Means: Image Clustering .. SKIPPED
[INFO]
[INFO] BUILD FAILURE
[INFO]
{noformat}
> Shouldn't the build fail on missing Javadoc?
>
>
> Key: MATH-1665
> URL: https://issues.apache.org/jira/browse/MATH-1665
> Project: Commons Math
> Issue Type: Task
> Components: legacy, legacy-core
>Reporter: Gilles Sadowski
>Priority: Minor
>
> Running maven (default goal) results in a successful build, even though some
> Javadoc is (partly) missing; e.g.
> {code}
> /**
> * @param lineSearcher
> */
> protected void setLineSearcher(LineSearch lineSearcher) {
> this.lineSearcher = lineSearcher;
> }
> {code}
> results in
> {noformat}
> [WARNING] * @param lineSearcher
> [WARNING] ^
> [WARNING]
> /home/gilles/gilles/devel/java/apache/commons-math/trunk/commons-math-legacy/src/main/java/org/apache/commons/math4/legacy/optim/nonlinear/scalar/gradient/GradientLikeOptimizer.java:209:
> warning: no description for @param
> {noformat}
> whereas, according to our "full documentation" requirement, the build should
> fail.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (MATH-1665) Shouldn't the build fail on missing Javadoc?
Gilles Sadowski created MATH-1665:
-
Summary: Shouldn't the build fail on missing Javadoc?
Key: MATH-1665
URL: https://issues.apache.org/jira/browse/MATH-1665
Project: Commons Math
Issue Type: Task
Components: legacy, legacy-core
Reporter: Gilles Sadowski
Running maven (default goal) results in a successful build, even though some
Javadoc is (partly) missing; e.g.
{code}
/**
* @param lineSearcher
*/
protected void setLineSearcher(LineSearch lineSearcher) {
this.lineSearcher = lineSearcher;
}
{code}
results in
{noformat}
[WARNING] * @param lineSearcher
[WARNING] ^
[WARNING]
/home/gilles/gilles/devel/java/apache/commons-math/trunk/commons-math-legacy/src/main/java/org/apache/commons/math4/legacy/optim/nonlinear/scalar/gradient/GradientLikeOptimizer.java:209:
warning: no description for @param
{noformat}
whereas, according to our "full documentation" requirement, the build should
fail.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (MATH-1663) GuassianCurveFitter interpolate
[ https://issues.apache.org/jira/browse/MATH-1663?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17751297#comment-17751297 ] Gilles Sadowski edited comment on MATH-1663 at 8/5/23 12:00 PM: Please put everything in a compilable Java source file (including the loop that reads the data input). Then attach that file to this report. Thanks. Note also that your data contains the string "NA"... was (Author: erans): Please put everything in a compilable Java source file (including the loop that reads the data input). Thanks. Note also that your data contains the string "NA"... > GuassianCurveFitter interpolate > > > Key: MATH-1663 > URL: https://issues.apache.org/jira/browse/MATH-1663 > Project: Commons Math > Issue Type: Bug > Components: core >Affects Versions: 3.6.1 >Reporter: Hasan Diwan >Priority: Minor > > If the mean of my data is 1.54 and its standard deviation is 0.24, how is the > interpolation using the GaussianCurveFitter yielding 5.58, when all the > x-values differ by 1? -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MATH-1663) GuassianCurveFitter interpolate
[ https://issues.apache.org/jira/browse/MATH-1663?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17751305#comment-17751305 ] Gilles Sadowski commented on MATH-1663: --- bq. // what are the elements of the array supposed to represent? See MATH-1664. > GuassianCurveFitter interpolate > > > Key: MATH-1663 > URL: https://issues.apache.org/jira/browse/MATH-1663 > Project: Commons Math > Issue Type: Bug > Components: core >Affects Versions: 3.6.1 >Reporter: Hasan Diwan >Priority: Minor > > If the mean of my data is 1.54 and its standard deviation is 0.24, how is the > interpolation using the GaussianCurveFitter yielding 5.58, when all the > x-values differ by 1? -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MATH-1663) GuassianCurveFitter interpolate
[ https://issues.apache.org/jira/browse/MATH-1663?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17751297#comment-17751297 ] Gilles Sadowski commented on MATH-1663: --- Please put everything in a compilable Java source file (including the loop that reads the data input). Thanks. Note also that your data contains the string "NA"... > GuassianCurveFitter interpolate > > > Key: MATH-1663 > URL: https://issues.apache.org/jira/browse/MATH-1663 > Project: Commons Math > Issue Type: Bug > Components: core >Affects Versions: 3.6.1 >Reporter: Hasan Diwan >Priority: Minor > > If the mean of my data is 1.54 and its standard deviation is 0.24, how is the > interpolation using the GaussianCurveFitter yielding 5.58, when all the > x-values differ by 1? -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MATH-1664) interpolate should return Map instead of double[]
[
https://issues.apache.org/jira/browse/MATH-1664?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17751288#comment-17751288
]
Gilles Sadowski commented on MATH-1664:
---
bq. There doesn't seem to be any indication of what the various elements
represent, either in the javadocs, [...]
Excerpt from the [API docs of
{{GaussianFitter}}|https://commons.apache.org/proper/commons-math/javadocs/api-4.0-beta1/org/apache/commons/math4/legacy/fitting/GaussianCurveFitter.html]:
{noformat}
Fits points to a Gaussian function.
The initial guess values must be passed in the following order:
Normalization
Mean
Sigma
The optimal values will be returned in the same order.
{noformat}
bq. [...] nor the source code.
The above is generated from the Javadoc in the [source
code|https://github.com/apache/commons-math/blob/master/commons-math-legacy/src/main/java/org/apache/commons/math4/legacy/fitting/GaussianCurveFitter.java].
bq. [...] have the interpolate method return a Map [...]
An array seemed the easiest way to return and use a very small set of values,
in a known order (as per the documentation); using a map for this looks like
overkill.
> interpolate should return Map instead of double[]
> -
>
> Key: MATH-1664
> URL: https://issues.apache.org/jira/browse/MATH-1664
> Project: Commons Math
> Issue Type: Improvement
> Components: core
>Affects Versions: 3.6.1
>Reporter: Hasan Diwan
>Priority: Minor
>
> It should be considered to have the interpolate method return a Map Double> (or Map where the key would be a descriptive label of
> what it means. There doesn't seem to be any indication of what the various
> elements represent, either in the javadocs, nor the source code.
> If someone would be so kind and tell me what the numbers represent, I am
> willing to patch the project myself and issue a pull request.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MATH-1663) GuassianCurveFitter interpolate
[ https://issues.apache.org/jira/browse/MATH-1663?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17751287#comment-17751287 ] Gilles Sadowski commented on MATH-1663: --- Could you post a minimal example (preferably a "Junit" test case) of the code and data that lead to such a result? > GuassianCurveFitter interpolate > > > Key: MATH-1663 > URL: https://issues.apache.org/jira/browse/MATH-1663 > Project: Commons Math > Issue Type: Bug > Components: core >Affects Versions: 3.6.1 >Reporter: Hasan Diwan >Priority: Minor > > If the mean of my data is 1.54 and its standard deviation is 0.24, how is the > interpolation using the GaussianCurveFitter yielding 5.58, when all the > x-values differ by 1? -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (GEOMETRY-110) 3D Convex Hull
[
https://issues.apache.org/jira/browse/GEOMETRY-110?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17749137#comment-17749137
]
Gilles Sadowski commented on GEOMETRY-110:
--
I'm uneasy with the suggestion (in [PR
#218|https://github.com/apache/commons-geometry/pull/218]) that a
{{toString()}} method would return a relatively long but truncated
representation of the instance.
I agree that an enormous String would probably be useless, but how useful would
be a truncated output?
Maybe a summary (number of points, edges and faces, plus settings like the
precision, etc...) would be enough (?).
> 3D Convex Hull
> --
>
> Key: GEOMETRY-110
> URL: https://issues.apache.org/jira/browse/GEOMETRY-110
> Project: Commons Geometry
> Issue Type: New Feature
>Reporter: Matt Juntunen
>Assignee: Matt Juntunen
>Priority: Major
> Fix For: 1.1
>
>
> We currently only have a 2D convex hull generator implementation. We should
> add a 3D convex hull implementation, perhaps based on the
> [Quickhull|https://en.wikipedia.org/wiki/Quickhull] algorithm.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IMAGING-356) TIFF reading extremely slow in version 1.0-SNAPSHOT
[
https://issues.apache.org/jira/browse/IMAGING-356?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17748918#comment-17748918
]
Gilles Sadowski commented on IMAGING-356:
-
{quote}{{ArrayIndexOutOfBounds}} [...] data[ y * width + x] = argb;
{quote}
Does this occur in a loop that updates all the "data" array? [Sorry, I didn't
follow the whole discussion.]
If so, the loop could be enclosed in a try/catch block so that the propagated
exception could convey that corruption was detected by the library.
> TIFF reading extremely slow in version 1.0-SNAPSHOT
> ---
>
> Key: IMAGING-356
> URL: https://issues.apache.org/jira/browse/IMAGING-356
> Project: Commons Imaging
> Issue Type: Bug
> Components: Format: TIFF
>Affects Versions: 1.0
>Reporter: Gary Lucas
>Priority: Major
> Attachments: image-2023-07-04-08-52-36-535.png
>
>
> I am using the latest code from github (1.0-SNAPSHOT downloaded from github
> of June 2023) to read a 300 megabyte TIFF file. Version 1.0-alpha3 required
> 673 milliseconds to read that file. The new code requires upward of 15
> minutes. Clearly something got broken since the last release.
> The TIFF file is a 1x1 pixel 4 byte image format organized in strips.
> The bottleneck appears to occur in the TiffReader getTiffRawImageData method
> which reads raw data from the file in preparation of creating a BufferedImage
> object.
> I suspect that there may be a general slowness of file access. In debugging,
> even reading the initial metadata (22 TIFF tags) took a couple of seconds.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (LANG-1704) ImmutablePair and ImmutableTriple implementation don't match final in Javadoc
[
https://issues.apache.org/jira/browse/LANG-1704?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17748915#comment-17748915
]
Gilles Sadowski commented on LANG-1704:
---
bq. That's never going to be true ...
IIUC, the OP said that the change broke his use-case. Maybe we need more
details on this but I can imagine that subverting the (strong) typing system is
not a good idea (passing an "ImmutablePair" that could not be immutable
also breaks the caller's expectation).
That functionality may have been broken, independently of the change being
binary and/or source compatible.
Immutable data-structures much simplify usage, with some trade-off (like no
support for inheritance).
What was the intended functionality?
Why the class was previously "final"?
Depending on the answer, removing "final" was wrong, or name of the class was
ill-chosen.
{quote}
* Allow typed subclasses, for example, MyCustomPair extends ImmutablePair
* Allow inline subclasses, for example, new ImmutablePair(foo, bar) \{ some
overrides } (handy when writing tests).
{quote}
AFAIK, this can be achieved through composition (more lines of code, sure)
increasing encapsulation, and thus safety. The latter is reduced when
increasing visibility; doing so for the sake of unit tests is not good.
> ImmutablePair and ImmutableTriple implementation don't match final in Javadoc
> -
>
> Key: LANG-1704
> URL: https://issues.apache.org/jira/browse/LANG-1704
> Project: Commons Lang
> Issue Type: Bug
> Components: lang.tuple.*
>Affects Versions: 3.13.0
>Reporter: Dan Ziemba
>Priority: Minor
> Fix For: 3.13.1
>
>
> As of commons-lang3 3.13.0, the ImmutablePair and ImmutableTriple classes are
> no longer final, even though their javadocs claim that they are. This is a
> problem because you can now subclass those and, for example, make an
> effectively mutable object that could be passed to a method with a parameter
> of type ImmutablePair.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (COMMONSSITE-166) CP 59 breaks the build
[
https://issues.apache.org/jira/browse/COMMONSSITE-166?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17748791#comment-17748791
]
Gilles Sadowski commented on COMMONSSITE-166:
-
Same behaviour in "Commons Numbers", "Commons RNG", "Commons Statistics".
Building "Commons Geometry" still works fine...
Issue is related to the module dedicated to Javadoc consolidation.
> CP 59 breaks the build
> --
>
> Key: COMMONSSITE-166
> URL: https://issues.apache.org/jira/browse/COMMONSSITE-166
> Project: Apache Commons All
> Issue Type: Bug
> Components: Commons Parent Pom
>Reporter: Gilles Sadowski
>Priority: Major
>
> Running (default goal) in the "Commons Math" project:
> {noformat}
> $ mvn
> [...]
> [INFO] Apache Commons Math SUCCESS [ 6.032
> s]
> [INFO] Miscellaneous core classes . SUCCESS [ 13.118
> s]
> [INFO] Artificial neural networks . SUCCESS [ 6.032
> s]
> [INFO] Transforms . SUCCESS [ 4.970
> s]
> [INFO] Exception classes (Legacy) . SUCCESS [ 5.137
> s]
> [INFO] Miscellaneous core classes (Legacy) SUCCESS [ 13.605
> s]
> [INFO] Apache Commons Math (Legacy) ... SUCCESS [01:19
> min]
> [INFO] Apache Commons Math Documentation .. FAILURE [ 0.311
> s]
> [INFO] Example applications ... SKIPPED
> [INFO] SOFM ... SKIPPED
> [INFO] SOFM: Chinese Rings SKIPPED
> [INFO] SOFM: Traveling Salesman Problem ... SKIPPED
> [INFO] K-Means SKIPPED
> [INFO] K-Means: Image Clustering .. SKIPPED
> [INFO]
>
> [INFO] BUILD FAILURE
> [INFO]
>
> [INFO] Total time: 02:08 min
> [INFO] Finished at: 2023-07-29T08:35:27+02:00
> [INFO]
>
> [ERROR] Failed to execute goal
> org.moditect:moditect-maven-plugin:1.0.0.Final:add-module-info
> (add-module-infos) on project commons-math-docs: Couldn't find file
> /home/gilles/gilles/devel/java/apache/commons-math/trunk/commons-math-docs/target/commons-math-docs-4.0-SNAPSHOT.jar.
> Run this goal for the project's JAR only after the maven-jar-plugin. ->
> [Help 1]
> [...]
> {noformat}
> CP 58 worked fine.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (COMMONSSITE-166) CP 59 breaks the build
Gilles Sadowski created COMMONSSITE-166:
---
Summary: CP 59 breaks the build
Key: COMMONSSITE-166
URL: https://issues.apache.org/jira/browse/COMMONSSITE-166
Project: Apache Commons All
Issue Type: Bug
Components: Commons Parent Pom
Reporter: Gilles Sadowski
Running (default goal) in the "Commons Math" project:
{noformat}
$ mvn
[...]
[INFO] Apache Commons Math SUCCESS [ 6.032 s]
[INFO] Miscellaneous core classes . SUCCESS [ 13.118 s]
[INFO] Artificial neural networks . SUCCESS [ 6.032 s]
[INFO] Transforms . SUCCESS [ 4.970 s]
[INFO] Exception classes (Legacy) . SUCCESS [ 5.137 s]
[INFO] Miscellaneous core classes (Legacy) SUCCESS [ 13.605 s]
[INFO] Apache Commons Math (Legacy) ... SUCCESS [01:19 min]
[INFO] Apache Commons Math Documentation .. FAILURE [ 0.311 s]
[INFO] Example applications ... SKIPPED
[INFO] SOFM ... SKIPPED
[INFO] SOFM: Chinese Rings SKIPPED
[INFO] SOFM: Traveling Salesman Problem ... SKIPPED
[INFO] K-Means SKIPPED
[INFO] K-Means: Image Clustering .. SKIPPED
[INFO]
[INFO] BUILD FAILURE
[INFO]
[INFO] Total time: 02:08 min
[INFO] Finished at: 2023-07-29T08:35:27+02:00
[INFO]
[ERROR] Failed to execute goal
org.moditect:moditect-maven-plugin:1.0.0.Final:add-module-info
(add-module-infos) on project commons-math-docs: Couldn't find file
/home/gilles/gilles/devel/java/apache/commons-math/trunk/commons-math-docs/target/commons-math-docs-4.0-SNAPSHOT.jar.
Run this goal for the project's JAR only after the maven-jar-plugin. -> [Help
1]
[...]
{noformat}
CP 58 worked fine.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (LANG-1704) ImmutablePair and ImmutableTriple not actually final as documented
[
https://issues.apache.org/jira/browse/LANG-1704?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17748789#comment-17748789
]
Gilles Sadowski commented on LANG-1704:
---
{quote}[...] classes are no longer final, even though their javadocs claim that
they are.
{quote}
I agree that the change performed in commit
940b79b59c7e3b6db1d7ff64ce3350ded1481e61 (with no associated JIRA page) should
be reverted.
The constructors should be made "private".
> ImmutablePair and ImmutableTriple not actually final as documented
> --
>
> Key: LANG-1704
> URL: https://issues.apache.org/jira/browse/LANG-1704
> Project: Commons Lang
> Issue Type: Bug
> Components: lang.tuple.*
>Affects Versions: 3.13.0
>Reporter: Dan Ziemba
>Priority: Minor
>
> As of commons-lang3 3.13.0, the ImmutablePair and ImmutableTriple classes are
> no longer final, even though their javadocs claim that they are. This is a
> problem because you can now subclass those and, for example, make an
> effectively mutable object that could be passed to a method with a parameter
> of type ImmutablePair.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (STATISTICS-77) Implement Sum
[
https://issues.apache.org/jira/browse/STATISTICS-77?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17746879#comment-17746879
]
Gilles Sadowski edited comment on STATISTICS-77 at 7/25/23 9:37 AM:
{quote}Let me know your thoughts on this and other alternatives.
{quote}
IMO, we have to delineate what is the most important service these classes will
provide, before trying to cover rare use-cases.
Casual usage does not need to bother with figuring out which of {{combine}} or
{{{}safeCombine{}}} to call; if it seems that {{safeCombine}} is safer, users
will pick it even if they will call it where {{combine}} would have been fine,
thus loosing whatever efficiency was available by default.
In the context of a library, a developer may have to always call
{{safeCombine}} in methods that cannot know which implementations they receive
as input.
I repeat that if we stick with the decision made in [Numbers] for
[{{Sum}}|https://commons.apache.org/proper/commons-numbers/commons-numbers-core/javadocs/api-1.1/org/apache/commons/numbers/core/Sum.html],
the issue vanishes (IOW, we stop wondering how to implement a service which we
don't intend to provide).
was (Author: erans):
bq. Let me know your thoughts on this and other alternatives.
IMO, we have delineate what is the most important service these classes will
provide, before trying to cover rare use-cases.
Casual usage does not need to bother with figuring out which of {{combine}} or
{{safeCombine}}; if it seems that {{safeCombine}} is safer, a user will pick it
even if he will most probably call it where {{combine}} would have been fine,
thus loosing whatever efficiency was available.
In the context of a library, a developer may have to always call
{{safeCombine}} in methods that cannot know which implementations they receive
as input.
I repeat that if we stick with the decision made in [Numbers] for
[{{Sum}}|https://commons.apache.org/proper/commons-numbers/commons-numbers-core/javadocs/api-1.1/org/apache/commons/numbers/core/Sum.html],
the issue vanishes (IOW, we stop wondering how to implement a service which we
don't intend to provide).
> Implement Sum
> -
>
> Key: STATISTICS-77
> URL: https://issues.apache.org/jira/browse/STATISTICS-77
> Project: Commons Statistics
> Issue Type: Sub-task
> Components: descriptive
>Reporter: Anirudh Joshi
>Priority: Minor
> Labels: gsoc, gsoc2023
> Fix For: 1.1
>
>
> This implementation uses {{commons-numbers}}
> [Sum|https://github.com/apache/commons-numbers/blob/master/commons-numbers-core/src/main/java/org/apache/commons/numbers/core/Sum.java]
> as the underlying implementation.
> This may be further expanded to include various other Sum implementations
> like [Kahan Sum|https://en.wikipedia.org/wiki/Kahan_summation_algorithm],
> {{Neumaier Sum}} (Two sum method) etc. with the option for the users to
> choose an implementation. However, before beginning the implementation of
> various other algorithms it may be worthwhile to discuss and investigate the
> relative speed of the current Sum implementation compared to
> {{DoubleStream.sum}} through JMH benchmarks.
> When we know the different speeds, it would be more clear if the user should
> have a choice for this statistic, e.g.
> * When using {{DoubleStream.sum}} is too slow and it would be nice to have a
> simple sum variation.
> * When the sum has a lot of cancellation and {{DoubleStream.sum}} suffers
> from random walk around zero.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (STATISTICS-77) Implement Sum
[
https://issues.apache.org/jira/browse/STATISTICS-77?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17746879#comment-17746879
]
Gilles Sadowski commented on STATISTICS-77:
---
bq. Let me know your thoughts on this and other alternatives.
IMO, we have delineate what is the most important service these classes will
provide, before trying to cover rare use-cases.
Casual usage does not need to bother with figuring out which of {{combine}} or
{{safeCombine}}; if it seems that {{safeCombine}} is safer, a user will pick it
even if he will most probably call it where {{combine}} would have been fine,
thus loosing whatever efficiency was available.
In the context of a library, a developer may have to always call
{{safeCombine}} in methods that cannot know which implementations they receive
as input.
I repeat that if we stick with the decision made in [Numbers] for
[{{Sum}}|https://commons.apache.org/proper/commons-numbers/commons-numbers-core/javadocs/api-1.1/org/apache/commons/numbers/core/Sum.html],
the issue vanishes (IOW, we stop wondering how to implement a service which we
don't intend to provide).
> Implement Sum
> -
>
> Key: STATISTICS-77
> URL: https://issues.apache.org/jira/browse/STATISTICS-77
> Project: Commons Statistics
> Issue Type: Sub-task
> Components: descriptive
>Reporter: Anirudh Joshi
>Priority: Minor
> Labels: gsoc, gsoc2023
> Fix For: 1.1
>
>
> This implementation uses {{commons-numbers}}
> [Sum|https://github.com/apache/commons-numbers/blob/master/commons-numbers-core/src/main/java/org/apache/commons/numbers/core/Sum.java]
> as the underlying implementation.
> This may be further expanded to include various other Sum implementations
> like [Kahan Sum|https://en.wikipedia.org/wiki/Kahan_summation_algorithm],
> {{Neumaier Sum}} (Two sum method) etc. with the option for the users to
> choose an implementation. However, before beginning the implementation of
> various other algorithms it may be worthwhile to discuss and investigate the
> relative speed of the current Sum implementation compared to
> {{DoubleStream.sum}} through JMH benchmarks.
> When we know the different speeds, it would be more clear if the user should
> have a choice for this statistic, e.g.
> * When using {{DoubleStream.sum}} is too slow and it would be nice to have a
> simple sum variation.
> * When the sum has a lot of cancellation and {{DoubleStream.sum}} suffers
> from random walk around zero.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (STATISTICS-77) Implement Sum
[
https://issues.apache.org/jira/browse/STATISTICS-77?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17746072#comment-17746072
]
Gilles Sadowski commented on STATISTICS-77:
---
{quote}
{code}
final Sum a = Sum.create(Type.SIMPLE); // Create an instance that uses
SimpleSum implementation.
a.accept(1);
final Sum b = Sum.create(Type.KAHAN); // Create an instance that uses
CompensatedSum implementation.
b.accept(2);
{code}
{quote}
If "extensions" are only going to be provided by [Statistics] (and the
constructor being package-private prevents otherwise), then why not use the
same pattern as in [RNG] (i.e. an "enum" of all supported algorithms)? Then,
it's purely internal business to provide the best possible result for the two
instances being combined.
This might entail creating a new instance, incurring unwanted side-effects (or
unwanted lack thereof).
To avoid future complications, I'd favour the same approach as for {{Sum}} in
[Numbers]: Computation is a black-box, trying to provide the best possible
result without accuracy guarantee.
The second best option is to let the user choose the algorithm (cf. "enum") but
any combination will be applied on the first instance, using its algorithm,
even if the algorithm of the second is more accurate.
If we go this route, then the place is [Numbers], not [Statisitics]; I mean
that [Statistics] would provide the choice, *only* if the summation algorithms
are defined in [Numbers] (no copy, please, of these extremely sensitive
manipulations of floating-point numbers!). If we stand by the decision made in
[Numbers] (to not provide the flexible choice of algorithm), there is no reason
to do it here.
{quote}
{code}
// Disallowed. Throws IllegalArgumentException / UnsupportedOperationException.
final double disallow = b.combine(a).getAsDouble();
// Allowed. Updates a.sum = a.sum + b.getAsDouble()
final double allow = a.combine(b).getAsDouble();
{code}
{quote}
The public API defines a single entity: "Sum". Getting an exception from
attempting to perform a sum of two "Sum" instances does not make sense at the
user level.
> Implement Sum
> -
>
> Key: STATISTICS-77
> URL: https://issues.apache.org/jira/browse/STATISTICS-77
> Project: Commons Statistics
> Issue Type: Sub-task
> Components: descriptive
>Reporter: Anirudh Joshi
>Priority: Minor
> Labels: gsoc, gsoc2023
>
> This implementation uses {{commons-numbers}}
> [Sum|https://github.com/apache/commons-numbers/blob/master/commons-numbers-core/src/main/java/org/apache/commons/numbers/core/Sum.java]
> as the underlying implementation.
> This may be further expanded to include various other Sum implementations
> like [Kahan Sum|https://en.wikipedia.org/wiki/Kahan_summation_algorithm],
> {{Neumaier Sum}} (Two sum method) etc. with the option for the users to
> choose an implementation. However, before beginning the implementation of
> various other algorithms it may be worthwhile to discuss and investigate the
> relative speed of the current Sum implementation compared to
> {{DoubleStream.sum}} through JMH benchmarks.
> When we know the different speeds, it would be more clear if the user should
> have a choice for this statistic, e.g.
> * When using {{DoubleStream.sum}} is too slow and it would be nice to have a
> simple sum variation.
> * When the sum has a lot of cancellation and {{DoubleStream.sum}} suffers
> from random walk around zero.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (STATISTICS-77) Implement Sum
[
https://issues.apache.org/jira/browse/STATISTICS-77?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17745873#comment-17745873
]
Gilles Sadowski commented on STATISTICS-77:
---
Referring to [PR #50|https://github.com/apache/commons-statistics/pull/50].
Assuming that {{Sum}} is designed for inheritance, user code could be like:
{code}
final Sum a = Sum.create(); // Returns current implementation.
a.accept(1);
final Sum b = Sum.createAnother(); // Returns a different implementation.
b.accept(2);
final double sum = a.combine(b).getAsDouble();
{code}
Will that work?
> Implement Sum
> -
>
> Key: STATISTICS-77
> URL: https://issues.apache.org/jira/browse/STATISTICS-77
> Project: Commons Statistics
> Issue Type: Sub-task
> Components: descriptive
>Reporter: Anirudh Joshi
>Priority: Minor
> Labels: gsoc, gsoc2023
>
> This implementation uses {{commons-numbers}}
> [Sum|https://github.com/apache/commons-numbers/blob/master/commons-numbers-core/src/main/java/org/apache/commons/numbers/core/Sum.java]
> as the underlying implementation.
> This may be further expanded to include various other Sum implementations
> like [Kahan Sum|https://en.wikipedia.org/wiki/Kahan_summation_algorithm],
> {{Neumaier Sum}} (Two sum method) etc. with the option for the users to
> choose an implementation. However, before beginning the implementation of
> various other algorithms it may be worthwhile to discuss and investigate the
> relative speed of the current Sum implementation compared to
> {{DoubleStream.sum}} through JMH benchmarks.
> When we know the different speeds, it would be more clear if the user should
> have a choice for this statistic, e.g.
> * When using {{DoubleStream.sum}} is too slow and it would be nice to have a
> simple sum variation.
> * When the sum has a lot of cancellation and {{DoubleStream.sum}} suffers
> from random walk around zero.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (STATISTICS-72) Implement Min
[
https://issues.apache.org/jira/browse/STATISTICS-72?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17745215#comment-17745215
]
Gilles Sadowski commented on STATISTICS-72:
---
Do we expect any implementation other than the one defined in {{StorelessMin}}?
> Implement Min
> -
>
> Key: STATISTICS-72
> URL: https://issues.apache.org/jira/browse/STATISTICS-72
> Project: Commons Statistics
> Issue Type: Sub-task
> Components: descriptive
>Reporter: Anirudh Joshi
>Assignee: Anirudh Joshi
>Priority: Minor
> Labels: gsoc, gsoc2023
> Fix For: 1.1
>
>
> Logic to compute the minimum of all values seen so far.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (STATISTICS-77) Implement Sum
[
https://issues.apache.org/jira/browse/STATISTICS-77?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17745209#comment-17745209
]
Gilles Sadowski commented on STATISTICS-77:
---
{quote}There may be different non-storeless implementations, [...]
{quote}
You mean "storeless", don't you?
My remark was aimed at the Javadoc specifying storeless for "Sum" where a user
might wonder why it would be otherwise.
Only when the statistics cannot intrinsically be computed without storing,
should it be stated that one could run out of memory...
bq. I think supporting storing values in each statistic is not optimal.
Certainly not when it would not serve any purpose.
> Implement Sum
> -
>
> Key: STATISTICS-77
> URL: https://issues.apache.org/jira/browse/STATISTICS-77
> Project: Commons Statistics
> Issue Type: Sub-task
> Components: descriptive
>Reporter: Anirudh Joshi
>Priority: Minor
> Labels: gsoc, gsoc2023
>
> This implementation uses {{commons-numbers}}
> [Sum|https://github.com/apache/commons-numbers/blob/master/commons-numbers-core/src/main/java/org/apache/commons/numbers/core/Sum.java]
> as the underlying implementation.
> This may be further expanded to include various other Sum implementations
> like [Kahan Sum|https://en.wikipedia.org/wiki/Kahan_summation_algorithm],
> {{Neumaier Sum}} (Two sum method) etc. with the option for the users to
> choose an implementation. However, before beginning the implementation of
> various other algorithms it may be worthwhile to discuss and investigate the
> relative speed of the current Sum implementation compared to
> {{DoubleStream.sum}} through JMH benchmarks.
> When we know the different speeds, it would be more clear if the user should
> have a choice for this statistic, e.g.
> * When using {{DoubleStream.sum}} is too slow and it would be nice to have a
> simple sum variation.
> * When the sum has a lot of cancellation and {{DoubleStream.sum}} suffers
> from random walk around zero.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (STATISTICS-77) Implement Sum
[
https://issues.apache.org/jira/browse/STATISTICS-77?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17745180#comment-17745180
]
Gilles Sadowski commented on STATISTICS-77:
---
Is the purpose to possibly return different implementations?
Will there ever be a "non-storeless" one?
> Implement Sum
> -
>
> Key: STATISTICS-77
> URL: https://issues.apache.org/jira/browse/STATISTICS-77
> Project: Commons Statistics
> Issue Type: Sub-task
> Components: descriptive
>Reporter: Anirudh Joshi
>Priority: Minor
> Labels: gsoc, gsoc2023
>
> This implementation uses {{commons-numbers}}
> [Sum|https://github.com/apache/commons-numbers/blob/master/commons-numbers-core/src/main/java/org/apache/commons/numbers/core/Sum.java]
> as the underlying implementation.
> This may be further expanded to include various other Sum implementations
> like [Kahan Sum|https://en.wikipedia.org/wiki/Kahan_summation_algorithm],
> {{Neumaier Sum}} (Two sum method) etc. with the option for the users to
> choose an implementation. However, before beginning the implementation of
> various other algorithms it may be worthwhile to discuss and investigate the
> relative speed of the current Sum implementation compared to
> {{DoubleStream.sum}} through JMH benchmarks.
> When we know the different speeds, it would be more clear if the user should
> have a choice for this statistic, e.g.
> * When using {{DoubleStream.sum}} is too slow and it would be nice to have a
> simple sum variation.
> * When the sum has a lot of cancellation and {{DoubleStream.sum}} suffers
> from random walk around zero.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (STATISTICS-77) Implement Sum
[
https://issues.apache.org/jira/browse/STATISTICS-77?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17745171#comment-17745171
]
Gilles Sadowski edited comment on STATISTICS-77 at 7/20/23 5:00 PM:
* Shouldn't the constructor(s) be "private" (not just package-private)? IMO,
the Javadoc "Create a Sum instance" should be replaced with "Prevent direct
instance creation. Use the \{@link #create() factory method}."
* I wouldn't duplicate the details of the actual algorithm used: Just link to
the Javadoc in [Numbers] (it's even specified there that the algo could change,
and if that happens the [Statistics] doc will be wrong).
* I think that "combine" looses precision...
was (Author: erans):
* Shouldn't the constructor(s) be "private" (not just package-private)? IMO,
the Javadoc "Create a Sum instance" should be replaced with "Prevent direct
instance creation. Use the \{@link #create() factory method}."
* I think that "combine" looses precision...
> Implement Sum
> -
>
> Key: STATISTICS-77
> URL: https://issues.apache.org/jira/browse/STATISTICS-77
> Project: Commons Statistics
> Issue Type: Sub-task
> Components: descriptive
>Reporter: Anirudh Joshi
>Priority: Minor
> Labels: gsoc, gsoc2023
>
> This implementation uses {{commons-numbers}}
> [Sum|https://github.com/apache/commons-numbers/blob/master/commons-numbers-core/src/main/java/org/apache/commons/numbers/core/Sum.java]
> as the underlying implementation.
> This may be further expanded to include various other Sum implementations
> like [Kahan Sum|https://en.wikipedia.org/wiki/Kahan_summation_algorithm],
> {{Neumaier Sum}} (Two sum method) etc. with the option for the users to
> choose an implementation. However, before beginning the implementation of
> various other algorithms it may be worthwhile to discuss and investigate the
> relative speed of the current Sum implementation compared to
> {{DoubleStream.sum}} through JMH benchmarks.
> When we know the different speeds, it would be more clear if the user should
> have a choice for this statistic, e.g.
> * When using {{DoubleStream.sum}} is too slow and it would be nice to have a
> simple sum variation.
> * When the sum has a lot of cancellation and {{DoubleStream.sum}} suffers
> from random walk around zero.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (STATISTICS-77) Implement Sum
[
https://issues.apache.org/jira/browse/STATISTICS-77?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17745171#comment-17745171
]
Gilles Sadowski commented on STATISTICS-77:
---
* Shouldn't the constructor(s) be "private" (not just package-private)? IMO,
the Javadoc "Create a Sum instance" should be replaced with "Prevent direct
instance creation. Use the \{@link #create() factory method}."
* I think that "combine" looses precision...
> Implement Sum
> -
>
> Key: STATISTICS-77
> URL: https://issues.apache.org/jira/browse/STATISTICS-77
> Project: Commons Statistics
> Issue Type: Sub-task
> Components: descriptive
>Reporter: Anirudh Joshi
>Priority: Minor
> Labels: gsoc, gsoc2023
>
> This implementation uses {{commons-numbers}}
> [Sum|https://github.com/apache/commons-numbers/blob/master/commons-numbers-core/src/main/java/org/apache/commons/numbers/core/Sum.java]
> as the underlying implementation.
> This may be further expanded to include various other Sum implementations
> like [Kahan Sum|https://en.wikipedia.org/wiki/Kahan_summation_algorithm],
> {{Neumaier Sum}} (Two sum method) etc. with the option for the users to
> choose an implementation. However, before beginning the implementation of
> various other algorithms it may be worthwhile to discuss and investigate the
> relative speed of the current Sum implementation compared to
> {{DoubleStream.sum}} through JMH benchmarks.
> When we know the different speeds, it would be more clear if the user should
> have a choice for this statistic, e.g.
> * When using {{DoubleStream.sum}} is too slow and it would be nice to have a
> simple sum variation.
> * When the sum has a lot of cancellation and {{DoubleStream.sum}} suffers
> from random walk around zero.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MATH-1579) Create "clustering" module
[
https://issues.apache.org/jira/browse/MATH-1579?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17745121#comment-17745121
]
Gilles Sadowski commented on MATH-1579:
---
FTR, I've just posted a reply to [~dimitrios.efthymiou]'s message where he said
he was "stuck", indicating a way forward (on the dependencies issue).
Another way forward is to think about the new API design (a.o. representing
points in "problem space", and adapting the "Distance" classes to the new
representation). A crucial issue is what balance should be achieved between
robustness, flexibility and performance (current API exposes reference to the
data).
> Create "clustering" module
> --
>
> Key: MATH-1579
> URL: https://issues.apache.org/jira/browse/MATH-1579
> Project: Commons Math
> Issue Type: Sub-task
>Reporter: Gilles Sadowski
>Priority: Major
> Labels: modularization, pull-request-available, refactoring
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Move and enhance codes from the "legacy" module" that are currently in
> package {{{}o.a.c.math4.legacy.ml.clustering{}}}.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MATH-1579) Create "clustering" module
[
https://issues.apache.org/jira/browse/MATH-1579?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17744608#comment-17744608
]
Gilles Sadowski commented on MATH-1579:
---
Build fails (error issued by the "javadoc" tool).
You must execute
{noformat}
$ mvn
{noformat}
in the top-level directory of the maven project; do not commit before you get
{noformat}
[INFO] BUILD SUCCESS
{noformat}
among the last lines on the console...
[Unless you are fairly confident that the problem is not a consequence of your
own changes.]
> Create "clustering" module
> --
>
> Key: MATH-1579
> URL: https://issues.apache.org/jira/browse/MATH-1579
> Project: Commons Math
> Issue Type: Sub-task
>Reporter: Gilles Sadowski
>Priority: Major
> Labels: modularization, pull-request-available, refactoring
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Move and enhance codes from the "legacy" module" that are currently in
> package {{{}o.a.c.math4.legacy.ml.clustering{}}}.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MATH-1579) Create "clustering" module
[
https://issues.apache.org/jira/browse/MATH-1579?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17744581#comment-17744581
]
Gilles Sadowski commented on MATH-1579:
---
Build fails (you've deleted the top-level POM file).
Could you please take into consideration what I suggested about (atomically
porting the clustering functionality to) a new module?
> Create "clustering" module
> --
>
> Key: MATH-1579
> URL: https://issues.apache.org/jira/browse/MATH-1579
> Project: Commons Math
> Issue Type: Sub-task
>Reporter: Gilles Sadowski
>Priority: Major
> Labels: modularization, pull-request-available, refactoring
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Move and enhance codes from the "legacy" module" that are currently in
> package {{{}o.a.c.math4.legacy.ml.clustering{}}}.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (MATH-1577) Create "geneticalgorithm" module
[
https://issues.apache.org/jira/browse/MATH-1577?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17744511#comment-17744511
]
Gilles Sadowski edited comment on MATH-1577 at 7/19/23 9:54 AM:
Module exists only in the dedicated branch.
Work stalled because no agreement has been reached on the refactoring (see
MATH-1618 and discussions in the [ML
archive|https://markmail.org/message/2mzdbozc6nwobc37]).
was (Author: erans):
Module exists only in the dedicated branch.
Work stalled because no agreement has been reached on the refactoring (see
discussion in the [ML archive|https://markmail.org/message/2mzdbozc6nwobc37]).
> Create "geneticalgorithm" module
>
>
> Key: MATH-1577
> URL: https://issues.apache.org/jira/browse/MATH-1577
> Project: Commons Math
> Issue Type: Sub-task
>Reporter: Gilles Sadowski
>Priority: Major
> Labels: module, refactoring
>
> Move and enhance codes from "legacy" module that are currently in the
> {{o.a.c.math4.legacy.genetics}} package.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Reopened] (MATH-1577) Create "geneticalgorithm" module
[
https://issues.apache.org/jira/browse/MATH-1577?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gilles Sadowski reopened MATH-1577:
---
Module exists only in the dedicated branch.
Work stalled because no agreement has been reached on the refactoring (see
discussion in the [ML archive|https://markmail.org/message/2mzdbozc6nwobc37]).
> Create "geneticalgorithm" module
>
>
> Key: MATH-1577
> URL: https://issues.apache.org/jira/browse/MATH-1577
> Project: Commons Math
> Issue Type: Sub-task
>Reporter: Gilles Sadowski
>Priority: Major
> Labels: module, refactoring
>
> Move and enhance codes from "legacy" module that are currently in the
> {{o.a.c.math4.legacy.genetics}} package.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (MATH-1577) Create "geneticalgorithm" module
[
https://issues.apache.org/jira/browse/MATH-1577?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gilles Sadowski updated MATH-1577:
--
Description:
Move and enhance codes from "legacy" module that are currently in the
{{o.a.c.math4.legacy.genetics}} package.
was:
Move and enhance codes from "legacy" module that are currently in the
{{o.a.c.math4.legacy.genetics}} package.
See
[modularized_master|https://gitbox.apache.org/repos/asf?p=commons-math.git;a=shortlog;h=refs/heads/modularized_master]
branch.
> Create "geneticalgorithm" module
>
>
> Key: MATH-1577
> URL: https://issues.apache.org/jira/browse/MATH-1577
> Project: Commons Math
> Issue Type: Sub-task
>Reporter: Gilles Sadowski
>Priority: Major
> Labels: module, refactoring
>
> Move and enhance codes from "legacy" module that are currently in the
> {{o.a.c.math4.legacy.genetics}} package.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MATH-1579) Create "clustering" module
[
https://issues.apache.org/jira/browse/MATH-1579?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17744504#comment-17744504
]
Gilles Sadowski commented on MATH-1579:
---
bq. I managed to move only a few classes from ml.clustering [...]
And the PR build fails because those classes are now missing in "legacy".
You could fix that by adding the dependency in the POM file (as you attempted
previously) but porting to a module should be done "atomically": After the
move, a developer should be able to access *all* the functionality that was in
the "legacy" package. IOW, the entire refactoring of the
{{o.a.c.math4.legacy.ml.clustering}} package must be done before the PR can be
merged into the "master" branch. [Side note: That merged PR will eventually
contain a single (squashed) commit, because all the details of the intermediate
work are not necessary for the long-term understanding of the move (only the
before/after states are).]
bq. Wait for someone to move those classes to the appropriate modules?
It depends. If the missing functionality is easy to duplicate, you could copy
of the relevant classes and make them package-private, or store them in package
named "internal" with a prominent note that they *must* be replaced (by a
dependency on the official implementation) before merging to "master"; and from
there continue the refactoring.
As I indicated, "Variance" should be on [~ani5rudh]'s to-do list, maybe it can
be prioritized (?) to remove the road-block.
bq. Maybe move the ml.distance classes to commons-geometry?
No.
[Details on the "dev" ML, in a reply to your message with subject: "[math]
legac ml.distance package migration".]
> Create "clustering" module
> --
>
> Key: MATH-1579
> URL: https://issues.apache.org/jira/browse/MATH-1579
> Project: Commons Math
> Issue Type: Sub-task
>Reporter: Gilles Sadowski
>Priority: Major
> Labels: modularization, pull-request-available, refactoring
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Move and enhance codes from the "legacy" module" that are currently in
> package {{{}o.a.c.math4.legacy.ml.clustering{}}}.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MATH-1579) Create "clustering" module
[
https://issues.apache.org/jira/browse/MATH-1579?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17744372#comment-17744372
]
Gilles Sadowski commented on MATH-1579:
---
bq. fixed
But now "CheckStyle" fails the build. Violations must be fixed too.
> Create "clustering" module
> --
>
> Key: MATH-1579
> URL: https://issues.apache.org/jira/browse/MATH-1579
> Project: Commons Math
> Issue Type: Sub-task
>Reporter: Gilles Sadowski
>Priority: Major
> Labels: modularization, pull-request-available, refactoring
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Move and enhance codes from the "legacy" module" that are currently in
> package {{{}o.a.c.math4.legacy.ml.clustering{}}}.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MATH-1579) Create "clustering" module
[
https://issues.apache.org/jira/browse/MATH-1579?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17744310#comment-17744310
]
Gilles Sadowski commented on MATH-1579:
---
The build (just run "mvn" on the command line) fails on my local machine:
{noformat}
[INFO] Reactor Summary for Apache Commons Math 4.0-SNAPSHOT:
[INFO]
[INFO] Apache Commons Math SUCCESS [ 5.057 s]
[INFO] Miscellaneous core classes . SUCCESS [ 11.859 s]
[INFO] Artificial neural networks . SUCCESS [ 6.058 s]
[INFO] Transforms . SUCCESS [ 5.015 s]
[INFO] Exception classes (Legacy) . SUCCESS [ 5.068 s]
[INFO] Miscellaneous core classes (Legacy) SUCCESS [ 13.780 s]
[INFO] Apache Commons Math (Legacy) ... FAILURE [ 0.005 s]
[INFO] Apache Commons Math Documentation .. SKIPPED
[INFO] Example applications ... SKIPPED
[INFO] SOFM ... SKIPPED
[INFO] SOFM: Chinese Rings SKIPPED
[INFO] SOFM: Traveling Salesman Problem ... SKIPPED
[INFO] K-Means SKIPPED
[INFO] K-Means: Image Clustering .. SKIPPED
[INFO]
[INFO] BUILD FAILURE
[INFO]
[INFO] Total time: 47.153 s
[INFO] Finished at: 2023-07-18T19:44:04+02:00
[INFO]
[ERROR] Failed to execute goal on project commons-math4-legacy: Could not
resolve dependencies for project
org.apache.commons:commons-math4-legacy:jar:4.0-SNAPSHOT: Failure to find
org.apache.commons:commons-math4-clustering:jar:4.0-SNAPSHOT in
https://repository.apache.org/snapshots was cached in the local repository,
resolution will not be reattempted until the update interval of
apache.snapshots has elapsed or updates are forced -> [Help 1]
{noformat}
GH also shows it failing (but I don't see the error message).
I spotted 2 issues in the POM files:
# Like the other modules, the new module must be declared in the top-level POM.
# Why did you add a section
{noformat}
org.apache.commons
commons-math4-clustering
4.0-SNAPSHOT
compile
{noformat}
in the POM file of the "commons-math-legacy" module?
> Create "clustering" module
> --
>
> Key: MATH-1579
> URL: https://issues.apache.org/jira/browse/MATH-1579
> Project: Commons Math
> Issue Type: Sub-task
>Reporter: Gilles Sadowski
>Priority: Major
> Labels: modularization, pull-request-available, refactoring
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Move and enhance codes from the "legacy" module" that are currently in
> package {{{}o.a.c.math4.legacy.ml.clustering{}}}.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (NUMBERS-199) Method "round "in class "Precision"
[ https://issues.apache.org/jira/browse/NUMBERS-199?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17744192#comment-17744192 ] Gilles Sadowski commented on NUMBERS-199: - bq. no test cases were provided Indeed, at the time, I had been hoping for those... > Method "round "in class "Precision" > --- > > Key: NUMBERS-199 > URL: https://issues.apache.org/jira/browse/NUMBERS-199 > Project: Commons Numbers > Issue Type: Bug > Components: core >Affects Versions: 1.1 >Reporter: Gilles Sadowski >Priority: Major > Fix For: 1.2 > > > See description in original report: MATH-1470. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (NUMBERS-199) Method "round "in class "Precision"
[ https://issues.apache.org/jira/browse/NUMBERS-199?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17744170#comment-17744170 ] Gilles Sadowski commented on NUMBERS-199: - Didn't the OP imply that the fix could just be using this [constructor|https://docs.oracle.com/javase/8/docs/api/java/math/BigDecimal.html#BigDecimal-double-]? > Method "round "in class "Precision" > --- > > Key: NUMBERS-199 > URL: https://issues.apache.org/jira/browse/NUMBERS-199 > Project: Commons Numbers > Issue Type: Bug > Components: core >Affects Versions: 1.1 >Reporter: Gilles Sadowski >Priority: Major > Fix For: 1.2 > > > See description in original report: MATH-1470. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (MATH-1470) Precision.round(double...)'s use of Double.toString(x) rounds twice resulting in inaccuracy
[ https://issues.apache.org/jira/browse/MATH-1470?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gilles Sadowski resolved MATH-1470. --- Resolution: Feedback Received Issue to be solved in "Commons Numbers" (NUMBERS-199). > Precision.round(double...)'s use of Double.toString(x) rounds twice resulting > in inaccuracy > --- > > Key: MATH-1470 > URL: https://issues.apache.org/jira/browse/MATH-1470 > Project: Commons Math > Issue Type: Bug >Affects Versions: 3.6.1 >Reporter: George Smith >Priority: Major > Original Estimate: 10m > Remaining Estimate: 10m > > The use of Double.toString( x ) in the creation of the BigDecimal used by the > Precision.round(double...) methods introduces a rounding that can then > generate incorrect results when the rounding is applied to the BigDecimal. > Whenever possible rounding should only be applied to the most accurate value > available. Switching the BigDecimal construction to use the double value > directly resolves the problem. > > This problem can be seen by running the main method of the > com.altoros.floatingpoint.PrecisionProblem class in the repo hosted at: > [https://github.com/Altoros/precision-problem] > > George > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (NUMBERS-199) Method "round "in class "Precision"
Gilles Sadowski created NUMBERS-199: --- Summary: Method "round "in class "Precision" Key: NUMBERS-199 URL: https://issues.apache.org/jira/browse/NUMBERS-199 Project: Commons Numbers Issue Type: Bug Components: core Affects Versions: 1.1 Reporter: Gilles Sadowski Fix For: 1.2 See description in original report: MATH-1470. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (MATH-1470) Precision.round(double...)'s use of Double.toString(x) rounds twice resulting in inaccuracy
[
https://issues.apache.org/jira/browse/MATH-1470?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16637042#comment-16637042
]
Gilles Sadowski edited comment on MATH-1470 at 7/18/23 8:09 AM:
Hi.
Thanks for the report and analysis.
Class {{Precision}} has been [moved to the "Commons Numbers"
project|https://github.com/apache/commons-numbers/blob/master/commons-numbers-core/src/main/java/org/apache/commons/numbers/core/Precision.java],
and so won't be part of the next major release (v4.0) of "Commons Math".
Could you please file an issue in the [bug tracking system for
"Numbers"|https://issues.apache.org/jira/projects/NUMBERS/issues/], linking
that issue to this one? Thanks.
It would of course be great if you could also provide a fix in the form of
patch (or pull request) containing the necessary code changes and associated
unit test(s).
was (Author: erans):
Hi.
Thanks for the report and analysis.
Class {{Precision}} has been [moved to the "Commons Numbers"
project|https://git1-us-west.apache.org/repos/asf?p=commons-numbers.git;a=blob;f=commons-numbers-core/src/main/java/org/apache/commons/numbers/core/Precision.java;h=11fe704383e46ee421a1c0c344dd86d86a2bcdbc;hb=HEAD],
and so won't be part of the next major release (v4.0) of "Commons Math".
Could you please file an issue in the [bug tracking system for
"Numbers"|https://issues.apache.org/jira/projects/NUMBERS/issues/], linking
that issue to this one? Thanks.
It would of course be great if you could also provide a fix in the form of
patch (or pull request) containing the necessary code changes and associated
unit test(s).
> Precision.round(double...)'s use of Double.toString(x) rounds twice resulting
> in inaccuracy
> ---
>
> Key: MATH-1470
> URL: https://issues.apache.org/jira/browse/MATH-1470
> Project: Commons Math
> Issue Type: Bug
>Affects Versions: 3.6.1
>Reporter: George Smith
>Priority: Major
> Original Estimate: 10m
> Remaining Estimate: 10m
>
> The use of Double.toString( x ) in the creation of the BigDecimal used by the
> Precision.round(double...) methods introduces a rounding that can then
> generate incorrect results when the rounding is applied to the BigDecimal.
> Whenever possible rounding should only be applied to the most accurate value
> available. Switching the BigDecimal construction to use the double value
> directly resolves the problem.
>
> This problem can be seen by running the main method of the
> com.altoros.floatingpoint.PrecisionProblem class in the repo hosted at:
> [https://github.com/Altoros/precision-problem]
>
> George
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IMAGING-358) "RationalNumber" class is "public"
[
https://issues.apache.org/jira/browse/IMAGING-358?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17743888#comment-17743888
]
Gilles Sadowski commented on IMAGING-358:
-
bq. I cited concerns that the alternate approach might not work due to the
possibility of difference in implementation and rules. You asked the
reasonable question "where are the differences?" And now I will make the
reasonable observation that the onus is on you to answer that, not me.
I was suggesting team work towards a common goal. If such does not exist, then
there is no point.
bq. After all, you are the one who is proposing to replace existing code.
Before the commons-number solution could be integrated into commons-imaging,
someone would have to inspect both approaches method-by-method to verify that
the results are compatible.
Yes, but it was the result of noticing that your {{RationalNumber}}
implementation hit bugs that might not exist (or have been fixed) in [Numbers].
Of course, there is the risk that bugs still exist, but the point of
consolidation is to not hit the same bug twice. The more a code is used, the
better (in my book).
Obviously (?), it does not make sense that an app developer who needs a
"fraction" should depend on [Imaging]; so the functionality has to stand on its
own in a truly low-level library. Once there, it makes sense that other
libraries reuse it.
bq. [...] we saw recently that changing legacy code to use an alternate API can
go badly wrong.
OK. That happens.
Reinventing all the wheels also has its drawbacks.
bq. I have a point that cannot be dismissed out-of-hand.
I'm not doing that.
I repeat: I had only pointed out a very real drawback of dismissing (!) the
principle of code reuse.
[It just happens that at work, a bug has lived on for years because some
computation was deemed "so easy" that several teams would perform it (rather
than a single one who'd then share the results). Not everyone got it right...]
bq. Commons-numbers-fraction is only 25.7 K with 7 compiled classes. That's no
big deal in a modern computing environment. But, oh yeah, it depends on
commons-number-core (25,3 K, 14 compiled classes). So now my Configuration
Management team, to whom I am answerable, has to add two new Jar files to their
build.
This is irrelevant to the _principle_ of code reuse which I advocate.
Thanks to having control over all those codes, what you expose here is a
_practical problem_ which we can solve (once known): We could indeed further
modularize "Commons Numbers" so as to generate a "convenience" JAR that only
contains what you need. Alternately, as was done in the past IIRC, [Imaging]
could use "shading" in order to effectively have no dependencies, while still
reusing common code.
bq. Finally, on a less contentious topic, [...]
I don't remember if you were around at the time, but be sure that it has been
very, very contentious, with some PMC members preferring to move [Math] to the
"attic" rather than refactor it...
bq. I did want to add that the refactoring of the Math project into smaller
pieces is an excellent idea and that you guys have made an outstanding effort.
[...]
Thanks a lot; I'm glad to hear it finally (that the idea was good)! Of course,
many thanks to [~aherbert] and [~mattjuntunen] for being instrumental in the
enhanced functionality which the spun-off components now provide.
bq. So I do admire what you were able to accomplish.
Work is not done yet. You are welcome to help. Even if you insist on keeping
{{RationalNumber}} in [Imaging]. ;-)
> "RationalNumber" class is "public"
> --
>
> Key: IMAGING-358
> URL: https://issues.apache.org/jira/browse/IMAGING-358
> Project: Commons Imaging
> Issue Type: Wish
> Components: imaging.common.*
>Affects Versions: 1.0-alpha2
>Reporter: Gilles Sadowski
>Priority: Major
> Labels: API, support
> Fix For: 1.0, 1.0-alpha3
>
>
> As per its Javadoc, class
> [{{RationalNumber}}|https://commons.apache.org/proper/commons-imaging/apidocs/org/apache/commons/imaging/common/RationalNumber.html]
> is tuned to the requirements of the TIFF format while its name purports that
> it's a general implementation of the "fraction" concept.
> Which is it?
> Do we want that utility to be part of [Imaging]'s public API (thus eliciting
> support to application developers who might use it beyond its intended scope)?
> A dependency on [[Numbers]'s "fraction"
> module|https://commons.apache.org/proper/commons-numbers/commons-numbers-docs/apidocs/org/apache/commons/numbers/fraction/package-summary.html],
> as proposed in IMAGING-309) would avoid the issue, and also consolidate
> (and/or help find potential bugs in) [Numbers]'s implementation.
> If that proposal is not accepted,
[jira] [Commented] (IMAGING-358) "RationalNumber" class is "public"
[
https://issues.apache.org/jira/browse/IMAGING-358?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17743693#comment-17743693
]
Gilles Sadowski commented on IMAGING-358:
-
bq. It's been two years [...] I recall the differences between the
implementations in Commons Imaging and Commons Numbers were related to the way
the two classes treated 32-bit unsigned integers
I asked the same question at the time. The initial answer was also about some
suspected special thing about a "TIFF fraction"; it might be case, but when I
suggested to investigate, the eventual answer morphed into the unrelated "no
dependency" mantra.
bq. I think the question is a bit disingenuous.
Because we don't agree about what "bloat" is does not need to bring snark in
the conversation.
bq. Commons Imaging started with no external dependencies except the Java
standard API. If we were to add a dependency to another library, and then that
library added dependencies of its own, we would have bloat.
As stated already, this is all within "Commons"; (potential) issues related to
dependencies are under our control.
The main (only?) rationale for "Commons" components to not have _external_
dependencies was to avoid the risk of JAR hell.
"Bloat" is orthogonal to "having dependencies".
I also don't like "bloat" (in the sense of "risk brought by redundancy"); I
believe that code reuse is more important than "having no dependencies".
One kind of "bloat" is nicely illustrated by "Commons" having at least 3
components implement a "fraction" (with varying degrees of flexibility,
performance, and robustness):
* [Imaging]
* [Lang]
* [Numbers] (originally in [Math])
The purpose of a *modular* [Numbers] was to solve the bloat which [Math] had
become, here in the sense that (before the spin-off), in order to use a small,
common, functionality like "fraction", you indeed had to depend on a library
with more than 300K lines of code. With [Numbers], you get the functionality
in less than 2K lines.
> "RationalNumber" class is "public"
> --
>
> Key: IMAGING-358
> URL: https://issues.apache.org/jira/browse/IMAGING-358
> Project: Commons Imaging
> Issue Type: Wish
> Components: imaging.common.*
>Affects Versions: 1.0-alpha2
>Reporter: Gilles Sadowski
>Priority: Major
> Labels: API, support
> Fix For: 1.0, 1.0-alpha3
>
>
> As per its Javadoc, class
> [{{RationalNumber}}|https://commons.apache.org/proper/commons-imaging/apidocs/org/apache/commons/imaging/common/RationalNumber.html]
> is tuned to the requirements of the TIFF format while its name purports that
> it's a general implementation of the "fraction" concept.
> Which is it?
> Do we want that utility to be part of [Imaging]'s public API (thus eliciting
> support to application developers who might use it beyond its intended scope)?
> A dependency on [[Numbers]'s "fraction"
> module|https://commons.apache.org/proper/commons-numbers/commons-numbers-docs/apidocs/org/apache/commons/numbers/fraction/package-summary.html],
> as proposed in IMAGING-309) would avoid the issue, and also consolidate
> (and/or help find potential bugs in) [Numbers]'s implementation.
> If that proposal is not accepted, {{RationalNumber}} should preferably be
> moved to [Imaging]'s [{{internal}}
> package|https://commons.apache.org/proper/commons-imaging/apidocs/org/apache/commons/imaging/internal/package-summary.html].
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (GEOMETRY-154) Implement divideVectorWithRatio(Vector x, double ratio)
[ https://issues.apache.org/jira/browse/GEOMETRY-154?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17743582#comment-17743582 ] Gilles Sadowski commented on GEOMETRY-154: -- bq. One thing i would love to do is [...] Please post to the ML. > Implement divideVectorWithRatio(Vector x, double ratio) > --- > > Key: GEOMETRY-154 > URL: https://issues.apache.org/jira/browse/GEOMETRY-154 > Project: Commons Geometry > Issue Type: New Feature > Components: euclidean1D, euclidean2D, euclidean3D >Reporter: Dimitrios Efthymiou >Priority: Minor > Labels: features > Original Estimate: 3h > Remaining Estimate: 3h > > It takes a vector, say, u = (10) and divides it with ratio, say 1/2. That > will return a pair of vectors v = (3.33) and w = (6.66). Regardless of > dimensions, both vectors start at the point of origin -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IMAGING-358) "RationalNumber" class is "public"
[
https://issues.apache.org/jira/browse/IMAGING-358?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17743564#comment-17743564
]
Gilles Sadowski commented on IMAGING-358:
-
bq. [...] the rational number format used by TIFF just wasn't a perfect fit
with that used in the math library. Some of the rules were a little different.
That sounds a bit strange. Is it a fraction, or not? Is there something wrong
in how the class in [Numbers] implements a fraction?
bq. the rules were defined as part of the TIFF format specification, [...]
Which rules? Certainly not those that define what a fraction is.
Perhaps a specialized behaviour on top of a (plain) fraction is required in
order to support the TIFF format, then why not focus on that, instead of taking
advantage of the work done in [Math] and then in [Numbers] (where bugs were
fixed and performance improved)?
bq. Adding unnecessary libraries adds bloat.
TIFF needs fraction, "commons-numbers-fraction" provides a JAR that only
contains classes about fractions. Where is the bloat?
> "RationalNumber" class is "public"
> --
>
> Key: IMAGING-358
> URL: https://issues.apache.org/jira/browse/IMAGING-358
> Project: Commons Imaging
> Issue Type: Wish
> Components: imaging.common.*
>Affects Versions: 1.0-alpha2
>Reporter: Gilles Sadowski
>Priority: Major
> Labels: API, support
> Fix For: 1.0, 1.0-alpha3
>
>
> As per its Javadoc, class
> [{{RationalNumber}}|https://commons.apache.org/proper/commons-imaging/apidocs/org/apache/commons/imaging/common/RationalNumber.html]
> is tuned to the requirements of the TIFF format while its name purports that
> it's a general implementation of the "fraction" concept.
> Which is it?
> Do we want that utility to be part of [Imaging]'s public API (thus eliciting
> support to application developers who might use it beyond its intended scope)?
> A dependency on [[Numbers]'s "fraction"
> module|https://commons.apache.org/proper/commons-numbers/commons-numbers-docs/apidocs/org/apache/commons/numbers/fraction/package-summary.html],
> as proposed in IMAGING-309) would avoid the issue, and also consolidate
> (and/or help find potential bugs in) [Numbers]'s implementation.
> If that proposal is not accepted, {{RationalNumber}} should preferably be
> moved to [Imaging]'s [{{internal}}
> package|https://commons.apache.org/proper/commons-imaging/apidocs/org/apache/commons/imaging/internal/package-summary.html].
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (GEOMETRY-154) Implement divideVectorWithRatio(Vector x, double ratio)
[ https://issues.apache.org/jira/browse/GEOMETRY-154?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17743536#comment-17743536 ] Gilles Sadowski commented on GEOMETRY-154: -- IIUC, this says that there are at least 2 ways a user might want to access this functionality: In your example, * one call would pass the ratio as 1/2 * the other would pass the ratio as 1/3 Not knowing which is more "standard", I'd (a priori) conclude that the API should serve both needs while minimizing the risk of confusion. IMHO, the current name of the method does not pass that test. And also, it's an "isolated" method: You should either tell where it fits in the code base, or suggest a new class/package (i.e. a place where other similar utilities could be used together for some purpose). Note that I'm not precluding other's opinion on whether it should be included at all... If there are no strong opinions in favour or against, the balance might be tilted by your finding a use-case (e.g. an example of use could perhaps be added to the [tutorial|https://commons.apache.org/proper/commons-geometry/tutorials/teapot.html] created by [~mattjuntunen]). > Implement divideVectorWithRatio(Vector x, double ratio) > --- > > Key: GEOMETRY-154 > URL: https://issues.apache.org/jira/browse/GEOMETRY-154 > Project: Commons Geometry > Issue Type: New Feature > Components: euclidean1D, euclidean2D, euclidean3D >Reporter: Dimitrios Efthymiou >Priority: Minor > Labels: features > Original Estimate: 3h > Remaining Estimate: 3h > > It takes a vector, say, u = (10) and divides it with ratio, say 1/2. That > will return a pair of vectors v = (3.33) and w = (6.66). Regardless of > dimensions, both vectors start at the point of origin -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IMAGING-358) "RationalNumber" class is "public"
[
https://issues.apache.org/jira/browse/IMAGING-358?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gilles Sadowski updated IMAGING-358:
Summary: "RationalNumber" class is "public" (was: "RationalNumer" class is
"public")
> "RationalNumber" class is "public"
> --
>
> Key: IMAGING-358
> URL: https://issues.apache.org/jira/browse/IMAGING-358
> Project: Commons Imaging
> Issue Type: Wish
> Components: imaging.common.*
>Affects Versions: 1.0-alpha2
>Reporter: Gilles Sadowski
>Priority: Major
> Labels: API, support
> Fix For: 1.0, 1.0-alpha3
>
>
> As per its Javadoc, class
> [{{RationalNumber}}|https://commons.apache.org/proper/commons-imaging/apidocs/org/apache/commons/imaging/common/RationalNumber.html]
> is tuned to the requirements of the TIFF format while its name purports that
> it's a general implementation of the "fraction" concept.
> Which is it?
> Do we want that utility to be part of [Imaging]'s public API (thus eliciting
> support to application developers who might use it beyond its intended scope)?
> A dependency on [[Numbers]'s "fraction"
> module|https://commons.apache.org/proper/commons-numbers/commons-numbers-docs/apidocs/org/apache/commons/numbers/fraction/package-summary.html],
> as proposed in IMAGING-309) would avoid the issue, and also consolidate
> (and/or help find potential bugs in) [Numbers]'s implementation.
> If that proposal is not accepted, {{RationalNumber}} should preferably be
> moved to [Imaging]'s [{{internal}}
> package|https://commons.apache.org/proper/commons-imaging/apidocs/org/apache/commons/imaging/internal/package-summary.html].
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IMAGING-358) "RationalNumer" class is "public"
Gilles Sadowski created IMAGING-358:
---
Summary: "RationalNumer" class is "public"
Key: IMAGING-358
URL: https://issues.apache.org/jira/browse/IMAGING-358
Project: Commons Imaging
Issue Type: Wish
Components: imaging.common.*
Affects Versions: 1.0-alpha2
Reporter: Gilles Sadowski
Fix For: 1.0, 1.0-alpha3
As per its Javadoc, class
[{{RationalNumber}}|https://commons.apache.org/proper/commons-imaging/apidocs/org/apache/commons/imaging/common/RationalNumber.html]
is tuned to the requirements of the TIFF format while its name purports that
it's a general implementation of the "fraction" concept.
Which is it?
Do we want that utility to be part of [Imaging]'s public API (thus eliciting
support to application developers who might use it beyond its intended scope)?
A dependency on [[Numbers]'s "fraction"
module|https://commons.apache.org/proper/commons-numbers/commons-numbers-docs/apidocs/org/apache/commons/numbers/fraction/package-summary.html],
as proposed in IMAGING-309) would avoid the issue, and also consolidate
(and/or help find potential bugs in) [Numbers]'s implementation.
If that proposal is not accepted, {{RationalNumber}} should preferably be moved
to [Imaging]'s [{{internal}}
package|https://commons.apache.org/proper/commons-imaging/apidocs/org/apache/commons/imaging/internal/package-summary.html].
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (GEOMETRY-154) Implement divideVectorWithRatio(Vector x, double ratio)
[ https://issues.apache.org/jira/browse/GEOMETRY-154?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17743517#comment-17743517 ] Gilles Sadowski commented on GEOMETRY-154: -- [~dimitrios.efthymiou], Is this [tutorial|https://www.youtube.com/watch?v=Sc7UMc-CQjQ] showing a (more general) variant of the proposed function? > Implement divideVectorWithRatio(Vector x, double ratio) > --- > > Key: GEOMETRY-154 > URL: https://issues.apache.org/jira/browse/GEOMETRY-154 > Project: Commons Geometry > Issue Type: New Feature > Components: euclidean1D, euclidean2D, euclidean3D >Reporter: Dimitrios Efthymiou >Priority: Minor > Labels: features > Original Estimate: 3h > Remaining Estimate: 3h > > It takes a vector, say, u = (10) and divides it with ratio, say 1/2. That > will return a pair of vectors v = (3.33) and w = (6.66). Regardless of > dimensions, both vectors start at the point of origin -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IMAGING-309) Depend on "Commons Numbers"
[
https://issues.apache.org/jira/browse/IMAGING-309?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17743477#comment-17743477
]
Gilles Sadowski commented on IMAGING-309:
-
bq. there is not even a single example
That's just false.
It refers to another ticket whose comments discuss two bugs in [Imaging]'s
implementation of the "fraction" concept.
Having two components implementing the same concept makes no sense. The only
argument mentioned there was "zero dependencies" (which is purely dogmatic
since we control the dependency, and by convention, no release will ever open
up JAR hell).
> Depend on "Commons Numbers"
> ---
>
> Key: IMAGING-309
> URL: https://issues.apache.org/jira/browse/IMAGING-309
> Project: Commons Imaging
> Issue Type: Wish
> Components: imaging.common.*
>Reporter: Gilles Sadowski
>Priority: Trivial
> Labels: dependencies, maintainability, robustness
> Fix For: 1.0
>
>
> It would make sense for high-level components such as [Imaging] to depend on
> lower level utilities developed within "Commons", such as [Numbers], where
> # changes in dependencies can be controlled by the same team, and
> # JAR hell is _not_ an issue (as per the project's policy on BC).
> Both [Imaging] and [Numbers] would benefit from such an ecosystem:
> * The low-level component is put to test in an actual use-case.
> * The high-level component does not need to maintain lower-level utilities.
> Motivation: IMAGING-285
> At the time, it might not have made sense to depend on a component like
> Commons Math (with its ever expanding code base) just for its {{Fraction}}
> class. Nowadays however, "Commons Numbers" provides the functionality in a
> dedicated [maven
> module|https://mvnrepository.com/artifact/org.apache.commons/commons-numbers-fraction/1.0].
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (STATISTICS-72) Implement Min
[ https://issues.apache.org/jira/browse/STATISTICS-72?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gilles Sadowski reassigned STATISTICS-72: - Assignee: Anirudh Joshi > Implement Min > - > > Key: STATISTICS-72 > URL: https://issues.apache.org/jira/browse/STATISTICS-72 > Project: Commons Statistics > Issue Type: Sub-task > Components: descriptive >Reporter: Anirudh Joshi >Assignee: Anirudh Joshi >Priority: Minor > Labels: gsoc, gsoc2023 > > Logic to compute the minimum of all values seen so far. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (STATISTICS-71) Implementation of Univariate Statistics
[
https://issues.apache.org/jira/browse/STATISTICS-71?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gilles Sadowski reassigned STATISTICS-71:
-
Assignee: Anirudh Joshi
> Implementation of Univariate Statistics
> ---
>
> Key: STATISTICS-71
> URL: https://issues.apache.org/jira/browse/STATISTICS-71
> Project: Commons Statistics
> Issue Type: Task
> Components: descriptive
>Reporter: Anirudh Joshi
>Assignee: Anirudh Joshi
>Priority: Minor
> Labels: gsoc, gsoc2023
>
> Jira ticket to track the implementation of the Univariate statistics required
> for the updated SummaryStatistics API.
> The implementation would be "storeless". It should be used for calculating
> statistics that can be computed in one pass through the data without storing
> the sample values.
> Currently I have the definition of API as (this might evolve as I continue
> working)
> {code:java}
> public interface DoubleStorelessUnivariateStatistic extends DoubleSupplier {
> DoubleStorelessUnivariateStatistic add(double v);
> long getCount();
> void combine(DoubleStorelessUnivariateStatistic other);
> } {code}
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IMAGING-309) Depend on "Commons Numbers"
[
https://issues.apache.org/jira/browse/IMAGING-309?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17743458#comment-17743458
]
Gilles Sadowski commented on IMAGING-309:
-
bq. Why would Commons Imaging depend on Commons Numbers?
Rationale is in the description.
> Depend on "Commons Numbers"
> ---
>
> Key: IMAGING-309
> URL: https://issues.apache.org/jira/browse/IMAGING-309
> Project: Commons Imaging
> Issue Type: Wish
> Components: imaging.common.*
>Reporter: Gilles Sadowski
>Priority: Trivial
> Labels: dependencies, maintainability, robustness
> Fix For: 1.0
>
>
> It would make sense for high-level components such as [Imaging] to depend on
> lower level utilities developed within "Commons", such as [Numbers], where
> # changes in dependencies can be controlled by the same team, and
> # JAR hell is _not_ an issue (as per the project's policy on BC).
> Both [Imaging] and [Numbers] would benefit from such an ecosystem:
> * The low-level component is put to test in an actual use-case.
> * The high-level component does not need to maintain lower-level utilities.
> Motivation: IMAGING-285
> At a time, it might not have made sense to depend on a component like Commons
> Math (with its ever expanding code base) just for its {{Fraction}} class.
> Nowadays however, "Commons Numbers" provides the functionality in a dedicated
> [maven
> module|https://mvnrepository.com/artifact/org.apache.commons/commons-numbers-fraction/1.0].
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IMAGING-309) Depend on "Commons Numbers"
[
https://issues.apache.org/jira/browse/IMAGING-309?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gilles Sadowski updated IMAGING-309:
Description:
It would make sense for high-level components such as [Imaging] to depend on
lower level utilities developed within "Commons", such as [Numbers], where
# changes in dependencies can be controlled by the same team, and
# JAR hell is _not_ an issue (as per the project's policy on BC).
Both [Imaging] and [Numbers] would benefit from such an ecosystem:
* The low-level component is put to test in an actual use-case.
* The high-level component does not need to maintain lower-level utilities.
Motivation: IMAGING-285
At the time, it might not have made sense to depend on a component like Commons
Math (with its ever expanding code base) just for its {{Fraction}} class.
Nowadays however, "Commons Numbers" provides the functionality in a dedicated
[maven
module|https://mvnrepository.com/artifact/org.apache.commons/commons-numbers-fraction/1.0].
was:
It would make sense for high-level components such as [Imaging] to depend on
lower level utilities developed within "Commons", such as [Numbers], where
# changes in dependencies can be controlled by the same team, and
# JAR hell is _not_ an issue (as per the project's policy on BC).
Both [Imaging] and [Numbers] would benefit from such an ecosystem:
* The low-level component is put to test in an actual use-case.
* The high-level component does not need to maintain lower-level utilities.
Motivation: IMAGING-285
At a time, it might not have made sense to depend on a component like Commons
Math (with its ever expanding code base) just for its {{Fraction}} class.
Nowadays however, "Commons Numbers" provides the functionality in a dedicated
[maven
module|https://mvnrepository.com/artifact/org.apache.commons/commons-numbers-fraction/1.0].
> Depend on "Commons Numbers"
> ---
>
> Key: IMAGING-309
> URL: https://issues.apache.org/jira/browse/IMAGING-309
> Project: Commons Imaging
> Issue Type: Wish
> Components: imaging.common.*
>Reporter: Gilles Sadowski
>Priority: Trivial
> Labels: dependencies, maintainability, robustness
> Fix For: 1.0
>
>
> It would make sense for high-level components such as [Imaging] to depend on
> lower level utilities developed within "Commons", such as [Numbers], where
> # changes in dependencies can be controlled by the same team, and
> # JAR hell is _not_ an issue (as per the project's policy on BC).
> Both [Imaging] and [Numbers] would benefit from such an ecosystem:
> * The low-level component is put to test in an actual use-case.
> * The high-level component does not need to maintain lower-level utilities.
> Motivation: IMAGING-285
> At the time, it might not have made sense to depend on a component like
> Commons Math (with its ever expanding code base) just for its {{Fraction}}
> class. Nowadays however, "Commons Numbers" provides the functionality in a
> dedicated [maven
> module|https://mvnrepository.com/artifact/org.apache.commons/commons-numbers-fraction/1.0].
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (GEOMETRY-160) Implement getIndicesOfOccurenceOfElement(Vector x, double element)
[ https://issues.apache.org/jira/browse/GEOMETRY-160?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17743457#comment-17743457 ] Gilles Sadowski commented on GEOMETRY-160: -- Let's discuss "clustering" on the ML, or in one of the relevant JIRA tickets. > Implement getIndicesOfOccurenceOfElement(Vector x, double element) > -- > > Key: GEOMETRY-160 > URL: https://issues.apache.org/jira/browse/GEOMETRY-160 > Project: Commons Geometry > Issue Type: New Feature > Components: euclidean1D, euclidean2D, euclidean3D >Reporter: Dimitrios Efthymiou >Priority: Minor > Labels: features > Original Estimate: 5h > Remaining Estimate: 5h > > If we have a vector u = (2, 1, 3, 1, 7) and a number, say, 1 then it returns > a list of the indices 1 and 3 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (GEOMETRY-160) Implement getIndicesOfOccurenceOfElement(Vector x, double element)
[ https://issues.apache.org/jira/browse/GEOMETRY-160?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17743436#comment-17743436 ] Gilles Sadowski commented on GEOMETRY-160: -- bq. What do you mean by "cleanup"? I mean that the tickets that are shows as "OPEN", but they have actually been completed and merged, should be marked as "COMPLETED" When you spot this, please add a comment to that effect and someone will indeed mark it as "resolved". Thanks. Note: When work has been done, a comment will usually refer to the corresponding commit identifier, and we leave the ticket open to let a potential reviewer confirm that the issue has been fixed. Then, if no external review is eventually performed, it's easy to forget to actually mark it as resolved. bq. when people work on a ticket, the ticket says "unassigned" and when I search for available tickets they appear there on the list when they should not. It often happens that a ticket is filed for traceability, but the "reporter" intends to work on it. Given the very low number of developers, it's unlikely that someone else would beat him to it. If in doubt, one can always ask on the "dev" ML (or in a comment!). bq. clustering package. Yes. Is there a ticket about it that explains what it is suposed to happen for it exactly? You could start by browsing the tickets turned up by a [search on JIRA|https://issues.apache.org/jira/issues/?jql=project%20%3D%20MATH%20AND%20status%20in%20(Open%2C%20%22In%20Progress%22%2C%20Reopened)%20AND%20text%20~%20%22clustering%22]. > Implement getIndicesOfOccurenceOfElement(Vector x, double element) > -- > > Key: GEOMETRY-160 > URL: https://issues.apache.org/jira/browse/GEOMETRY-160 > Project: Commons Geometry > Issue Type: New Feature > Components: euclidean1D, euclidean2D, euclidean3D >Reporter: Dimitrios Efthymiou >Priority: Minor > Labels: features > Original Estimate: 5h > Remaining Estimate: 5h > > If we have a vector u = (2, 1, 3, 1, 7) and a number, say, 1 then it returns > a list of the indices 1 and 3 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (GEOMETRY-160) Implement getIndicesOfOccurenceOfElement(Vector x, double element)
[ https://issues.apache.org/jira/browse/GEOMETRY-160?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17743429#comment-17743429 ] Gilles Sadowski commented on GEOMETRY-160: -- bq. every ticket in commons is unassigned Is there an implicit meaning to that statement? bq. Maybe someone should do a thorough cleanup What do you mean by "cleanup"? As said multiple times, you are welcome to take on any issue reported on JIRA. Did I mention creating a module out of CM's "clustering" package? ;-) > Implement getIndicesOfOccurenceOfElement(Vector x, double element) > -- > > Key: GEOMETRY-160 > URL: https://issues.apache.org/jira/browse/GEOMETRY-160 > Project: Commons Geometry > Issue Type: New Feature > Components: euclidean1D, euclidean2D, euclidean3D >Reporter: Dimitrios Efthymiou >Priority: Minor > Labels: features > Original Estimate: 5h > Remaining Estimate: 5h > > If we have a vector u = (2, 1, 3, 1, 7) and a number, say, 1 then it returns > a list of the indices 1 and 3 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (GEOMETRY-160) Implement getIndicesOfOccurenceOfElement(Vector x, double element)
[
https://issues.apache.org/jira/browse/GEOMETRY-160?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17743425#comment-17743425
]
Gilles Sadowski commented on GEOMETRY-160:
--
{quote}[...] if you can't state a use case for adding code, then it does not
belong.
{quote}
To be more precise, a "personal use" case is not a necessary condition; two
others ways have been mentioned:
# a reference to a scientific paper (or Wikipedia) describing the algorithm
# a reference to a library that provides the functionality
{quote}Why is the method Vectors::normSq even necessary when you can just do
x*x - which was the argument someone gave me for another convenience method I
suggested 1/2 days ago?
{quote}
Cf. point (1): [https://en.wikipedia.org/wiki/Euclidean_distance]
Also, Matt and I have explained that this code is in an {{internal}} package
(by convention, it is excluded from the user API). Admittedly the code is
trivial, but is probably there for the sake of consistency and completeness wrt
the 2D and 3D cases that are less trivial.
{quote}[...] dedicated class that handles that math aspect. Why don't we do the
same for commons-geometry?
{quote}
Don't we? Where?
{quote}I don't know when you would need to know the indices of occurence of an
element. But since it is calculable, there must be a reason or two, right?
{quote}
I've already answered this in an earlier comment.
{quote}I am guessing you are talking about only widely used libraries for Java
or Python libraries, etc. right?
{quote}
Yes.
{quote}What should the Jira ticket say in that case? "Check if a point is on
the vector – Matlab and NumPy does it".
{quote}
Yes.
But don't take this as an argument to extract a single method out of those
libraries and make a PR out of it! It it fits into an existing class, fine.
However, if it is part of a larger functionality, then additional conditions
would probably apply:
# that functionality should also be within the scope of the component/module,
and
# enough code should be ported so as to provide an actually useful equivalent
of what exists in the other library.
{quote}I used ChatGPT to generate the use-cases
{quote}
A "use case" (AFAIK) is something concrete: "If feature were implemented, I
could do ." I'd say that should be somewhat higher-level than
(otherwise, we'd just state the obvious: "With , I can do ").
{quote}I just implemented math algorithms.
{quote}
With reference or use-case?
> Implement getIndicesOfOccurenceOfElement(Vector x, double element)
> --
>
> Key: GEOMETRY-160
> URL: https://issues.apache.org/jira/browse/GEOMETRY-160
> Project: Commons Geometry
> Issue Type: New Feature
> Components: euclidean1D, euclidean2D, euclidean3D
>Reporter: Dimitrios Efthymiou
>Priority: Minor
> Labels: features
> Original Estimate: 5h
> Remaining Estimate: 5h
>
> If we have a vector u = (2, 1, 3, 1, 7) and a number, say, 1 then it returns
> a list of the indices 1 and 3
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
