Re: (commons-geometry) branch master updated: GEOMETRY-110: add ConvexHull3D using Quickhull algorithm
Hi. Although the list of successive changes might have been meaningful in separate commits, it seems like noise in a single one (e.g. many of them signal a change wrt to some previous state whose trace has been lost). Obviously, repeating "GEOMETRY-110" serves no purpose. If possible (?), it would be neat to amend the log to just keep the first line. Regards, Gilles Le dim. 28 avr. 2024 à 02:14, a écrit : > > This is an automated email from the ASF dual-hosted git repository. > > mattjuntunen pushed a commit to branch master > in repository https://gitbox.apache.org/repos/asf/commons-geometry.git > > > The following commit(s) were added to refs/heads/master by this push: > new 2f4e86b7 GEOMETRY-110: add ConvexHull3D using Quickhull algorithm > 2f4e86b7 is described below > > commit 2f4e86b792693d4c2c0e5fb2c4f198541e1fecb6 > Author: Andreas Goß <75903169+agos...@users.noreply.github.com> > AuthorDate: Sun Apr 28 02:14:00 2024 +0200 > > GEOMETRY-110: add ConvexHull3D using Quickhull algorithm > > * GEOMETRY-110 > > Add ConvexHull3D class and tests. > > * GEOMETRY-110 > > Return only an unmodifiable collection of facets. > > * GEOMETRY-110 > > Test for a large number of points. > > * Checkstyle Fix. > > * GEOMETRY-110 > > Points are added to candidates again instead of a new point set. > > * GEOMETRY-110 > > Only candidates points are distributed. > > * GEOMETRY-110 > > Add Simplex type > > * GEOMETRY-110 > > Create simplex while appending and cache it for later. > > * GEOMETRY-110 > > Build simplex incrementially while appending points. > > * GEOMETRY-110 > > Return facets as list and filter out duplicates in vertices. > > * GEOMETRY-110 > > Returned collections have to be unmodifiable in public methods. > > * GEOMETRY-110 > > Rename method and calculate maximum in a loop. > > * GEOMETRY-110 > > Declare variable outside of loop. > > * GEOMETRY-110 > > Rename methods. > > * GEOMETRY-110 > > Replace bounds by array. > > * GEOMETRY-110 > > Add check for appending a collection of points > > * [GEOMETRY-110] > > Delete hasOusidePoints and add exclusion for facets to spotbugs. > > * [GEOMETRY-110] > > Move isInside method into Facet class and reverse and rename it to > isOutside > > * [GEOMETRY-110] > > Replace vertexToFacetMap with edgeMap > > * [Geometry-110] > > Change loop for creating edges. > > * [GEOMETRY-110] > > Facets are all located through edge operations. The edges are oriented in > such a way, that neighbors share an edge in inverse orientation. > > * [GEOMETRY-110] > > Delete unnecessary debug code. > > * [GEOMETRY-110] > > Edges are oriented and lookup is done via an edgeMap. Each oriented edge > is unique in association with a facet. Each facet stores the maximum offset > and the associated point of outside points. > > * [GEOMETRY-110] > > - Rename Edge fields. > - Improve testing and assert all outputs of the algorithm. > > * [GEOMETRY-110] > > Check isDegenerate for all non-degenerate hulls. > > * [GEOMETRY-110] > > Even though the defined region is the same the number of facets can vary > depending on the execution order of the algorithm. > > - > > Co-authored-by: agoß > Co-authored-by: Andreas Goss > --- > .../euclidean/threed/hull/ConvexHull3D.java| 728 > + > .../euclidean/threed/hull/package-info.java| 25 + > .../euclidean/threed/hull/ConvexHull3DTest.java| 276 > .../resources/spotbugs/spotbugs-exclude-filter.xml | 5 + > 4 files changed, 1034 insertions(+) > > [...] - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: (commons-parent) branch master updated: Facilitate JMH benchmarking from the Maven CLI
Hi.
Le sam. 20 avr. 2024 à 17:50, Gary Gregory a écrit :
>
> Hello,
>
> I looked at Commons Lang, Commons IO, Commons CSV, Commons BCEL, Commons
> Crypto, and Commons Text. All of the above do the same duplicate work.
For sure, it's an improvement to make duplicate configurations obsolete.
However, shouldn't we go a step further in harmonizing the repositories'
structure in terms of functionality?
For example, we could have a component ("internal" to Commons" dedicated
to benchmarking boiler-plate code (similar to, or within, the "Testing" project
which you had proposed some time ago).
As noted, IMHO a Maven module dedicated to benchmarking is preferable to
"mixing" with unit tests (e.g. only that module would then depend on the
benchmarking utilities).
Regards,
Gilles
>
> Gary
>
> On Sat, Apr 20, 2024, 11:01 AM Gilles Sadowski wrote:
>
> > Hi.
> >
> > This commit caught my attention but I've not looked in detail (sorry!).
> > I'm wondering whether this addition deserves a discussion here on "dev"
> > to reach consensus on how to handle benchmarking code in a uniform
> > way across all components.
> > For a long time, some components (namely and mainly "Commons
> > RNG") have been providing[1] extensive JMH codes (in dedicated
> > maven modules) in order to generate benchmark reports.
> > This addition seems (?) to duplicate the functionality, under different
> > assumptions on how to trigger it.
> > Did you look at how the benchmarking functionality is laid out in [RNG]?
> > Can't it be generalized to other components, with or without formal
> > support in the "main" POM file? [At first sight, it would seem tidier,
> > more
> > flexible and more maintainable, to *not* bundle benchmark codes within
> > "src/test" (where true unit tests reside)...]
> >
> > Gilles
> >
> > [1] Thanks to Alex.
> >
> > Le sam. 20 avr. 2024 à 16:30, a écrit :
> > >
> > > [...]
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
Re: (commons-parent) branch master updated: Facilitate JMH benchmarking from the Maven CLI
Hi.
This commit caught my attention but I've not looked in detail (sorry!).
I'm wondering whether this addition deserves a discussion here on "dev"
to reach consensus on how to handle benchmarking code in a uniform
way across all components.
For a long time, some components (namely and mainly "Commons
RNG") have been providing[1] extensive JMH codes (in dedicated
maven modules) in order to generate benchmark reports.
This addition seems (?) to duplicate the functionality, under different
assumptions on how to trigger it.
Did you look at how the benchmarking functionality is laid out in [RNG]?
Can't it be generalized to other components, with or without formal
support in the "main" POM file? [At first sight, it would seem tidier, more
flexible and more maintainable, to *not* bundle benchmark codes within
"src/test" (where true unit tests reside)...]
Gilles
[1] Thanks to Alex.
Le sam. 20 avr. 2024 à 16:30, a écrit :
>
> This is an automated email from the ASF dual-hosted git repository.
>
> ggregory pushed a commit to branch master
> in repository https://gitbox.apache.org/repos/asf/commons-parent.git
>
>
> The following commit(s) were added to refs/heads/master by this push:
> new 9637b97 Facilitate JMH benchmarking from the Maven CLI
> 9637b97 is described below
>
> commit 9637b97c371906c90d958b2b7869a47818ad2e0b
> Author: Gary Gregory
> AuthorDate: Sat Apr 20 10:28:56 2024 -0400
>
> Facilitate JMH benchmarking from the Maven CLI
>
> - Add profile benchmark for JMH benchmarks
> - Add JMH to dependency management section
> ---
> pom.xml | 46 +-
> src/changes/changes.xml | 3 +++
> 2 files changed, 44 insertions(+), 5 deletions(-)
>
> diff --git a/pom.xml b/pom.xml
> index abfe20e..dbb3698 100644
> --- a/pom.xml
> +++ b/pom.xml
> @@ -167,7 +167,7 @@
>
>
> 6.4.1
> 5.10.2
> -
> +1.37
>
>java-11-up
> @@ -1856,7 +1855,6 @@
> 10.15.0
>
>
> -
>
>
>java-17-up
> @@ -1870,7 +1868,45 @@
> -->
>
>
> -
> +
> +
> + benchmark
> +
> +true
> +org.apache
> +
> +
> +
> +
> +org.codehaus.mojo
> +exec-maven-plugin
> +3.2.0
> +
> +
> +benchmark
> +test
> +
> + exec
> +
> +
> + test
> + java
> +
> +-classpath
> +
> +org.openjdk.jmh.Main
> +-rf
> +json
> +-rff
> +target/jmh-result.${benchmark}.json
> +${benchmark}
> +
> +
> +
> +
> +
> +
> +
> +
>
> -
>
> diff --git a/src/changes/changes.xml b/src/changes/changes.xml
> index a62cb49..0937e3b 100644
> --- a/src/changes/changes.xml
> +++ b/src/changes/changes.xml
> @@ -58,6 +58,9 @@ The type attribute can be add,update,fix,remove.
> -->
>
>
> +
> + Add
> profile benchmark for JMH benchmarks.
> + Add JMH
> to dependency management section.
>
> Set
> Javadoc link to latest Java API LTS version.
>
>
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
Re: Is there a blog for commons?
Le ven. 19 avr. 2024 à 13:05, Gary Gregory a écrit : > > I think there are three places today this type of information can live > within Apache: > > - the component website (which we can publish whenever we want) > - the project wiki (which automatically is live) > - https://news.apache.org/ (not sure how one posts there) I beg to differ. >From what I understand, this would be much more useful in a documentation section of the component (as a practical way to learn how to use non-trivial functionality implemented there). [If the primary purpose is personal advertisement, there is no real point discussing it on the Commons "dev" ML.] Regards, Gilles > > [...] - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: Is there a blog for commons?
Le mar. 16 avr. 2024 à 13:09, Gary Gregory a écrit : > > There is an Apache wide blog here: > https://news.apache.org/ > > We have a wiki here: > https://cwiki.apache.org/confluence/display/COMMONS/FrontPage Most links lead to pages that are badly out-of-date: --- last modified on Sep 20, 2009 --- >>> [...] - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: Is there a blog for commons?
Hi. Le mar. 16 avr. 2024 à 12:45, Bruno Kinoshita a écrit : > > I do not remember ever reading a blog post from Commons. The other ASF > projects where I am active (opennlp/jena) also do not have one. Arrow has > one that seems to be used [1], but I am not sure if others would adopt it. > I would be keen to write something about Imaging if we had a blog post. How about "userguide" or "tutorial" sections, like e.g. in "Commons Geometry"[1][2]? Regards, Gilles [1] https://commons.apache.org/proper/commons-geometry/userguide/index.html [2] https://commons.apache.org/proper/commons-geometry/tutorials/teapot.html > > Cheers > > [1] https://arrow.apache.org/blog/ > > On Tue, 16 Apr 2024 at 09:06, Claude Warren wrote: > > > I was wondering if there is a blog dedicated to commons? I have several > > blog posts about using the new Bloom filters in collections 4.5 and am > > looking for a place to publish. > > > > Claude - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [LEGACY STAT] test suite from legacy includes non-free NIST data
Le mer. 27 mars 2024 à 02:37, Elliotte Rusty Harold a écrit : > > This is something to ask Apache lawyers about. You could ask there: https://issues.apache.org/jira/browse/LEGAL > Yes, we're allowed to > distribute this public US government data. https://www.nist.gov/itl/ssd/software-quality-group/national-software-reference-library-nsrl/subscribe/redistribution In particular: --- The RDS is not subject to copyright protection and is in the public domain. --- > No, that doesn't mean we > can distribute it under the Apache license. I think we can[1], but it is of no consequence (ASL will not apply to the public domain files). Quoting from Wikipedia[2]: --- The legal scholar Melville Nimmer has written that "it is axiomatic that material in the public domain is not protected by copyright, even when incorporated into a copyrighted work". Regards, Gilles [1] Within the files, there is a link to the original source (NIST). [2] https://en.wikipedia.org/wiki/Public_domain > I can't tell. The legal nitpicking is beyond me. > > On Tue, Mar 26, 2024 at 10:46 PM Orion Yeung wrote: > > > > Hello, > > > > I was unsure how to identify the component in the subject header here, but > > I'd noticed you've got the standard reference NIST data in your repo, here: > > > > https://github.com/apache/commons-math/tree/master/commons-math-legacy/src/test/resources/org/apache/commons/math4/legacy/stat/data > > > > that we - on a statistics Rust crate - realized we needed to stop > > redistributing in our repo. *I'm not a legal person, but I'm providing the > > heads up as it may be a copyright violation. *Feel free to ask me for > > clarifications. > > > > Some relevant links, > > > > [Fedora mailing list discussing this data when using the crate] ( > > https://lists.fedoraproject.org/archives/list/legal%40lists.fedoraproject.org/thread/LSM6MO6TAHTIDNF5COCA6UWQDHWRF3AH/ > > ) > > [statrs GitHub issue mentioning this]( > > https://github.com/statrs-dev/statrs/issues/195) > > > > Best, > > -- > > Orion Yeung > > he / him - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [LEGACY STAT] test suite from legacy includes non-free NIST data
Hi. Le mar. 26 mars 2024 à 23:46, Orion Yeung a écrit : > > Hello, > > I was unsure how to identify the component in the subject header here, but > I'd noticed you've got the standard reference NIST data in your repo, here: > > https://github.com/apache/commons-math/tree/master/commons-math-legacy/src/test/resources/org/apache/commons/math4/legacy/stat/data > > that we - on a statistics Rust crate - realized we needed to stop > redistributing in our repo. *I'm not a legal person, but I'm providing the > heads up as it may be a copyright violation. *Feel free to ask me for > clarifications. First result in a Google search: --- In general, publications of the National Institute of Standards and Technology, as publications of the Federal government, are in the public domain and not subject to copyright in the United States. Permission to reprint or copy from them is therefore not required. The original source should be credited. --- Also: https://www.nist.gov/open/copyright-fair-use-and-licensing-statements-srd-data-software-and-technical-series-publications#data Doesn't this apply to the data being referred to? Excerpt: --- To the extent that NIST may hold copyright in countries other than the United States, you are hereby granted the non-exclusive irrevocable and unconditional right to print, publish, prepare derivative works and distribute the NIST data, in any medium, or authorize others to do so on your behalf, on a royalty-free basis throughout the world. ---CUT--- Regards, Gilles > [...] - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [Math] How to update the web site?
Le sam. 9 mars 2024 à 03:57, Gary Gregory a écrit : > > It looks like the Maven SCM plugin wants your password. Did you > provide it on the command line? The error message (cf. below) says: "interactive prompting was disabled". No prompt has been asking to supply a login and password. Gilles > > Gary > > On Thu, Mar 7, 2024 at 11:33 AM Gilles Sadowski wrote: > > > > Le jeu. 7 mars 2024 à 15:20, Gary Gregory a écrit : > > > > > > Please see https://commons.apache.org/site-publish.html > > > > Thanks. > > Trying > > $ mvn scm-publish:publish-scm > > results in > > ---CUT--- > > [ERROR] Failed to execute goal > > org.apache.maven.plugins:maven-scm-publish-plugin:3.2.1:publish-scm > > (default-cli) on project commons-math4-parent: Failed to check-in > > files to SCM: The svn command failed. svn: E215004: Authentication > > failed and interactive prompting is disabled; see the > > --force-interactive option > > [ERROR] svn: E215004: Commit failed (details follow): > > [ERROR] svn: E215004: No more credentials or we tried too many times. > > [ERROR] Authentication failed > > ---CUT--- > > > > [Appending "--force-interactive" does not help.] > > > > By the way, if this is the recommended way, should we remove the > > "site"-related statements in the components' specific POM files? > > > > Gilles > > > [...] - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [Math] How to update the web site?
Le jeu. 7 mars 2024 à 15:20, Gary Gregory a écrit : > > Please see https://commons.apache.org/site-publish.html Thanks. Trying $ mvn scm-publish:publish-scm results in ---CUT--- [ERROR] Failed to execute goal org.apache.maven.plugins:maven-scm-publish-plugin:3.2.1:publish-scm (default-cli) on project commons-math4-parent: Failed to check-in files to SCM: The svn command failed. svn: E215004: Authentication failed and interactive prompting is disabled; see the --force-interactive option [ERROR] svn: E215004: Commit failed (details follow): [ERROR] svn: E215004: No more credentials or we tried too many times. [ERROR] Authentication failed ---CUT--- [Appending "--force-interactive" does not help.] By the way, if this is the recommended way, should we remove the "site"-related statements in the components' specific POM files? Gilles > > On Thu, Mar 7, 2024, 9:10 AM Gilles Sadowski wrote: > > > Hi. > > > > In relation to > > https://issues.apache.org/jira/browse/MATH-1667 > > I'm trying to regenerate the (live) site of [Math], but > > I've lost track of the "right" way to do it in accordance > > with the latest contents of the POM file; there is a > > profile named "site-checkout" but running > > $ mvn -P site-checkout > > did not check out the web site's files (into directory > > "site-content") as I was, perhaps wrongly, expecting. > > > > Also, is it still OK to (force) update of the live site's > > files (at the risk of breaking). Or has a safer way be > > put in place? [Some time ago, there was a discussion > > about moving web sites to "git" repositories...] > > > > Best, > > Gilles - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
[Math] How to update the web site?
Hi. In relation to https://issues.apache.org/jira/browse/MATH-1667 I'm trying to regenerate the (live) site of [Math], but I've lost track of the "right" way to do it in accordance with the latest contents of the POM file; there is a profile named "site-checkout" but running $ mvn -P site-checkout did not check out the web site's files (into directory "site-content") as I was, perhaps wrongly, expecting. Also, is it still OK to (force) update of the live site's files (at the risk of breaking). Or has a safer way be put in place? [Some time ago, there was a discussion about moving web sites to "git" repositories...] Best, Gilles - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
[Statistics][All] Web site partly broken
Hi. >From the "home" page: https://commons.apache.org/proper/commons-statistics/ clicking on the "latest release" link: https://commons.apache.org/statistics/download_statistics.cgi leads to a page where the layout has not been applied. Regards, Gilles - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [all, site] Logo Update?
It's a quick change to update the main page with the current "graphical identity" of the ASF (new feather). [I.e. just use the logo which the ASF main site is using.] Not so much to modify (using Gimp) each component's logo. And something that will need redoing in a few months from now... Le mar. 26 déc. 2023 à 16:42, Gary Gregory a écrit : > > Tip: copy and edit the SVG, probably using... Gimp? > > Gary > > > > [...] - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [all, site] Logo Update?
Le mar. 26 déc. 2023 à 16:31, Rob Tompkins a écrit : > > If that’s indeed the case, then wouldn’t the easiest thing be to simply > incorporate the feather into the current logo design as a quick update while > we wait for the new branding? The first link which I pointed contains an image where this was done (i.e. incorporate the new feather in the original "Commons" logo design, modulo the remark make by Emmanuel Bourg at the time concerning the URL). Regards, Gilles > > -Rob > > > On Dec 26, 2023, at 10:32 AM, Gilles Sadowski wrote: > > > > Le mar. 26 déc. 2023 à 16:12, Rob Tompkins a écrit : > >> > >> Good call. I’m going to add one to the list and then put the logos up for > >> a [VOTE] to the community to choose which (by ordering them most preferred > >> to least). > > > > Well, a good logo is not just a question of preference; e.g. there may be > > some design guidelines which not everyone is aware of, or pay attention > > to, or otherwise finds appealing. > > > > More importantly the ASF board has decided (AFAIK) to again change > > the "graphical identity" of the foundation; so this probably not the right > > time for reviving such discussion. > > > > Regards, > > Gilles > > > >> [...] - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [all, site] Logo Update?
Le mar. 26 déc. 2023 à 16:12, Rob Tompkins a écrit : > > Good call. I’m going to add one to the list and then put the logos up for a > [VOTE] to the community to choose which (by ordering them most preferred to > least). Well, a good logo is not just a question of preference; e.g. there may be some design guidelines which not everyone is aware of, or pay attention to, or otherwise finds appealing. More importantly the ASF board has decided (AFAIK) to again change the "graphical identity" of the foundation; so this probably not the right time for reviving such discussion. Regards, Gilles > [...] - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [all, site] Logo Update?
Hello. Le mar. 26 déc. 2023 à 03:52, Rob Tompkins a écrit : > > Hey all, > > Should we use the more modern feather with the same logo (-1, -0, +0, +1)? > Happy to give a shot at creating the same logo with the new feather. A logo with the "new" ASF graphics has been there for years: https://apache.org/logos/#commons When the discussion occurred (IIRC there was a ML thread too), very few provided an opinion: https://issues.apache.org/jira/browse/COMMONSSITE-86 Hence, the main "Commons" page was not updated. Logo was updated for some components: https://commons.apache.org/proper/commons-math https://commons.apache.org/proper/commons-rng https://commons.apache.org/proper/commons-numbers https://commons.apache.org/proper/commons-geometry https://commons.apache.org/proper/commons-statistics Regards, Gilles - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [MATH] MultiStartMultivariateOptimizerTest.testCircleFitting flaky test
Le sam. 23 déc. 2023 à 23:50, sebb a écrit : > > On Sat, 23 Dec 2023 at 15:44, Gilles Sadowski wrote: > > > > Hello. > > > > Le sam. 23 déc. 2023 à 16:30, sebb a écrit : > > > > > > The test MultiStartMultivariateOptimizerTest.testCircleFitting [1] > > > seems to be flaky. > > > > > > It often fails with values below the expected minimum of 750. > > > > > > Does this indicate a real failure, or can the minimum be safely reduced? > > > > I think so (if the right answer is found in fewer iterations, all the > > better). > > I wondered about that, but then why is there a lower limit at all? > > The history shows that the minimum was previously lower, but there are > suggestions that the counts may have been inaccurate. > At one point the limits were 590 < n < 610 which would definitely not work > now! Testing a lower limit predates the API refactoring (that occurred many years ago). I vaguely recall (?) that the lower limit had to be increased because the previous implementation may have indeed not counted some calls to the evaluation function. Regards, Gilles > > > > > > Sebb > > > [1] > > > https://github.com/apache/commons-math/blob/b0cefc56c67bd41ec9f14311f058d319b05c0312/commons-math-legacy/src/test/java/org/apache/commons/math4/legacy/optim/nonlinear/scalar/MultiStartMultivariateOptimizerTest.java#L75-L76 > > > - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [MATH] MultiStartMultivariateOptimizerTest.testCircleFitting flaky test
Hello. Le sam. 23 déc. 2023 à 16:30, sebb a écrit : > > The test MultiStartMultivariateOptimizerTest.testCircleFitting [1] > seems to be flaky. > > It often fails with values below the expected minimum of 750. > > Does this indicate a real failure, or can the minimum be safely reduced? I think so (if the right answer is found in fewer iterations, all the better). Regards, Gilles > > Sebb > [1] > https://github.com/apache/commons-math/blob/b0cefc56c67bd41ec9f14311f058d319b05c0312/commons-math-legacy/src/test/java/org/apache/commons/math4/legacy/optim/nonlinear/scalar/MultiStartMultivariateOptimizerTest.java#L75-L76 > - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: Security model for Commons Imaging, Compress, Codec and IO: RCE and DOS?
Hello. Le jeu. 14 déc. 2023 à 12:10, Arnout Engelen a écrit : > > Hello Commons developers, > > I'd like to discuss what our security ambitions are for components like > Commons Imaging, Compress, Codec and IO: > > Generally for Commons, we say that unless otherwise specified it is up to > the user of the library to make sure any input is either trusted or > correctly validated/sanitized (https://commons.apache.org/security.html). > > For these modules it might make sense to be a little more nuanced: > https://commons.apache.org/proper/commons-imaging/ already explicitly says > it intends to be "more secure against corrupt/malicious images", and while > the others don't seem to say it explicitly AFAICS in practice we consider > it OK to decompress/decode/... untrusted input at least to some degree. > > So what does that mean? > > * I'd say parsing/decompression/decoding should never allow malicious input > to trigger arbitrary code execution(?) +1 > * Should parsing/decompression/decoding protect against 'disproportionate' > CPU usage? > * Should parsing/decompression/decoding protect against 'disproportionate' > memory usage? > * Should parsing/decompression/decoding protect against 'disproportionate' > disk usage? > > Where we say 'yes', I vaguely recall a similar conversation where the answer was "no" (IIRC). [Along: "What is the definition of disproportionate?"] > we should also decide whether we intend to treat such > issues as security problems (that should be fixed with some priority and, > after release, disclosed in an advisory) or bugs/improvements (where we can > possibly take more of an 'issues and patches welcome' position). > > I'm curious about your thoughts! > If "Commons" intends to provide utilities with the same purpose across components, it would be sensible to have them defined in a "lower"-level component on which [Imaging], [Compress], ... would depend. Especially if the corresponding code is purported to be focused on security, "let's just copy the source" should not be allowed. Regards, Gilles - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [All] Download page broken for several components
Le mar. 28 nov. 2023 à 18:39, sebb a écrit : > > Doh! Mea culpa. > > Turns out this issue had previously been solved, but during a clear-up > I managed to remove the work-rounds. > > Hopefully all now resolved. Yes; thanks! Gilles >>>> [...] - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
[All] Download page broken for several components
Hello. For https://commons.apache.org/geometry/download_geometry.cgi https://commons.apache.org/math/download_math.cgi https://commons.apache.org/numbers/download_numbers.cgi https://commons.apache.org/statistics/download_statistics.cgi https://commons.apache.org/rng/download_rng.cgi much of the usual contents (namely links to "zip" and "tar" files) is missing. Page also does not correctly display the menus. logo, ... Gilles - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [VOTE] Release Apache Commons Logging 1.3.0 based on RC1
Le lun. 27 nov. 2023 à 00:15, Piotr P. Karwasz a écrit : > [...] > +1 (non binding): everything works correctly with the following remarks: > > 1. the SPDX artifact is not reproducible, > 2. For some strange reason I had to set `TZ=America/New_York` to make > the main JAR reproducible. Either the Moditect or the Maven JAR plugin > are responsible for that. > 3. The SHA512 sums in the distribution can not be used with > `sha512sum -c` (they lack the file name). Maybe related to this old feature request: https://issues.apache.org/jira/browse/COMMONSSITE-133 Gilles - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [ALL] Standardise Maven defaultGoal in components?
Le dim. 8 oct. 2023 à 16:48, Gary Gregory a écrit : > > Clirr and FindBugs are now unmainted and broken on modern Java versions. > They have been replaced by JApiCmp and SpotBugs. +1 to not run deprecated software. > > It does not make sense IMO to run both JApiCmp and RevApi, they do the same > thing. Supposedly; but there was one case where "revapi" spotted a potential problem not found by "japicmp". [I don't remember the details.] In any case, it doesn't hurt to run both, does it? [Or one can be in the default, and the other added by projects that want it...] Gilles >> [...] - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [ALL] Standardise Maven defaultGoal in components?
Le dim. 8 oct. 2023 à 16:11, sebb a écrit : > > There are currently lots of variations of the defaultGoal in different > components. > > It may be sensible to establish a standard setting which components > should adopt (unless there is a good reason to do otherwise). +1 > > If so, what should that be, Anything and everything that would lead to a -1 by the reviewer (if just to avoid spending cycles on something that could have been detected automatically). > and where does it get documented? Can it be defined in "commons-parent" POM file? > > Personally, I don't think install should ever be a default goal as it > changes the environment outside the component. +1 > > Main goals seen: > clean > install > package > site > test > verify $ mvn clean test verify Isn't "test" included in "verify"? > > Other goals seen: > apache-rat:check > checkstyle:check > clirr:check > findbugs:check > japicmp:cmp > javadoc:javadoc > pmd:check > pmd:cpd-check > spotbugs:check +1 (all of the above, plus "revapi:check") Regards, Gilles - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [LANG] Extend "EqualsBuilder (Was: Pull request)
Hello. Le mer. 27 sept. 2023 à 11:48, Marc Cappelletti a écrit : > > Hello Gilles, > > Thanks for the details and the comment. Thanks for your interest in contributing. > > By the way, do we comment directly on the PR Many people mostly do it on GH (which shuns people who don't want to register with GH...). Alternatively, implementation details can be discussed in JIRA comments. > or strictly via this mailing > list? New features and major changes should be approved on this ML. Once done, technical discussions will likely occur in one or the other venue mentioned above. Regards, Gilles >> [...] - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
[LANG] Extend "EqualsBuilder (Was: Pull request)
Hello.
As this list is shared among many (30+) "components" of the "Commons"
project, the "Subject: " line should be prefixed by the "id" of the component
(in this case: "[LANG] Pull request"). It is also nice if the subject line is a
bit more specific (in this case: "[LANG] Extend "EqualsBuilder"), so that it
draws the attention of the regular maintainer(s) of that part of the library.
Le mer. 27 sept. 2023 à 10:33, Marc Cappelletti
a écrit :
>
> Hello,
>
> I'm a new contributor and I have a pull request:
> https://github.com/apache/commons-lang/pull/1114
Increasing a field visibility (in this case removing the "private" qualifier
of "isEquals") is rarely a good idea.
Wouldn't it be possible to add the capability to the existing class?
If not, perhaps via adding a ("protected") helper method or constructor?
>
> Is everything okay for a review or do I need to publish the link somewhere,
> like in this dev list? :)
>
For tracking purposes, please file a JIRA report:
https://issues.apache.org/jira/projects/LANG
Thanks,
Gilles
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
Re: [statistics] descriptive module
Hello. Le mar. 26 sept. 2023 à 18:33, Alex Herbert a écrit : > > I have been looking at continuing the work on the descriptive module > to add the remaining stats found in Commons Math. Thanks! > Before adding more > classes I would like to address the current implementation pattern. > > The statistics in the descriptive module are currently abstract > classes with a concrete inner class that is prefixed Storeless. > > This pattern would make sense if there was the intention to provide > stored implementations. There was some discussion about this IIRC.[1] > Currently I do not think this would be the > best solution. For example it would make sense to separate the storage > of a variable size stream of double values, from the computation of a > statistic. That is, a resizable backing array storage is out of scope > for this module. > > I propose to simplify the current implementations to final classes > that implement the current Storeless functionality. Any future change > to stored, immutable, or other implementations can be provided by > changing the final class back to abstract with different > implementations. +1 Regards, Gilles [1] https://issues.apache.org/jira/projects/STATISTICS/issues/STATISTICS-77 - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: No sign of releases for Functor or OGNL - move to dormant?
Le mer. 20 sept. 2023 à 15:36, sebb a écrit : > > I cannot find any releases for Functor Briefly looking at the description and examples pages (not the code), it seems that much functionality has been superseded by the standard "java.util.function" package and lambdas. What looks interesting is the mention of "design patterns"; maybe this part could be moved to somewhere else (if sufficiently useful)... > or OGNL, No site update since 2013 (according to the date on the web page). Code never moved to "git" (according to the "source repository" page). Just inferring potential usage from the description, it seems that "Groovy" would be a more appropriate (and supported) tool (?). Regards, Gilles > yet they are listed on > the commons home page, and the releases page. > > Seems to me they should be moved to dormant? > > Sebb - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [pool] RC time
Le dim. 17 sept. 2023 à 15:46, Eric Bresie a écrit : > > Which indicates: > > "This document is meant as a step-by-step recipe to achieve the release of > the Commons RNG component. Note that more general instructions valid > for all components, including [rng], are available on the Apache Commons > main site: at *"https://commons.apache.org/releases/prepare.html > <https://commons.apache.org/releases/prepare.html>"* and > *"https://commons.apache.org/releases/release.html > <https://commons.apache.org/releases/release.html>"* That paragraph has been there for years; it is not a guarantee that the referred documents actually contain "general instructions valid for all components". What is (almost) certain is that the instructions embedded in a component's source directory worked for the last release of that component, and were probably updated during the preparation of that release. [Those updates were made necessary because the "general" instructions (and in the past there were several sets of them) actually did *not* work for all components. We cannot have "general" instructions until we agree and enforce a common layout for all components.] Gilles >> [...] - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [pool] RC time
Le sam. 16 sept. 2023 à 23:54, Phil Steitz a écrit : > > It has been quite a few years since I cut a Commons release, but I would > like to step up for pool 2.12. I think the code in the 2_X branch is > ready. All of my soak tests and tests with my own apps and dbcp passed. I > am sure a lot has changed since I last did this. Is there a checklist or > instructions somewhere? https://github.com/apache/commons-rng/blob/master/doc/release/release.howto.txt > > Phil - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [Imaging] Drop Serializable
Hello. Le jeu. 31 août 2023 à 15:29, Gary Gregory a écrit : > > Hi All, > > I propose we drop implementating Serializable +1 Gilles > and avoid any and all > possible security issues in this area. > > Gary - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [Meta] gitlab error responses to mailing list
Hi. Le jeu. 10 août 2023 à 15:41, Mark Thomas a écrit : > > Got them. > > The idiot concerned has won themselves a lifetime subscription to the > deny list for commons-dev and the handful of other ASF lists they are > subscribed to. > > Sorry it took a while to sort this out. Was it a mistake or was there a purpose? > > Some of you won't yet have received the test message yet due to my mail > server being rate limited. You should received it in the next few hours. Out of curiosity, what was the strategy for figuring out what was going on? [Or a pointer to a description of the issue and the way to fix it.] Thank you, Gilles >> [...] - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [Meta] gitlab error responses to mailing list
Le lun. 7 août 2023 à 16:38, Gilles Sadowski a écrit : > > Le lun. 7 août 2023 à 10:46, Mark Thomas a écrit : > > > > Got the error message. To help me play hunt the subscriber, can anyone > > provide information on when this behaviour started? > > I got one on Saturday at 11:17, in a thread with >[commons-math] Three Concerns > as subject line. Content was: > ---CUT--- > Unfortunately, your email message to GitLab could not be processed. > > We couldn't figure out what the email is for. Please create your issue > or comment through the web interface. > ---CUT--- And again, just now, in reply to the above message... > > Regards, > Gilles > > >> [...] - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [Meta] gitlab error responses to mailing list
Le lun. 7 août 2023 à 10:46, Mark Thomas a écrit : > > Got the error message. To help me play hunt the subscriber, can anyone > provide information on when this behaviour started? I got one on Saturday at 11:17, in a thread with [commons-math] Three Concerns as subject line. Content was: ---CUT--- Unfortunately, your email message to GitLab could not be processed. We couldn't figure out what the email is for. Please create your issue or comment through the web interface. ---CUT--- Regards, Gilles >> [...] - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [commons-math] Three Concerns
Hello. Le sam. 5 août 2023 à 08:08, Hasan Diwan a écrit : > > I'm trying to migrate an internal service for interpolation to commons-math > 3.6.1, using org.apache.commons.math3.fitting.GaussianCurveFitter. Thanks for your interest in "Commons Math". For any new code, you should use the latest version (currently, v4.0-beta1). Version 3.6.1 is 7 years old.[1] > My > thoughts on this method: > > - The fit() function returns a double[], what the numbers mean is missing > from the javadoc. I can write the doc, but just need to know what they > should be. It is documented (at least in v4.0-beta1). > This is the quick fix, but I feel we should consider having the > method return a Map where the key could be a descriptive > label of what it means. I'm not sure it adds anything to the API; a caller would have to know the list of keys, instead of the list of indices. > This would be in addition to the javadoc addition > mentioned earlier. > > - Exceptions that are thrown by the fit() method ought to inherit from > Exception instead of RuntimeException. > > - 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? > I don't know. More details should be provided, as requested on the JIRA ticket which you reported.[2] Regards, Gilles [1] https://commons.apache.org/proper/commons-math/changes-report.html [2] https://issues.apache.org/jira/browse/MATH-1663 - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [DbUtils] Issue: Can not find Apache Commons DbUtils version 1.8
Hello.
[Don't forget to set the prefix (in this case "[DbUtils]") in a post's
"Subject: " line; this ML is shared by 30+ components.]
Le dim. 30 juil. 2023 à 11:05, sharedata a écrit :
>
> Apache Commons DbUtils1.7 version have thread bugs in BeanProcessor
> class via SPI ServiceLoader.
>
> Apache Commons DbUtilsgithub website have declared version 1.8,
All resources ("Commons" homepage, "Maven Central") refer to 1.7 as the
last release.
The "master" branch is set to develop the next major release (2.0).
However, the "release" branch's POM file does indeed contain[1]
---CUT---
1.8
---CUT---
Hopefully, someone can clarify (e.g. point to the ML posts where a roadmap
may have been discussed).
Gilles
[1] https://github.com/apache/commons-dbutils/blob/release/pom.xml#L27
> but the apache officialwebsite and maven repository all still stay in
> 1.7 old version.
>
>
>
>
> See:
>
> https://github.com/apache/commons-dbutils
>
> https://commons.apache.org/proper/commons-dbutils/download_dbutils.cgi
>
> https://mvnrepository.com/artifact/commons-dbutils/commons-dbutils
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
Re: [math] JIRA ticket for modularisation of all 14 legacy packages
Le jeu. 20 juil. 2023 à 23:46, Dimitrios Efthymiou a écrit : > > I am not home now, but these are the ones i remember from looking at the > GitHub repo: > AbstractStorelessUnivariateStatistic.java > AbstractUnivariateStatistic.java > WeightedEvaluation.java > Sum.java > FirstMoment.java > Mean.java > SecondMoment.java > StandardDeviation.java > Variance.java > VectorialMean.java Please try what I suggested in my previous message (about 30 lines of code that could be copied into an "internal" package to get the same functionality as the last 2 classes above). Then we can continue discussing (on JIRA) on how to move around roadblocks actually encountered. [You can create a JIRA "sub-task" for each specific problem.] Gilles > > > On Thu, 20 Jul 2023, 22:40 Gilles Sadowski, wrote: > > > Le jeu. 20 juil. 2023 à 23:28, Dimitrios Efthymiou > > a écrit : > > > > > > Unfortunately, i just tried a simple move, but there are deoendencies on > > 3 > > > distance classes > > > > But... those classes are only used by the "clustering" package; they > > are not external dependencies; they would go into the new module > > as first-class citizens. > > [A follow-up issue would be whether those distance classes are > > worth sharing with the other machine learning utility in the module > > "commons-math-neuralnet".] > > > > > and about 12 stats classes, > > > > Which ones? > > > > > because there are transitive > > > dependencies. Not to mention the respective test classes. > > > > Well, of course there is work to do to fix all aspects of the move... > > > > Gilles > > > > > > > > > > > [...] - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [math] JIRA ticket for modularisation of all 14 legacy packages
Le jeu. 20 juil. 2023 à 23:28, Dimitrios Efthymiou a écrit : > > Unfortunately, i just tried a simple move, but there are deoendencies on 3 > distance classes But... those classes are only used by the "clustering" package; they are not external dependencies; they would go into the new module as first-class citizens. [A follow-up issue would be whether those distance classes are worth sharing with the other machine learning utility in the module "commons-math-neuralnet".] > and about 12 stats classes, Which ones? > because there are transitive > dependencies. Not to mention the respective test classes. Well, of course there is work to do to fix all aspects of the move... Gilles > > > > > > > [...] - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [math] JIRA ticket for modularisation of all 14 legacy packages
Le jeu. 20 juil. 2023 à 21:19, Dimitrios Efthymiou
a écrit :
>
> are you saying that in order to move the ml.clustering classes
> to the new clustering module, I can take all the dependencies to classes
> and their transitive dependencies, copy them to the new clustering module,
> but only keep in them the minimum required code for the new module to
> operate?
To some extent, yes. But the main point is the refactoring. For example,
your wouldn't copy the code from "linear" after seeing that one can do
without it. But also note in this case that exposing a "double[][]" instead
may not be the best choice for a long-term API. As was mentioned, it
would be worth looking at how other libraries provide similar functionality.
The module should solve all issues mentioned in JIRA; it's not just copying
the classes and removing dependencies.
Gilles
>
> On Thu, 20 Jul 2023 at 15:27, Gilles Sadowski wrote:
>
> > Hello.
> >
> > Le mer. 19 juil. 2023 à 12:59, Dimitrios Efthymiou
> > a écrit :
> > >
> > > [...]
> > > 1-- [...]
> > > 2--As for the atomic refactoring and feature branch, well,
> > > unless someone moves the Variance class (you said that someone
> > > is doing it now) and the distance package and whatever other
> > > dependencies exist within the ml.clustering package,
> > > there can be no moving of the remaining clustering classes
> > > to the new clustering module, right?
> > > 3-- [...]
> > > 4--I don't know how to continue with the clustering modularisation
> > > given all those dependencies. Maybe I shouldn't have started this,
> > > because now I am stuck
> >
> > You aren't.
> >
> > The dependencies found in "o.a.c.math4.legacy.ml.clustering" are
> > (1) "MatrixUtils" and "RealMatrix" (from the "linear" package)
> > (2) "Variance" and "VectorialMean" (from the "stat" package)
> >
> > (1) creates the coupling for a single method ("getMembershipMatrix")
> > that isn't called from anywhere (not even the unit tests). Remove the
> > method and the dependency towards "linear" vanishes.
> >
> > (2) "Variance" can be replaced with a temporary implementation like
> > (untested copy/paste from "SecondMoment" and "FirstMoment"):
> > ---CUT---
> > class Variance {
> > private int n = 0;
> > private double dev = 0;
> > private double nDev = 0;
> > private double m2 = 0;
> > private double m1 = 0;
> >
> > void increment(final double d) {
> > ++n;
> > dev = d - m1;
> > nDev = dev / n;
> > m1 += nDev;
> > m2 += ((double) n - 1) * dev * nDev;
> > }
> >
> > double get() {
> > return m2;
> > }
> > }
> > ---CUT---
> > Then, creating a private copy of class "VectorialMean" (replacing,
> > in the copy, CM exceptions with JDK ones) would complete the
> > removal of the dependency towards the "stat" package.
> >
> > And so on.
> >
> > Regards,
> > Gilles
> >
> > > > > [...]
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
Re: [math] JIRA ticket for modularisation of all 14 legacy packages
Hello.
Le mer. 19 juil. 2023 à 12:59, Dimitrios Efthymiou
a écrit :
>
> [...]
> 1-- [...]
> 2--As for the atomic refactoring and feature branch, well,
> unless someone moves the Variance class (you said that someone
> is doing it now) and the distance package and whatever other
> dependencies exist within the ml.clustering package,
> there can be no moving of the remaining clustering classes
> to the new clustering module, right?
> 3-- [...]
> 4--I don't know how to continue with the clustering modularisation
> given all those dependencies. Maybe I shouldn't have started this,
> because now I am stuck
You aren't.
The dependencies found in "o.a.c.math4.legacy.ml.clustering" are
(1) "MatrixUtils" and "RealMatrix" (from the "linear" package)
(2) "Variance" and "VectorialMean" (from the "stat" package)
(1) creates the coupling for a single method ("getMembershipMatrix")
that isn't called from anywhere (not even the unit tests). Remove the
method and the dependency towards "linear" vanishes.
(2) "Variance" can be replaced with a temporary implementation like
(untested copy/paste from "SecondMoment" and "FirstMoment"):
---CUT---
class Variance {
private int n = 0;
private double dev = 0;
private double nDev = 0;
private double m2 = 0;
private double m1 = 0;
void increment(final double d) {
++n;
dev = d - m1;
nDev = dev / n;
m1 += nDev;
m2 += ((double) n - 1) * dev * nDev;
}
double get() {
return m2;
}
}
---CUT---
Then, creating a private copy of class "VectorialMean" (replacing,
in the copy, CM exceptions with JDK ones) would complete the
removal of the dependency towards the "stat" package.
And so on.
Regards,
Gilles
> > > [...]
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
Re: [commons-io] question: file content merge sort and binary search
Le jeu. 20 juil. 2023 à 15:18, Gary Gregory a écrit : > > [...] Instead of keeping on arguing to shove your library in [...] If we could stop the brutal language... (?) The OP asked politely, and was ready to wait indefinitely (unsubscribing from this ML) for an answer; I just wanted to make sure that there was no missed opportunities (on both ends). Regards, Gilles > [...] - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [commons-io] question: file content merge sort and binary search
Hi. [Disclaimer: I'm not a user nor a developer of "Commons IO", so I'm not the most suitable for entertaining this conversation and, surely, I shouldn't be the only one...] Le jeu. 20 juil. 2023 à 10:33, ssz a écrit : > > Hi > Sure, I will support my code. > I have a lot of other opensource projects, not so much free time. I have to point out that the two sentences seem to neutralize themselves... > But this code will have the highest priority as Commons is used by > thousands of developers. That's what I've heard, but did not see much of a proof: We have no reliable way to know where "Commons" code is used. [This was a feature of open-source, but new regulations might make it a liability...] More importantly, if true, only a very tiny fraction of those users share their experience here, so that a quite small number of "regular" developers end up deciding what is useful. Almost inevitably, the selection is biased... > My other projects are used by hundreds of people. That's great, but would not convince (based on the lack of feedback) a committer here who is not among those users. The general problem is: 1. The active team is not getting bigger. 2. Those "regular" developers find they have already too much to handle. 3. Hence they tend to not easily accept contributions that are (or seem) likely to require time which they don't have. 4. This puts off would-be contributors that could have become part of the active team. 1. The active team is not getting bigger... So I'm trying to find other arguments... Which projects (ASF?) depend on your proposed contribution? Regards, Gilles >>> [...] - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [commons-io] question: file content merge sort and binary search
Hi. Le mar. 18 juil. 2023 à 19:06, ssz a écrit : > > [...] > > We use this library as a second-level cache when parsing CIMXML RDF, this > file-based cache contains triples, and also subject-type pairs (RDF nodes). > It is not csv. > Also, I'm thinking about RDF-Graph implementation backed by fs. This is where the discussion, about whether "Commons" is the right place, could start because... > > So, I think we can always find ways to use this functionality. > Placing it in some common place would save other developers time. ... placing it here implies that there will be people willing to stay around and maintain ... > Implementation of file-sorting and searching is not so simple as it sounds. ... this "not so simple" functionality. That's why we ask for use-cases: People who have a direct interest in maintaining the functionality are more likely to help fix it when the need arises. IOW, I'd expect the contributors of a major functionality of which they are the only known users to stay around in order to support it. Regards, Gilles > [...] - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [math] JIRA ticket for modularisation of all 14 legacy packages
Le mer. 19 juil. 2023 à 17:48, Elliotte Rusty Harold a écrit : > > On Wed, Jul 19, 2023 at 11:38 AM Gilles Sadowski wrote: > > > I think that the page one would look for is this one: > >https://commons.apache.org/proper/commons-math/dependency-info.html > > It's fine to put it there, but even if it's correct it's still too > hard to find. The only way to get to that page is scroll about two > thirds of the way down a sidebar and click one of the four links that > mention "dependencies" that seems as likely to bring you to a list of > commons-math's own dependencies rather than how to add this project as > a dependency. I'm a Maven comitter who's spent way more time in the > depths of Maven Project website generation than 99.9% of Java > programmers and I still couldn't find this the first time I looked for > it. That's de facto evidence that this information is not easy to > find. You are quite right. [IIRC, trying to figure it out from "Maven Central" is even worse.] The "Commons" web site esthetics and ergonomy has never attracted much attention. [After years of a new one being potentially available[1], even the logo did not change (all of the "new" ones will become obsolete in a few months following the ASF rebranding effort).] > > This coordinates belong right up front on > https://commons.apache.org/proper/commons-math/index.html +1 Would you file a report on https://issues.apache.org/jira/projects/COMMONSSITE/ ? > > I am tempted to see about changing the title of that page in the > sidebar from "Dependency Information" to "Maven Coordinates". Those pages are providing dependency info not only for maven: The info is there for (each module too), see e.g. https://commons.apache.org/proper/commons-math/commons-math4-transform/dependency-info.html but it would be nice indeed that the BOM snippet appears prominently on https://commons-math4-transform/dependency-info.html > That > would help a little and it's likely commons-math is hardly the only > project that has this issue. > The web site template is shared by all components. One change will fix them all. ;-) Well, not really: First step is to agree to generate a BOM module like Alex created for "RNG", and that the "Overview" page links to it. That would imply that all projects must become "modular" even if just to have two modules (one "code" and one BOM)... That would be "good" (TM), IMHO. Regards, Gilles [1] https://issues.apache.org/jira/projects/COMMONSSITE/issues/COMMONSSITE-86 - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [math] JIRA ticket for modularisation of all 14 legacy packages
Le mer. 19 juil. 2023 à 16:03, Elliotte Rusty Harold a écrit : > > On Wed, Jul 19, 2023 at 9:53 AM Gilles Sadowski wrote: > > > > org.apache.commons.math4 and org.apache.commons.math3 > > > > > > Although it's not easy to find, > > > > What do you mean? > > Is it something we can fix here? > > > > Probably. I did a google search and hunted around on the web pages at > https://commons.apache.org/proper/commons-math/ > > Nowhere did I find a clear statement that "To import commons-math to > a project use the coordinates org.apache.commons:commons-math3:3.6.1" > or anything like that. I just took another look and I see something > for 4.0 at https://commons.apache.org/proper/commons-math/summary.html > but that's not the first place someone would look, and that's only for > the parent project. Not should the main website be for an unreleased > version. > > I'd put this on both Overview pages and probably the Developer's Guide > page at https://commons.apache.org/proper/commons-math/ I think that the page one would look for is this one: https://commons.apache.org/proper/commons-math/dependency-info.html Unfortunately, the "auto-generating" script/template does not take modular maven projects into account. Rather than assuming a single artefact, the build should somehow generate a BOM that would transitively fetch all the modules. I think that Alex managed to do just that for "Commons RNG".[1] Regards, Gilles [1] https://commons.apache.org/proper/commons-rng/commons-rng-bom/index.html - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [math] JIRA ticket for modularisation of all 14 legacy packages
Le mer. 19 juil. 2023 à 14:58, Elliotte Rusty Harold a écrit : > > Commons Math 4 and Commons Math 3 have different java packages: > > org.apache.commons.math4 and org.apache.commons.math3 > > Although it's not easy to find, What do you mean? Is it something we can fix here? > it does look like the Maven > coordinates have changed as well. > > so it's effectively a completely new release of a new project that > can coexist with the older project in a classpath. That shouldn't > cause any dependency problems. :-) Thanks, Gilles - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [math] JIRA ticket for modularisation of all 14 legacy packages
Hi. Le mer. 19 juil. 2023 à 13:43, Elliotte Rusty Harold a écrit : > > Ok, don't do that unless it's new code in new packages. Otherwise > you're creating a dependency hell for existing clients. It is > extremely developer hostile. Pretty much all of https://jlbp.dev/ > applies but especially > > JLBP-5: Do not include a class in more than one classpath entry > JLBP-6: Rename artifacts and packages together I repeat that it has been "Commons policy" for over 15 years. If I missed something, please use concrete examples, based on the modules shipped with v4.0-beta1, so that we can fix it before the "non-beta" release. Thanks, Gilles > > Debugging the problems this will cause is difficult and painful, even > for someone well-versed in Maven dependency management. > > On Wed, Jul 19, 2023 at 11:37 AM Dimitrios Efthymiou > wrote: > > > > no. I mean creating maven modules inside commons-math, like > > the existing ones: > > commons-math-neuralnet > > commons-math-transform > > > > > [...] - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [math] JIRA ticket for modularisation of all 14 legacy packages
Hello. Le mer. 19 juil. 2023 à 12:59, Dimitrios Efthymiou a écrit : > > thanks Gilles. > 1--I think I broke the build, because I did not include (correctly) > the dependency on clustering inside the root pom.xml. My local build > succeeds. I hope that the GitHub build succeeds, as well. It doesn't. > 2--As for the atomic refactoring and feature branch, well, > unless someone moves the Variance class (you said that someone > is doing it now) and the distance package and whatever other > dependencies exist within the ml.clustering package, > there can be no moving of the remaining clustering classes > to the new clustering module, right? Wrong. I made a suggestion on JIRA. > 3--I see that the commons-statistics project, for example, > has empty modules. I think the geometry project (I don't remember which one) > has some classes that are still in commons-math Which ones? > because the migration > is not complete. The migration was completed (it took almost two years) before releasing v1.0 of the [Geometry] component. > So, I thought that I coud do the same i.e. move > the clusteirng classes that do not depend on anything The "same" is doing what I suggested (cf. above). > 4--I don't know how to continue with the clustering modularisation > given all those dependencies. Maybe I shouldn't have started this, > because now I am stuck If the work would have only consisted in copying Java files from one directory to another... It would have been done already. Even for packages that didn't have any dependency (see e.g. the "commons-math-transform" module), the port involved looking at the API to make it more "modern" and/or user-friendly. The "clustering" case is more complicated because, in addition to the API changes and enhancements, there are (few) dependencies (to remove), and bugs (to fix). Please look at the JIRA reports. [One main issue is how to represent a point in (problem domain) space and cluster of those, and distance between them, ...] Regards, Gilles >> [...] - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [math] JIRA ticket for modularisation of all 14 legacy packages
Hello. Le mer. 19 juil. 2023 à 11:21, Dimitrios Efthymiou a écrit : > > I saw 1575, but I didn't see subtasks for all 14 packages. > Is there a plan to modularise all 14 packages? Obviously, it would be good to achieve that, as pointed out in the release notes of version 4.0-beta1: https://commons.apache.org/proper/commons-math/changes-report.html But there is no "plan", like an ordered list of instructions to follow from start to end. The general task is "refactoring". > As for the dependencies on core, linear, analysis, well, > from what I know, the way to modularise a codebase that > was not designed to be modular, is to start moving classes > that do not depend on legacy ones, 1-by-1, And break the build like it is currently the case with the "clustering" refactoring? > slowly. As noted on JIRA[1], the move of an existing functionality into its own (maven) module should be "atomic" on the "master" branch. When the refactoring (started on a developer's local machine) is sufficiently advanced, we can create a feature branch so that several developers can more easily collaborate. > For classes that depend on legacy ones, then we can create > new analysis and linear modules, create interfaces in them > that have the methods our new modularised classes need, > have the legacy classes in analysis and linear implement > those interfaces, have the legacy module depend on the new > analysis and linear modules (since they have the new interfaces), > have the new optimisation module depend on the new > analysis and linear modules and gradually you can move implementation > code from the legacy to the new modules. The dependencies > will be from legacy to the new modules and not the other way > around. So the process I would try is: > 1--create module commons-math-optimisation > 2--create module commons-math-analysis > 3--create module commons-math-linear-algebra > 4--see on which analysis classes does optimisation depends? > 5--see no which specific methods does optimisation depends? > 6--create interfaces in commons-math-analysis for those classes and their > methods that optimisation needs > 7--have the analysis classes implement their respective interfaces from > commons-math-analysis (maintaining the API) > 8--have commons-math-legacy depend on commons-math-analysis and > commons-math-linear-algebra > 9--use these interfaces from within commons-math-optimisation > 10-gradual move of methods and classes from commons-math-legacy to > commons-math-optimisation, commons-math-analysis, > commons-math-linear-algebra Sure! :-} The devil is in the details... One crucial task is to have a way to (optionally) call external implementations of linear algebra algorithms and data-structures. I've no idea whether it's possible to adapt all the functionality to a new design based only on interfaces (and not loose performance). Unless we can really switch between alternative implementations this is a lot of work with literally no gain. Another possibility (also mentioned in [1]) is to isolate the needed utilities in a "private" toolbox. [However, I'd be *very* reluctant if it entails copying several hundred or thousand lines.] Regards, Gilles [1] https://issues.apache.org/jira/browse/MATH-1579?focusedCommentId=17744504=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17744504 > > On Wed, 19 Jul 2023 at 09:49, Gilles Sadowski wrote: > > > Hello. > > > > Le mer. 19 juil. 2023 à 02:33, Dimitrios Efthymiou > > a écrit : > > > > > > Hello everyone. Is there, or gonna be, a dedicated ticket for the > > > modularisation of all 14 packages commons-math-legacy has? > > > > https://issues.apache.org/jira/browse/MATH-1575 > > > > > I think that > > > some of them are easy to modularise like optimisation, > > > > When I list the dependencies towards other packages in "legacy", > > I see > > o.a.c.math4.legacy.core > > o.a.c.math4.legacy.linear > > o.a.c.math4.legacy.analysis > > > > How do you suggest to handle it? > > > > > special > > > > Here, there is only one class, but it should be analysed to > > suggest a better API (and maybe improve performance). > > There is also the question of whether to provide this and other > > special functions with extended precision[1] (and maybe move > > them to [Numbers]; like the gamma family of functions). > > > > > and filter > > > > When I list the dependencies towards other packages in "legacy", > > I see > > o.a.c.math4.legacy.linear > > > > Regards, > > Gilles > > > > > > [1] See section 7.4 in D. Bailey's documentation: > > https://www.davidhbailey.com/dhbpapers/mpfun2020.pdf - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [math] JIRA ticket for modularisation of all 14 legacy packages
Hello. Le mer. 19 juil. 2023 à 02:33, Dimitrios Efthymiou a écrit : > > Hello everyone. Is there, or gonna be, a dedicated ticket for the > modularisation of all 14 packages commons-math-legacy has? https://issues.apache.org/jira/browse/MATH-1575 > I think that > some of them are easy to modularise like optimisation, When I list the dependencies towards other packages in "legacy", I see o.a.c.math4.legacy.core o.a.c.math4.legacy.linear o.a.c.math4.legacy.analysis How do you suggest to handle it? > special Here, there is only one class, but it should be analysed to suggest a better API (and maybe improve performance). There is also the question of whether to provide this and other special functions with extended precision[1] (and maybe move them to [Numbers]; like the gamma family of functions). > and filter When I list the dependencies towards other packages in "legacy", I see o.a.c.math4.legacy.linear Regards, Gilles [1] See section 7.4 in D. Bailey's documentation: https://www.davidhbailey.com/dhbpapers/mpfun2020.pdf - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [commons-io] question: file content merge sort and binary search
Hello.
Le mar. 18 juil. 2023 à 17:35, ssz a écrit :
>
> here https://github.com/sszuev/textfile-utils-examples/tree/master/src/test
Yes, this shows the API and its usage, but I was also wondering
about actual uses. What kind of applications would need to call
this functionality from Java? What does your implementation bring
which a user cannot do with "sort"?[1]
Best regards,
Gilles
[1] https://en.wikipedia.org/wiki/Sort_(Unix)
>
> On Tue, Jul 18, 2023 at 12:03 PM Gilles Sadowski
> wrote:
>
> > Hello.
> >
> > Le mar. 18 juil. 2023 à 10:50, ssz a écrit :
> > >
> > > Hello there
> > >
> > > I see this issue on hold.
> > > So far, no one else has an opinion on this issue.
> >
> > Maybe "Commons Text"?
> > It would help to see use-cases and API examples (in Java).
> >
> > Regards,
> > Gilles
> >
> > > I'm going to unsubscribe from this list for a while.
> > > Please email me directly in case of a positive final decision.
> > >
> > > sss.zuev {at} gmail / com
> > >
> > >>> [...]
> >
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
Re: [math] legac ml.distance package migration
Hello. Le mar. 18 juil. 2023 à 17:30, Dimitrios Efthymiou a écrit : > > Hello everyone. I am working on the modularisation of > the legacy ml.clustering package to a new module: > commons-math-clustering. Some clustering classes > depend on stat.moment.Variance In the new modules, there must be no dependency towards classes in the "legacy" module. Hopefully, [Statistics] will soon (?) contain a brand-new "Variance"[1] which the new module can depend on. In the meantime, there are maybe other issues that can be tackled.[2] > and some of > the ml.distance classes. I guess that "Variance" and "Distance" are not used for the same purpose. > 1--those distances belong to geometry probably and > not machine learning. Manhattan distance, for example. For the foreseeable future, [Geometry] will only deal with 1D, 2D, 3D. I.e. physical space with a low and fixed dimension. In machine learning, the space is routinely high-dimensional and the dimension varies from problem to problem. This must be handled at runtime by the implementation(s). > 2--should I move the distance package to the new > clustering module so that they are together or create a new > commons-math-distance module? It depends on whether the distance will be useful for more than just the clustering functionality. > Or put the distance classes > in the commons-math-geometry project? No, for the reason given above. Regards, Gilles [1] https://issues.apache.org/jira/browse/STATISTICS-71 [2] 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%22cluster%22 - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: Move math algorithms from all projects to math libraries
Hello. Le mar. 18 juil. 2023 à 15:25, Dimitrios Efthymiou a écrit : > > Hi Gilles. Question about the clustering package What should happen? > Create a new module commons-math-clustering and then > literally move the code from legacy to commons-math-clustering? > Are there tickets or should I create one that explains that > we are moving the legacy clustering package to a new module? > Where is the document with the precise requirements and instructions? Let's not continue this thread with many different topics. Please post a new message for the new subject. Thanks, Gilles > > > > >> [...] - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: Is there a need for a commons-physics project?
Hello. Le mar. 18 juil. 2023 à 00:45, Paul King a écrit : > > The main issue with jscience is lack of maintenance. It was invented > around the time of JSR 275 which was ultimately rejected. The newer > "units of measurement" work is in JSR 363 and JSR 385, while the > currency/money stuff is in JSR 354. Thanks. > > Even the "units of measurement" work is a bit fragmented. If you want > to use KILOMETERS and MILES for instance, or use FEET, you have to mix > and match different libraries with the standard, and the different > libraries are all based on different vintages of the standard. It > would be nice to have a single library to be able to use. But I'd > check with the JSR folks first to see if there was an interest in > having an ASF implementation. If there is a reference implementation, why work on another? > > I wrote a blog about using these APIs with Groovy here: > > https://groovy.apache.org/blog/life-on-mars-units-of Nice. Gilles >> [...] - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [commons-io] question: file content merge sort and binary search
Hello.
Le mar. 18 juil. 2023 à 10:50, ssz a écrit :
>
> Hello there
>
> I see this issue on hold.
> So far, no one else has an opinion on this issue.
Maybe "Commons Text"?
It would help to see use-cases and API examples (in Java).
Regards,
Gilles
> I'm going to unsubscribe from this list for a while.
> Please email me directly in case of a positive final decision.
>
> sss.zuev {at} gmail / com
>
>>> [...]
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
Re: Move math algorithms from all projects to math libraries
Hello. Le mar. 18 juil. 2023 à 02:48, Dimitrios Efthymiou a écrit : > > Thanks Gilles. I checked NUMBERS-193 and i have an implementation of DD and > i will put it in *.ext package (TBD) along with some tests. Do i have to > look at Dfd.java or something, because these dfd classes in math legacy > core have lots of hard-coded decimals in there. Yes, we need to sort out what to with with the "Dfp" classes: I don't know how useful they will be once the DD implementation is available. We'll perhaps need benchmarks to assess speed vs precision among all extended precision implementations: * DD in [Numbers], * Dfp in [Math] * BigDecimal in the JDK If "Dfp" is somehow (TBD) useful, it should be moved to a module of its own, perhaps in [Numbers]. > Do these need to be copied > to DD or just implement the high/low part, add, multiply and checks for > overflows? You might want to have a look at https://issues.apache.org/jira/browse/MATH-1591 Regards, Gilles > > > [...] - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: Move math algorithms from all projects to math libraries
Le mar. 18 juil. 2023 à 00:38, Dimitrios Efthymiou a écrit : > > good to know. I also see > https://cwiki.apache.org/confluence/display/COMMONS/MathWishList > Is this page still valid. At the top: ---CUT--- Created by ASF Infrabot, last modified on Nov 01, 2013 ---CUT--- What do you think? This is a mixed bag of disparate ideas, some of which were (partly or completely) implemented, some weren't even discussed on the ML since then. The authoritative list of things to do first are those for which there is a decently recent discussion on JIRA. > I mean, could I work on one of these, like > Add further functionality for BigDecimal > <https://cwiki.apache.org/confluence/display/COMMONS/MathWishList#> and > BigInteger > <https://cwiki.apache.org/confluence/display/COMMONS/MathWishList#> > arithmetic See e.g. https://issues.apache.org/jira/browse/NUMBERS-193 Regards, Gilles > > On Mon, 17 Jul 2023 at 23:22, Gilles Sadowski wrote: > > > Le lun. 17 juil. 2023 à 20:49, Dimitrios Efthymiou > > a écrit : > > > > > > All i am saying is that if HBase has a class, say MathUtils and a method > > > add(double... numbers) and its body has the math algorithm to do > > addition, > > > we can just replace the method body with a call to the appropriate math > > > class that does addition. That's all i am saying. HBase, for example > > > already depends on math. I am not saying, change the API of HBase. Just > > > extract whatever math algorithms HBase has, put them in math (if they > > don't > > > exist there already) and call math. > > > > Only the concerned projects can tell if they would be willing > > to transfer some code to "Commons". > > > > Gilles > > > > > [...] - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: Move math algorithms from all projects to math libraries
Le lun. 17 juil. 2023 à 20:49, Dimitrios Efthymiou a écrit : > > All i am saying is that if HBase has a class, say MathUtils and a method > add(double... numbers) and its body has the math algorithm to do addition, > we can just replace the method body with a call to the appropriate math > class that does addition. That's all i am saying. HBase, for example > already depends on math. I am not saying, change the API of HBase. Just > extract whatever math algorithms HBase has, put them in math (if they don't > exist there already) and call math. Only the concerned projects can tell if they would be willing to transfer some code to "Commons". Gilles > [...] - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: Move NO algorithms from ANY projects to math libraries
Hello. Le lun. 17 juil. 2023 à 12:50, Elliotte Rusty Harold a écrit : > > There are a lot of proposals floating recently to churn the API. I'm > going to move a direct no on all of this. > > Mild improvements in consistency in no way justify any API breakage or > even deprecation. We routinely do that in every major release. Otherwise it wouldn't be a major release. > Every method and class that currently exists in any > commons library should continue to exist there with the same signature > indefinitely. It does, but in outdated (and often unsupported) older versions. Parties that want it otherwise should provide the necessary resources (e.g. to maintain older versions). > Compatibility is far more important than consistency. There has never been any (intentional) breaking of (binary) compatibility in a minor release. > Do > NOT redesign or rethink the APIs at this late date. Too much depends > on them. That depends on which component(s) you are talking about. and which versions and whether it is "beta" or not. > > New methods, classes, and packages, and projects can be added where > appropriate. Internals can be improved as possible. But what's there > today stays there, absent the very rare case where critical bugs or > security issues require breaking an API. However, that's extremely > uncommon. It has been the "Commons" policy for years. > No API will ever be perfect or free from hindsight. But the cost of > change is too high to justify breaking commons libraries. No one is forced to use the latest versions. > Stare > decisis is as valuable a principle in API design as in law. Not following the advice led to [RNG], [Numbers], [Geometry] and [Statistics], all of which could challenge previous decisions, resulting in better API, more functionality, improved performance, bugs discovery... Regards, Gilles - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: Move math algorithms from all projects to math libraries
Le lun. 17 juil. 2023 à 15:19, Dimitrios Efthymiou a écrit : > > I don't have specific functionality in mind. You mentioned ASF projects which, IIUC, you said depend on "Commons Math". So I asked: On which "Commons Math" utilities do they depend? [Last time I checked (I don't remember where or how), most were from the "stat" package).] > I just had an idea > to do a search for dependencies on java.lang.Math or BigInteger > or BigDecimal and if I find any, I would see if these dependencies > exist because the project has its own custom math algorithms. > If yes then, there you go. We have something to replace by > utilising the commons math libraries. I haven't done a > search yet. I wanted to see if the community would be OK > with new tickets (if any) for new functionality to be implemented > in the math libraries, GIVEN that there will automatically be > use-cases i.e. apache already uses those algorithms. > When I suggest new math functionality, I am always asked > what the use-cases are and I don't have any, because I just > want to implement unimplemented math algorithms. So, I thought > that this way (if I find any) there will be use-cases Yes, but if those projects don't want to depend on the new functionality, your time would be better used elsewhere. As you could read today[1], it's difficult to even share code inside the "Commons" project. For another project to delegate some functionality is much more to ask. What usually happens is the other way around; some functionality already exists somewhere, and is taken advantage of right away. For better or (and?) worse, most use-cases came from people who were using CM and needed something more, which they contributed back. Since it's "there" already, better improve it than find more things to add (if you don't have use-cases for them). Did I mention "clustering" and "genetic algorithm"? Regards, Gilles [1] https://issues.apache.org/jira/browse/IMAGING-358 > > On Mon, 17 Jul 2023 at 11:43, Gilles Sadowski wrote: > > > Le lun. 17 juil. 2023 à 02:34, Dimitrios Efthymiou > > a écrit : > > > > > > I didn't say to introduce a dependency on math. I said that libraries > > that > > > already depend on math, may have math algorithms implemented that we > > could > > > replace with a call to the appropriate commons math methods > > > > Sounds nice. > > If we could already do that just within "Commons"... (see other post). > > > > > or if math > > > doesn't have those math algorithms, we can move them to math. Flink and > > > HBase for example depend on math > > > > For which functionality? > > > > Regards, > > Gilles > > > > >> [...] - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: Is there a need for a commons-physics project?
Hi. Le lun. 17 juil. 2023 à 18:21, Thomas a écrit : > > Maybe start small, with a universally usable prerequisite: > > something like commons-unit as an implementation of javax.measure. https://github.com/javolution/jscience https://github.com/javolution/jscience/blob/master/physics/src/main/java/org/jscience/physics/unit/PhysicsUnit.java Regards, Gilles > > See: > > https://unitsofmeasurement.github.io/unit-api/site/apidocs/javax/measure/class-use/Unit.html > > | javax.measure > unit-api 1.0 > Even if not used for physics projects, it might still be very usefull > for dev-ops / JMX / SNMP measurements, and certain business > applications. Downside: there are already implementations out there. > Else, I find it extremely difficult, to select the topics addressed in > something simply called 'physics'. You might end up trying to > reimplement Mathematica with Java. | > > On 17.07.2023 03:55, Dimitrios Efthymiou wrote: > > - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: Is there a need for a commons-physics project?
Hello. Le lun. 17 juil. 2023 à 13:53, Gary Gregory a écrit : > > It might already exist in Apache Sedona. Thanks for the pointer. >From a 30 s look at the web site[1] it seems more GIS-oriented. [It might be worth comparing its features with "Commons Geometry".] Regards, Gilles [1] https://sedona.apache.org/1.4.1 >> [...] - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: Is there a need for a commons-physics project?
Short answer: No. We have had the (failed, for various reasons[1]) "Commons Math" experiment. No need to try another one with such a vague scope. Regards, Gilles [1] Cf. record of discussions in the ML archives. - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: Move math algorithms from all projects to math libraries
Le lun. 17 juil. 2023 à 02:34, Dimitrios Efthymiou a écrit : > > I didn't say to introduce a dependency on math. I said that libraries that > already depend on math, may have math algorithms implemented that we could > replace with a call to the appropriate commons math methods Sounds nice. If we could already do that just within "Commons"... (see other post). > or if math > doesn't have those math algorithms, we can move them to math. Flink and > HBase for example depend on math For which functionality? Regards, Gilles >> [...] - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: Move math algorithms from all projects to math libraries
Hi. Le lun. 17 juil. 2023 à 02:08, Gary Gregory a écrit : > > At one point, I had proposed to deprecate Commons Lang' math package in > favor of something else in Commons Math or elsewhere. Commons Lang would > NOT depend on Commons Math/Other, we would just deprecate with a forwarding > link. > > This idea was rejected IIRC because I do not think there was agreement on > where to put what. I don't recall any outright rejection, and I don't remember a conversation about code "location". String parsing in "NumberUtils" do not belong in [Numbers] but would belong to [Text] (or it would be quite fine to keep in [Lang], just weird that it is in a package called "math"...). The weirdly named "IEEE754rUtils" class contains utilities that could be moved to [Math] (or some to [Numbers] if not covered already). The third and last class is "Fraction"... > I think the Lang Fraction class for example IIRC, we indeed *agreed* to not recommend its use (cf. below). > is not a > match for the one in Math or Numbers or wherever it is. Not sure what you mean by "is not a match"; meaning "less safe" would concur with the Javadoc: ---CUT--- * Note that this class is intended for common use cases, it is int * based and thus suffers from various overflow issues. For a BigInteger based * equivalent, please see the Commons Math BigFraction class. ---CUT--- [Note: "BigFraction" is in the "commons-numbers-fraction" module in "Commons Numbers", not "Commons Math".] > > One thing to keep in mind it's OK to fill in the gaps in one component > (Math, Numbers, and so on) but that does not automatically mean that a > dependency will be introduced. For example, it would be odd for Lang or IO > to depend on Math. I totally agree with the last sentence. Inter-dependencies within "Commons" would be an interesting conversation (that has always been killed off as if "no dependency" was a virtue by itself). Within what we like to call low-level components developed here, a hierarchy could be envisioned (with a number of "steps", TBD). At the bottom, no dependency would be allowed, while at the top, dependencies towards libraries that have a strict no JAR hell policy would be allowed (e.g. Log4J2 API ?). A "Commons" component at an intermediate "step" could only depend on another "Commons" component at a lower "step" (i.e. forbidding circular dependencies). [Lang], [IO], [Numbers], [RNG] are instances that sit at the bottom. [Math] would now be at the top (several users need logging!) [Geometry] and [Statistics] depend on [Numbers] and/or [RNG] so are at a higher "step". [Imaging] would also be at an intermediate "step". Regards, Gilles > > Gary > > On Sun, Jul 16, 2023, 19:55 Dimitrios Efthymiou < > efthymiou.dimitri...@gmail.com> wrote: > > > Hello everyone. > > One thing i would love to do is to go through the apache projects, see > > which ones already depend on the math library, and see if they implement > > some math stuff that could be replaced by a call to commons math or move > > that function to the math library. Would such cases be considered valid for > > implementing new math algorithms inside the math libraries? I don't think i > > have seen any ticket that wants to implement new math algorithms. > > > > Thank you > > - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [statistics] move code from math4.stat.regression to commons-statistics-regression
Hello. Le sam. 15 juil. 2023 à 22:18, Dimitrios Efthymiou a écrit : > > hello everyone. I noticed that the common-statistics-regression module > has no code. Work started as a GSoC project 4 years ago (see e.g. [1]) but code did not reach a state where it could be committed. > Does that mean that we should start moving classes from > \commons-math\commons-math-legacy\src\main\java\org\apache\commons\math4\legacy\stat\ > regression > to > \commons-statistics\commons-statistics-descriptive\src\main\java\org\apache\commons\statistics\ > regression ? Sure, you can do it in your local copy and start experimenting, but I'd suggest to do it "incrementally" (discuss and agree on the new design before making any PR). Regards, Gilles [1] https://issues.apache.org/jira/browse/STATISTICS-11 - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [statistics] move code from math4.stat to commons-statistics
Hello. Le sam. 15 juil. 2023 à 22:15, Dimitrios Efthymiou a écrit : > > hello everyone. I noticed that the common-statistics-descriptive module > has no code. Does that mean that we should start moving classes from > \commons-math\commons-math-legacy\src\main\java\org\apache\commons\math4\legacy\stat\descriptive > to > \commons-statistics\commons-statistics-descriptive\src\main\java\org\apache\commons\statistics\descriptive? Anirudh works on adding functionality[1] to the "descriptive" module as part of GSoC 2023. Most the communication about this happens (unfortunately) on a "Slack" channel. [Hopefully, Anirudh will reply to this post and provide an update on the current status.] Regards, Gilles [1] https://issues.apache.org/jira/browse/STATISTICS-71 - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [math] refactoring math4
Hello. Le ven. 14 juil. 2023 à 16:15, Dimitrios Efthymiou a écrit : > > Hello devs. I need a little help. > > 1--Say that I want to implement a new feature/function that, technically > exists in the math4 or legacy, but it doesn't exist in commons- geometry or > commons- numbers. What is the protocol? Do we create a ticket on math4 and > put the new code in math4 and ignore the geometry/numbers projects? If it's in the [Math] component, but some rationale can be found that it should be in one of the other (newer) components ([RNG], [Geometry], [Numbers], [Statistics]), then it should be ported there (once done, the functionality is removed from [Math]). The underlying principle is that the newer components are more focused (than [Math]), so that a contributor interested in that subject matter is more likely to be able to help clean up all the issues that block the next release As you can see, there are many long-standing issues in [Math] because it covers many subjects, and no one is sufficiently interested in everything (or has enough time) to do the necessary refactoring. If the feature is in "legacy", but is part of larger "subject matter" which a refactoring could implement in a modular way (reducing dependencies and removing circular ones), the new package should be moved to a (maven) module of its own. [That has been done already for several packages for which it was relatively straightforward (because they were not involved in circular dependencies).] As I've already suggested, the next task on that list would be to refactor, fix and move the "clustering" functionality (adding documentation, and JMH benchmarks along the way). Another pending task is the refactoring of the "genetics" package. [See the associated JIRA reports. There is also a long ML thread about it (cf. "dev" ML archive).] > > 2--Can contributors remove code from math4 and move it to the other new > math projects? Sure. In practice, we can do it now because we released a "beta" version of 4.0; hence we allow ourselves to break compatibility until the a non-beta version is released. > I see in GitHub for commons-math it says: "Functionality > still within "Commons Math" is gradually being modularized and refactored". > Is there documentation that explains the precise way math4 should be > refactored and modularised and who is allowed to even touch math4 and move > functionality out of the library? You can do whatever you want with your copy/clone of the repository. Of course, as you noticed, the issue is to have a committer agree to merge your changes back to the ASF's copy. Prior discussion avoids people doing useless work (although sometimes, no agreement could be found a priori, yet a developer might wish to do the work anyway; that's how the [RNG] component got started). > > 3–Are the math-related projects (like numbers and geometry) final? The math-related (so called because they were initially comprising refactored code ported from [Math]) components are * [RNG] (main maintainer: Alex) * [Numbers] (main maintainer: Alex) * [Statistics] (main maintainer: Alex) * [Geometry] (main maintainer: Matt) The PMC did not agree to create more [Math] spin-offs. So, the second best option was to modularize [Math]. Perhaps in the future, some modules will grow sufficiently so as to be worthy of their own component... > For > example, where is calculus gonna go? In a module within [Math] (provided it does not enter in a dependency loop with other modules). > Is there gonna be a new project like > commons-calculus? Same question for other math theories. Currently: No (reason given above). > > 4--Are the submodules of the numbers and geometry projects final? Geometry > has the commons-geometry-euclidean module and a few more. Will there be new > modules added to the math-related projects, as time passes? Sure (by definition, it's the goal of modularization), as long as the new modules stay within the component's scope. Of course, there are practical conditions to creating a new module. Some are pretty straightforward: Thorough documentation, same programming style as the rest of the code base, full coverage by (Junit) unit tests, JMH benchmarks (if departing from an existing implementation). Some are more vague, like avoiding that the component becomes the receptacle of code which no one wants to maintain. Regards, Gilles - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: Are any of these types of projects needed?
Hi.
Le ven. 14 juil. 2023 à 03:20, Dimitrios Efthymiou
a écrit :
>
> The intended audience is the devs on this maillist.
People on this ML are mostly the developers of the Commons components:
https://commons.apache.org
> It is like market
> research to get the pulse of the community on these ideas to see if there
> is at least one that I could apply for in the incubator.
Do you mean the ASF incubator:
https://incubator.apache.org/cookbook/
?
If so, your first step would be to browse the ASF projects:
https://www.apache.org/index.html#projects-list
in order to find which ones that target the fairly specific
domains in your list.
If you mean to work on a "Commons" component, there are
different approaches, depending on whether the component
is "active" or in the "sandbox" (like "Graph").
For active components, development is usually incremental
and within the current "roadmap" (though it is often implicit).
>
> No, i am not working on all of these. I just presented ideas so that I get
> some feedback. Maybe some people will say: "yes, an open source java-based
> eCommerce platform will be in demand", you know?
No, you won't get that kind of feedback on this ML.
> Same with the other emails
> about math functions. Maybe some people from math or non-math commons
> libraries may point out that they would need some of those functions.
It might seem so, but it is not; if you on the one hand, you list the
"functions"
out of context ("use case"), and on the other you list either large
domains (like
"quantum computing", or "physics"!), there is an enormous "gap"...
Most "Commons" components are domain-agnostic but (each) focused on
specific kinds of utilities (like "collections", "file compression", "image file
formats", "random number generators", ...). You have to fill the "gap" by
finding out where in those components, your contributions would find a
"natural" home.
"Commons Math" is probably the least "focused" component; it was a main
reason for the "spin-off" components. Modularization is a big ongoing task
(cf. release notes of CM v4.0-beta1) for which help is welcome.
>
> Lastly, are there any math libraries that do symbolic math using functional
> interfaces? For example can I use commons math to give it a function that
> represents x^2, differentiate it and as a result get another function that
> represents 2x? I am talking about symbolic math that Wolfram Mathematica
> does.
As I noted in a previous email, there is some related functionality in
package "o.a.c.math4.legacy.differentiation". As said, it would be great
to have this code refactored, providing an easier API (there was a JIRA
report about it, IIRC) and moved to its own module.
>
> Thank you for the time you spent on going through the emails. I did some
> pull requests implementing some things and they kept being rejected. So, (i
> think it was you that suggested it) to ask the community which math
> functions they would like to see implemented
Sorry if it was not clear; there is some misunderstanding which the above
has hopefully clarified.
Here, the "community" is mainly "those who do the work". So, as Alex
wrote: "you develop code that you will use". However, you can also help
by improving things that were identified as problematic (like the lack of
modularization in the "legacy" packages of CM or any bug reported on
JIRA).
Regards,
Gilles
>
>>> [...]
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
Re: Are any of these types of projects needed?
Dimitrios, As requested several times, could you please add the "component" prefix to the "Subject: " line, to signal to the intended audience? What's the purpose of the list below? Are you developing all of those applications? Regards, Gilles Le ven. 14 juil. 2023 à 02:54, Dimitrios Efthymiou a écrit : > > Java-based ECommerce platform > > Graph and network theory library > > Operations research or management science or mathematical programming > library > > Calendar library with many useful methods that the java datetime API > doesn't provide off-the-shelf > > Finance library including financial engineering > > User management (not apache shiro) i.e. account management, 2-factor auth, > forgot/reset password, security questions and more > > Web utilities from cookie service to device recognition to email service > and more > > Image manipulation library > > Parallelism library for CPU and GPU parallelism > > Quantum computing library > > AdminTool platform. Imagine grafana, but with a lot of prebuilt and > extensible tools > > Physics library > > Client SDK builder by taking API specs and generating java SDKs, JavaScript > SDKs, python etc. > > Transformer of MySQL data to MongoDB and vice-versa. Same for other kinds > of databases > > Blockchain library > > Query Profiling Plugin: A plugin that tracks and logs all database queries > that are executed by the application. It could highlight inefficient > queries, and also track and display query execution times. > > Health Check Plugin: A plugin to perform various health checks on the > application and its dependencies, such as checking database connectivity, > ensuring required services are running, checking disk space, etc. This > plugin can expose health check endpoints that return the status of your > application and its dependencies. This can be useful for monitoring and > automated deployment scenarios. > > Scheduled Tasks Monitoring Plugin: This plugin could provide a unified view > of all the scheduled tasks in your application and provide information like > when each task last ran, whether it completed successfully, and when it's > due to run next. > > Event Sourcing Plugin: A plugin that makes it easier to implement the event > sourcing pattern in a Spring application. It would help manage the event > store and the rehydration of application state from events. > > Application Metadata Plugin: A plugin that generates and exposes metadata > about the application, like the version number, build date, list of active > profiles, etc. > > Data Integrity Plugin: A plugin that helps ensure data integrity by > checking for anomalies such as orphaned records, duplicate entries, etc. > > Test Data Generation Plugin: This plugin could auto-generate test data for > unit and integration tests, using predefined rules to ensure the data is > meaningful and useful for testing. > > Telemetry Filter: A filter that collects telemetry data such as request > counts, error counts, and more, which can be useful for monitoring and > diagnostics. - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
[Math (?)] Re: [batch8] is there a need for any of these functions?
Le ven. 14 juil. 2023 à 01:36, Dimitrios Efthymiou a écrit : > > getUnion(Set other) Why is it limited to the "ANumber" type? Again, the question is: Which kinds of applications would find it handy that this functionality is provided by the "Commons" project? > getIntersection(Set other) > getDifference(Set other) > getSymmetricDifference(Set other) > isSubset(Set other) > isProperSubset(Set other) > getTruthSetFor(Predicate filterToApply) > getSizeOfPowerset() > getPowerset() > isDisjointTo(Set other) > getComplementRelativeTo(Set other) > getCardinality() > getMinimum() > getMaximum() > isBounded() > getNumberOfSubsetsTheSetHas() > getNumberOfDerangements() > > > multiset functions - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
[Math] Re: [batch7] is there a need for any of these functions?
For matrix-related functionality, see the "o.a.c.math4.legacy.linear" package in "Commons Math". As noted, it's "legacy" and up for refactoring (but note that several other packages depend on it). [See also the JIRA reports about it.] Le ven. 14 juil. 2023 à 01:35, Dimitrios Efthymiou a écrit : > > getNumberOfNonZeroDiagonalElements(Matrix x) > getDiagonal(Matrix x) > getRank(Matrix x) > getSubmatrix(Matrix x, int fromRow, int toRow, int fromColumn, int toColumn) > negate(Matrix x) > isZeroMatrix(Matrix x) > isIdentityMatrix(Matrix x) > > > getUpperTriangularPart(Matrix x) > getLowerTriangularPart(Matrix x) > > > swapRows(Matrix x, int row1, int row2) > swapColumns(Matrix x, int column1, int column2) > > > exponentiate(Matrix x, int exponent) > getExponentForMatrixToBeNilpotent(Matrix x) > > > augmentWith(Matrix x, Vector y) > > > isSingular(Matrix x) > isInvertible(Matrix x) > isSymmetric(Matrix x) > isSkewSymmetric(Matrix x) > isAntiSymmetric(Matrix x) > isOrthogonal(Matrix x) > isUnitary(Matrix x) > isNormal(Matrix x) > isHermitian(Matrix x) > isAntihermitian(Matrix x) > isBinary(Matrix x) > isCMatrix(Matrix x) > isIntegerMatrix(Matrix x) > isSpecialMatrix(Matrix x) > isUnitMatrix(Matrix x) > isCompatibleWith(Matrix x, Vector vector) > isCentrosymmetric(Matrix x) > isBisymmetric(Matrix x) > isCirculantMatrix(Matrix x) > isCommutativeWith(Matrix x, Matrix other) > isCoxeterMatrix(Matrix x) > isDiagonallyDominant(Matrix x) > isDoublyStochastic(Matrix x) > isFibonacciQMatrix(Matrix x) > isUpperHessenbergMatrix(Matrix x) > isLowerHessenbergMatrix(Matrix x) > isHessenbergMatrix(Matrix x) > isHankelMatrix(Matrix x) > isHilbertMatrix(Matrix x) > isInvolutoryMatrix(Matrix x) > isJordanBlock(Matrix x) > isKMatrix(Matrix x) > isKacMatrix(Matrix x) > isClementMatrix(Matrix x) > isMonotonicMatrix(Matrix x) > isPeriodicMatrix(Matrix x) > getMatrixPeriod(Matrix x) > isSquareMatrix(Matrix x) > isRectangularMatrix(Matrix x) > isRedhefferMatrix(Matrix x) > isScalarMatrix(Matrix x) > isSpecialOrthogonalMatrix(Matrix x) > isSpecialUnitaryMatrix(Matrix x) > isStochasticMatrix(Matrix x) > isRightStochasticMatrix(Matrix x) > isLeftStochasticMatrix(Matrix x) > isTriangularMatrix(Matrix x) > isTridiagonalMatrix(Matrix x) > isUnimodularMatrix(Matrix x) > isVandermondeMatrix(Matrix x) > > > getConjugateTranspose(Matrix x) > > > getAdjoint(Matrix x) > isSelfAdjoint(Matrix x) > > > getTrace(Matrix x) > > > getInverse(Matrix x) > > > getCondition(Matrix x) > > > rotate90DegreesClockwise(Matrix x) > > > getCumulativeSumForRows(Matrix x) > getCumulativeSumForColumns(Matrix x) > getCumulativeProductForRows(Matrix x) > getCumulativeProductForColumns(Matrix x) > > > getDifferencesBetweenSuccessiveRowElements(Matrix x) > getDifferencesBetweenSuccessiveColumnElements(Matrix x) > > > getMinor(Matrix x, int rowToExclude, int columnToExclude) > > > getBandwidth(Matrix x) > > > getHadamartMatrix(int order) > > > normalise(Matrix x) > > > normaliseFrom0To1(Matrix x) > > > ArithmeticProgressionSequence > GeometricProgressionSequence > FibonacciSequence > other sequence functions - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
[Graph] Re: [batch6] is there a need for any of these functions?
As I've already indicated, there is a "Graph" component that never got traction: https://commons.apache.org/sandbox/commons-graph/ Please have a look and if you want to revive it, you should make a proposal starting from that (even if just to expose shortcomings which you may have identified and which you'd propose to fix). Le ven. 14 juil. 2023 à 01:35, Dimitrios Efthymiou a écrit : > > getOrder(Graph graph) > > > getAllPossibleEdges(Graph graph) > > > getAllPossibleEdgesBetween(Graph graph, Graph other) > > > isTrivial(Graph graph) > > > areAdjacent(Graph graph, Vertex v1, Vertex v2) > > > isComplete(Graph graph) > > > getUnion(Graph graph, Graph other) > > > getIntersection(Graph graph, Graph other) > > > isDisjointWith(Graph graph, Graph other) > > > isSubgraphOf(Graph graph, Graph other) > > > isSupergraphOf(Graph graph, Graph other) > > > contains(Graph graph, Graph other) > > > isInducedSubgraphOf(Graph graph, Graph other) > > > doesGraphInduce(Graph graph, Graph other) > > > doesGraphSpan(Graph graph, Graph other) > > > isSpanningSubgraphOf(Graph graph, Graph other) > > > subtract(Graph graph, Vertex[] verticesToDelete) > > > subtractEdges(Graph graph, Edge[] edgesToDelete) > > > getComplement(Graph graph) > > > joinVerticesToVerticesOf(Graph graph, Graph other) > > > getNeighbourVerticesOf(Graph graph, Vertex vertex) > > > getNeighbourEdgesOf(Graph graph, Vertex vertex) > > > getNeighbourhoodOf(Graph graph, Vertex vertex) > > > getDegreeOf(Graph graph, Vertex vertex) > > > isVertexIsolated(Graph graph, Vertex vertex) > > > getDegrees(Graph graph) > > > getIndegrees(Graph graph) > > > getOutdegrees(Graph graph) > > > getIndegreeOf(Graph graph, Vertex vertex) > > > getOutdegreeOf(Graph graph, Vertex vertex) > > > getMinimumDegree(Graph graph) > > > getMinimumIndegree(Graph graph) > > > getMinimumOutdegree(Graph graph) > > > getMaximumDegree(Graph graph) > > > getMaximumIndegree(Graph graph) > > > getMaximumOutdegree(Graph graph) > > > getAverageDegree(Graph graph) > > > getAverageIndegree(Graph graph) > > > getAverageOutdegree(Graph graph) > > > isRegular(Graph graph) > > > containsVertex(Graph graph, Vertex vertex) > > > containsEdge(Graph graph, Edge edge) > > > getEdgesThatIncludeVertex(Graph graph, Vertex vertex) > > > getEdgesThatIncludeVertexAsFirst(Graph graph, Vertex vertex) > > > getEdgesThatIncludeVertexAsSecond(Graph graph, Vertex vertex) > > > getCycles(Graph graph) > > > getGirth(Graph graph) > > > getCircumference(Graph graph) > > > getPathsBetween(Graph graph, Vertex v1, Vertex v2) > > > getNumberOfPathsBetween(Graph graph, Vertex v1, Vertex v2) > > > getDistanceBetween(Graph graph, Vertex v1, Vertex v2) > > > getLargestDistanceBetween(Graph graph, Vertex v1, Vertex v2) > > > getDiameter(Graph graph) > > > get2VerticesWithDistance(Graph graph, ANumber distance) > > > get2VerticesWithDistanceAtLeast(Graph graph, ANumber distance) > > > get2VerticesWithDistanceLessThan(Graph graph, ANumber distance) > > > get2VerticesWithDistanceLessThanOrEqualTo(Graph graph, ANumber distance) > > > getEccentricityOfVertex(Graph graph, Vertex vertex) > > > getCentralVertices(Graph graph) > > > isVertexCentral(Graph graph, Vertex vertex) > > > getRadius(Graph graph) > > > getVerticesWithGivenDistanceFromVertex(Graph graph, ANumber distance, > Vertex vertex) > > > getVerticesWithDistanceFromVertexLessThanGivenDistance(Graph graph, ANumber > distance, Vertex vertex) > > > getVerticesWithDistanceFromVertexLessThanOrEqualToGivenDistance(Graph > graph, ANumber distance, Vertex vertex) > > > getVerticesWithDistanceFromVertexGreaterThanGivenDistance(Graph graph, > ANumber distance, Vertex vertex) > > > getVerticesWithDistanceFromVertexGreaterThanOrEqualToGivenDistance(Graph > graph, ANumber distance, Vertex vertex) > > > isTherePathBetween(Graph graph, Vertex v1, Vertex v2) > > > isConnected(Graph graph) > isKConnected(Graph graph, ANumber k) > > > isComponent(Graph graph, Graph subgraph) > > > getAllPossibleSubgraphs(Graph graph) > > > getComponents(Graph graph) > > > isCutvertex(Graph graph, Graph component, Vertex vertex) > getCutvertices(Graph graph) > > > isBridge(Graph graph, Graph component, Edge edge) > getBridges(Graph graph) > > > getConnectivity(Graph graph) > getEdgeConnectivity(Graph graph) > > > isLEdgeConnected(Graph graph, ANumber l) > > > getNumberOfCycles(Graph graph) > isAcyclic(Graph graph) > > > isForest(Graph graph) > isTree(Graph graph) > isBipartite(Graph graph) > isEulerian(Graph graph) > isSimpleGraph(Graph graph) > isMultigraph(Graph graph) > isPseudograph(Graph graph) > > > contractEdge(Graph graph, Edge edge) > > > doEdgesBelongToCycleSpace(Graph graph, OrionSet edges) > > > getDimensionsOfCycleSpace(Graph graph) > getDimensionsOfCutSpace(Graph graph) > > > getNumberOfEdgesThatInclude(Graph graph, Vertex v1, Vertex v2) > > > areAdjacentByMultipleEdges(Graph graph, Vertex v1, Vertex v2) > > > getEdgesThatInclude(Graph graph, Vertex v1, Vertex v2) > > > getNumberOfLoops(Graph
[Numbers] Re: [batch5] is there a need for any of these functions?
Le ven. 14 juil. 2023 à 01:34, Dimitrios Efthymiou a écrit : > > convertDegreesToRadians(Number x) > See "angle" module in "Commons Numbers". > > convertRadiansToDegrees(Number x) > > > normaliseRadians(Number x) > > > isEquivalentTo(Vector x, Vector y) Component "Commons Geometry" defines and _uses_ "vectors". Perhaps some of the functionality below can find a place there (or exists already)... > > > multiplyComponentWise(Vector x, Vector y) > > > normalise(Vector x) > > > translate(Vector x, Number translationLength) > > > reverseDirection(Vector x) > > > getDisplacementVector(Point point1, Point point2) > > > getBasisVector(int dimensions, Axis axis) > > > getVectorComponent(Vector x, Axis axis) > > > getVectorComponents(Vector x) > > > getCosineWithXAxis(Vector x) > > > getCosineWithAxis(Vector x, Axis axis) > > > getAngleWithVector(Vector x, Vector y) > > > getAngleWithXAxis(Vector x) > > > getAngleWithAxis(Vector x, Axis axis) > > > isPerpendicularTo(Vector x, Vector y) > > > isParallelTo(Vector x, Vector y) > > > getLengthOfProjectionOntoVector(Vector x, Vector y) > > > getProjectionOntoVector(Vector x, Vector y) > > > getTripleScalarProduct(Vector x, Vector y, Vector z) > > > getDistanceFrom(Vector x, Vector y) > > > getStandardBasis(int dimensions) > > > isCodirectionalTo(Vector x, Vector y) > > > isAntidirectionalTo(Vector x, Vector y) > > > getEqualVectorBasedOnPoint(Vector x, Point point) > > > areVectorsLinearlyDependent(List vectors) > > > areVectorsLinearlyIndependent(List vectors) > > > isOrthonormalTo(Vector x, Vector y) > > > areVectorsOrthonormal(List vectors) > > > isPointBetweenVectorEndPoints(Vector x, Point point) > > > divideVectorWithRatio(Vector x, Number ratio) > > > getMidpoint(Vector x) > > > convertToMatrix(Vector x) > > > getLengthOfLongestIncreasingSubsequence(Vector x) > > > getLengthOfLongestDecreasingSubsequence(Vector x) > > > getLengthOfLongestStableSubsequence(Vector x) > > > getFirstIndexOfMinimum(Vector x) > > > getLastIndexOfMinimum(Vector x) > > > getFirstIndexOfMaximum(Vector x) > > > getLastIndexOfMaximum(Vector x) > > > getCumulativeSum(Vector x) > > > getCumulativeProduct(Vector x) > > > getReverseCumulativeSum(Vector x) > > > getReverseCumulativeProduct(Vector x) > > > getDifferencesBetweenSuccessiveElements(Vector x) > > > areAtEquilibrium(Vector... vectors) > > > sortAndMapTogether(Vector x, Vector y) > > > normaliseFrom0To1(Vector x) > > > flattenVectors(List vectors) > > > getTheFirstNLargestElementsSorted(Vector x, int n) > > > getTheFirstNSmallestElementsSorted(Vector x, int n) > > > getIndicesOfOccurenceOfElement(Vector x, ANumber element) - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
[Math][Numbers] Re: [batch3] is there a need for any of these functions?
More pointers below. Note: All code in the "legacy" packages of "Commons Math" are candidates for refactoring. The result should end up into a (maven) module of its own with a minimal number of dependencies (and no circular dependencies). Le ven. 14 juil. 2023 à 01:32, Dimitrios Efthymiou a écrit : > > public static Function1x1 differentiate(Function1x1 f) i.e. > take x^2 and return the function 2x, not 2x(x0) > public static Function1x1 differentiate(Function1x1 f, int > orderOfDerivative) i.e. take x^3 and return the function 6x, not 6x(x0) > public static Function2x1 > getPartialDerivativeOnX(Function2x1 f) i..e take x^2 + 4y and return the > function 2x + 4y > public static Function2x1 > getPartialDerivativeOnY(Function2x1 f) i..e take x^2 + 4y and return the > function x^2 + 4 See package "o.a.c.math4.legacy.analysis.differentiation". > SolveFirstOrderOrdinaryDifferentialEquationUsingEulerMethod See package "o.a.c.math4.legacy.ode". > > > getNumberOfCombinationsWithElementRepetition(Number n, Number r) > GetPascalTriangle > GetStirlingNumberOfFirstKind > getStirlingNumberOfSecondKind > etNumberOfOrderedSelections(Number numberOfItems, Number > sizeOfEachSelection) > getNumberOfWaysToChooseWithReplacementInAnyOrder(Number numberOfItems, > Number sizeOfEachSelection) > getNumberOfMPartCompositionsOfN(Number n, Number m) > GetNumberOfCompositionsOfN > GetExtendedBinomialCoefficient Some of this could belong to module "combinatorics" (in component "Commons Numbers"). > > > getError(Number realValue, Number approximateValue) > getAbsoluteError(Number realValue, Number approximateValue) > getRelativeError(Number realValue, Number approximateValue) > getPercentError(Number realValue, Number approximateValue) > getErrorSquared(Number realValue, Number approximateValue) > getSumOfSquaredErrors(Vector realValues, Vector approximateValues) > getMeanSquaredError(Vector realValues, Vector approximateValues) > Related (?) to the upcoming module "descriptive" (in component "Commons Statistics"). > > PolynomialFunction object using Java util functions See package "o.a.c.math4.legacy.polynomials" in "Commons Math". > > Function object using Java util functions that can represent any function > and do symbolic math on it - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
[Math][Geometry] Re: [batch4] is there a need for any of these functions?
Le ven. 14 juil. 2023 à 01:34, Dimitrios Efthymiou a écrit : > > getNumberOfParallelogramsFormedByPoints(Point[] points) > > > getMinimumNumberOfLinesThatGoThroughPoints(Point > pointAllLinesToPassThrough, Point[] points) Maybe to be added somewhere in "Commons Geometry"... > > getManhattanDistance(Point point1, Point point2) See package "o.a.c.math4.legacy.ml.distance". > > getNumberOfHorizontalOrVerticalLineSegmentsToConnectPoints(Point point1, > Point point2, Point point3) Although the name is verbose, I don't get it. Please provide context. > > getMinimumDistanceBetweenLineAndPointIn3D(Point linePoint1, Point > linePoint2, Point point) See "Commons Geometry". Whether it already provides any of the functionality listed below, or it misses, you have to help figuring it out. Again, rather than listing functions, could you group functionality by topic? Whenever possible, we favour OO design. > > getAreaOfParallelogramGiven2AdjacentSides(Vector x, Vector y) > > > getDistanceFromPoint(Plane plane, Point point) > > > getAngleWithPlane(Plane x, Plane other) > > > isPlaneParallelTo(Plane x, Plane other) > > > getDistanceFromParallelPlane(Plane x, Plane other) > > > areCoplanar(Point... points) > > > getFootOfPerpendicularLineFromPoint(Plane x, Point point) > > > arePointsCollinear(Point... points) > > > arePointsCoplanar(Point... points) > > > getClosestPairOfPoints(Point[] points) > > > getDistanceOfClosestPairOfPoints(Point[] points) > > > getFarthestPairOfPoints(Point[] points) > > > getOrientation(Point p, Point q, Point r) > > > getNumberOfLatticePointsBetween(Point p, Point other) > > > getNumberOfLatticePointsBetweenIncludingGivenPoints(Point p, Point other) > > > getNumberOfIntegralPointsBetween(Point p, Point other) > > > getNumberOfIntegralPointsBetweenIncludingGivenPoints(Point p, Point other) > > > reflectAboutALineSegment(Point p, LineSegment lineSegment) > > > reflectAboutALine(Point p, Line line) > > > translate(Point p, Number x) > > > getDistanceFromLine(Point p, Line line) > > > doesPointLieOnTheLeftOfLineSegment(Point point, LineSegment lineSegment) > > > doesPointLieOnTheRightOfLineSegment(Point point, LineSegment lineSegment) > > > reflectAboutAPlane(Point point, Plane plane) > > > getHammeredDistanceBetweenPoints(Point... points) > > > getCircumference(Circle x) > > > getArea(Circle x) > > > isPointInsideCircle(Circle x, Point other) > > > isPointOnCircle(Circle x, Point other) > > > getNumberOfLatticePoints(Circle x) > > > getPositiveYBasedOnX(Circle circle, Number x) > > > getNegativeYBasedOnX(Circle circle, Number x) > > > getAngleAsRadiansBetween(Circle x, Point startPoint, Point endPoint) > > > getCirclePointBasedOn(Circle x, Point startPoint, Number angle) > > > getNumberOfAreasBasedOnNumberOfCuts(Number cuts) > > > isLineTangentToCircle(Circle x, Line line) > > > doesLineIntersectCircle(Circle x, Line line) > > > isLineTangent(Circle x, Line line) > > > isLineSecant(Circle x, Line line) > > > getAreaOfMinorSegment(Circle x, CircleChord chord) > > > getAreaOfMajorSegment(Circle x, CircleChord chord) > > > doCirclesIntersect(Circle x, Circle other) > > > getTangentLineOnPoint(Circle x, Point point) > > > getCircleThatEnclosesPoints(List points) > > > getArcLength(CircleArc arc) > > > isPointOnArc(CircleArc arc, Point point) > > > getAreaFormedByArc(CircleArc arc) > > > getChordLength(CircleChord chord) > > > isPointOnChord(CircleChord chord, Point point) > > > isDiameter(CircleChord chord) > > > getSurfaceArea(Cube x) > > > getVolume(Cube x) > > > getFaceDiagonal(Cube x) > > > getSpaceDiagonal(Cube x) > > > getCylinderSurfaceArea(Cylinder x) > > > getCylinderVolume(Cylinder x) > > > isMajorAxisParallelToXAxis(Ellipse x) > > > getEllipseArea(Ellipse x) > > > getEllipseCircumference(Ellipse x) > > > getDistanceFromPoint(Line line, Point point) > > > doesIntersect(Line x, Line other) > > > getIntersectionPoint(Line x, Line other) > > > getPointThatMinimisesSumOfdistancesFromPointsToLine(Line x, Point[] points) > > > getPointThatMinimisesSumOfdistancesFromPointsToLine(Line x, Point[] points, > int precision) > > > getLineThatBestFitsPoints(List points) > > > isLineParallelTo(Line x, Line other) > > > isLineVerticalTo(Line x, Line other) > > > isLineTangentToCircle(Line x, Circle circle) > > > doesLineIntersectCircle(Line x, Circle circle) > > > isPointInsidePolygon(Polygon polygon, Point point) > > > getConvexHull(Point[] points) > > > getMinimumCostOfTriangulation(Polygon polygon) > > > getPolygonPerimeter(Polygon polygon) > > > getPolygonArea(Polygon polygon) > > > getPerimeter(Rectangle x) > > > getArea(Rectangle x) > > > isPointInsideRectangle(Rectangle x, Point other) > > > isPointOnRectangle(Rectangle x, Point other) > > > doesRectangleOverlapWith(Rectangle x, Rectangle other) > > > getRectangleCornerPointsUsing4LineSegments(LineSegment s1, LineSegment s2, > LineSegment s3, LineSegment s4) > > > doLineSegmentsFormRectangle(LineSegment s1, LineSegment s2, LineSegment s3,
[Numbers][Math] Re: [batch2] is there a need for any of these functions?
Hi. [Note the addition of a prefix to the "Subject:" line; this ML is shared by some 30+ components.] Did you have a look at what the math-related components already provide? [Some pointers below.] Please group your proposals by topic. Le ven. 14 juil. 2023 à 01:32, Dimitrios Efthymiou a écrit : > > DivideAndRemainder which returns a pair of quotient and remainder > > > GetSineInDegrees which converts the input from radians to degrees and then > does Math.sin(x) > GetCosineInDegrees which converts the input from radians to degrees and > then does Math.cos(x) > GetTangentInDegrees which converts the input from radians to degrees and > then does Math.tan(x) See "angle" module in Commons Numbers. > > GetNthRoot of an integer See "complex" module in Commons Numbers. > > GetNeperianLogarithm JDK: Math.log(double x) > > > Exponentiate(x, y) which is x^y where x and y can be any combination of > int, long, double, Complex, etc. > See "complex" module. > > GetPowerOf2GreaterOrEqualTo(x) i.e. SomePowerOf2 >= x > > > GetSumOfDigits > > > GetSumOfSquares(List numbers) > > > public static Number[] GetCumulativeSum(Number[] numbers) > > > public static Number[] GetCumulativeSumOfSquares(Number[] numbers) > > > AddNumbersWithWeightsTask i.e. > double sum = 0.0d; > IntStream.range(0, numbers.size()).forEach(i -> sum + (numbers.get(i) * > weights.get(i))); > > > GetEToThePowerOf i.e. e^x JDK: Math.exp(double x) > > GetIntegralRoot > > > GetJordanProduct > > > GetWeightedArithmeticAverage(List numbers, List weights) > > > GetGeometricAverage > > > GetHarmonicAverage > > > GetQuadraticAverage > There is some development going on with a GSoC contributor working on descriptive statistics. See https://issues.apache.org/jira/browse/STATISTICS-54 > interval arithmetic (part of computational mathematics) - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [commons-lang] 04/04: Throw IllegalArgumentException instead of InternalError in the builder package
Hi.
Le mer. 12 juil. 2023 à 14:44, a écrit :
>
> This is an automated email from the ASF dual-hosted git repository.
>
> ggregory pushed a commit to branch master
> in repository https://gitbox.apache.org/repos/asf/commons-lang.git
>
> commit 2e3feda04337baa483bc26b66f238161dc6c97ac
> Author: Gary Gregory
> AuthorDate: Wed Jul 12 08:44:38 2023 -0400
>
> Throw IllegalArgumentException instead of InternalError in the builder
> package
The diff below contains a bunch of (formatting ?) changes that
have nothing to do with this commit message.
Regards,
Gilles
> ---
> src/changes/changes.xml| 1 +
> .../commons/lang3/builder/CompareToBuilder.java| 752
> ++---
> .../commons/lang3/builder/EqualsBuilder.java | 20 +-
> .../commons/lang3/builder/HashCodeBuilder.java | 9 +-
> .../apache/commons/lang3/builder/Reflection.java | 44 ++
> .../lang3/builder/ReflectionDiffBuilder.java | 7 +-
> .../lang3/builder/ReflectionToStringBuilder.java | 14 +-
> 7 files changed, 434 insertions(+), 413 deletions(-)
>
> diff --git a/src/changes/changes.xml b/src/changes/changes.xml
> index 26d7be48c..da3522029 100644
> --- a/src/changes/changes.xml
> +++ b/src/changes/changes.xml
> @@ -123,6 +123,7 @@ The type attribute can be add,update,fix,remove.
> Update Javadoc for the insert methods in ArrayUtils #1078.
> Deprecate ExceptionUtils.ExceptionUtils().
> TypeUtils.getRawType() throws a NullPointerException on
> Wildcard GenericArrayType.
> +Throw IllegalArgumentException instead of InternalError in the
> builder package.
>
> Add GitHub coverage.yml.
> Add EnumUtils.getEnumSystemProperty(...).
> diff --git
> a/src/main/java/org/apache/commons/lang3/builder/CompareToBuilder.java
> b/src/main/java/org/apache/commons/lang3/builder/CompareToBuilder.java
> index 38c69e613..3d411bb15 100644
> --- a/src/main/java/org/apache/commons/lang3/builder/CompareToBuilder.java
> +++ b/src/main/java/org/apache/commons/lang3/builder/CompareToBuilder.java
> @@ -97,19 +97,37 @@ import org.apache.commons.lang3.ObjectUtils;
> public class CompareToBuilder implements Builder {
>
> /**
> - * Current state of the comparison as appended fields are checked.
> - */
> -private int comparison;
> -
> -/**
> - * Constructor for CompareToBuilder.
> + * Appends to {@code builder} the comparison of {@code lhs}
> + * to {@code rhs} using the fields defined in {@code clazz}.
> *
> - * Starts off assuming that the objects are equal. Multiple calls are
> - * then made to the various append methods, followed by a call to
> - * {@link #toComparison} to get the result.
> + * @param lhs left-hand object
> + * @param rhs right-hand object
> + * @param clazz {@link Class} that defines fields to be compared
> + * @param builder {@link CompareToBuilder} to append to
> + * @param useTransients whether to compare transient fields
> + * @param excludeFields fields to exclude
> */
> -public CompareToBuilder() {
> -comparison = 0;
> +private static void reflectionAppend(
> +final Object lhs,
> +final Object rhs,
> +final Class clazz,
> +final CompareToBuilder builder,
> +final boolean useTransients,
> +final String[] excludeFields) {
> +
> +final Field[] fields = clazz.getDeclaredFields();
> +AccessibleObject.setAccessible(fields, true);
> +for (int i = 0; i < fields.length && builder.comparison == 0; i++) {
> +final Field field = fields[i];
> +if (!ArrayUtils.contains(excludeFields, field.getName())
> +&& !field.getName().contains("$")
> +&& (useTransients ||
> !Modifier.isTransient(field.getModifiers()))
> +&& !Modifier.isStatic(field.getModifiers())) {
> +// IllegalAccessException can't happen. Would get a Security
> exception instead.
> +// Throw a runtime exception in case the impossible happens.
> +builder.append(Reflection.getUnchecked(field, lhs),
> Reflection.getUnchecked(field, rhs));
> +}
> +}
> }
>
> /**
> @@ -183,10 +201,11 @@ public class CompareToBuilder implements
> Builder {
> *
> *
> * Static fields will not be compared
> - * If {@code compareTransients} is {@code true},
> + * If the {@code compareTransients} is {@code true},
> * compares transient members. Otherwise ignores them, as they
> * are likely deriv
Re: [commons-lang] branch master updated: --corrected the isUnchecked method to check for null (#1079)
Hi.
IIUC, the discussion sparked by that new code is currently
converging towards deletion:
https://markmail.org/message/nlqtk6na6nvwtelo
In any case, several arguments (confusing, unnecessary,
useless) were mentioned so that this commit be reverted.
A new thread should be started on the "dev" list, by someone
who still thinks that these utilities should be added.
Regards,
Gilles
Le lun. 3 juil. 2023 à 12:58, a écrit :
>
> This is an automated email from the ASF dual-hosted git repository.
>
> ggregory pushed a commit to branch master
> in repository https://gitbox.apache.org/repos/asf/commons-lang.git
>
>
> The following commit(s) were added to refs/heads/master by this push:
> new f68a643ef --corrected the isUnchecked method to check for null
> (#1079)
> f68a643ef is described below
>
> commit f68a643ef99189d10a6753167367dcc8f943d634
> Author: Dimitrios Efthymiou
> AuthorDate: Mon Jul 3 11:58:45 2023 +0100
>
> --corrected the isUnchecked method to check for null (#1079)
>
> --created test for null case
> ---
> src/main/java/org/apache/commons/lang3/exception/ExceptionUtils.java | 2 +-
> .../java/org/apache/commons/lang3/exception/ExceptionUtilsTest.java | 5
> +
> 2 files changed, 6 insertions(+), 1 deletion(-)
>
> diff --git
> a/src/main/java/org/apache/commons/lang3/exception/ExceptionUtils.java
> b/src/main/java/org/apache/commons/lang3/exception/ExceptionUtils.java
> index c98b5ed36..d1460b81f 100644
> --- a/src/main/java/org/apache/commons/lang3/exception/ExceptionUtils.java
> +++ b/src/main/java/org/apache/commons/lang3/exception/ExceptionUtils.java
> @@ -641,7 +641,7 @@ public class ExceptionUtils {
> * @since 3.13.0
> */
> public static boolean isUnchecked(final Throwable throwable) {
> -return !isChecked(throwable);
> +return throwable != null && (throwable instanceof Error || throwable
> instanceof RuntimeException);
> }
>
> /**
> diff --git
> a/src/test/java/org/apache/commons/lang3/exception/ExceptionUtilsTest.java
> b/src/test/java/org/apache/commons/lang3/exception/ExceptionUtilsTest.java
> index 956a72390..c103345ff 100644
> --- a/src/test/java/org/apache/commons/lang3/exception/ExceptionUtilsTest.java
> +++ b/src/test/java/org/apache/commons/lang3/exception/ExceptionUtilsTest.java
> @@ -635,6 +635,11 @@ public class ExceptionUtilsTest extends AbstractLangTest
> {
> assertTrue(ExceptionUtils.isChecked(new TestThrowable()));
> }
>
> +@Test
> +public void testIsUnchecked_null() {
> +assertFalse(ExceptionUtils.isUnchecked(null));
> +}
> +
> @Test
> public void testIsUnchecked_checked() {
> assertFalse(ExceptionUtils.isUnchecked(new IOException()));
>
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
Re: [commons-lang] branch master updated: [LANG-1647] Add and ExceptionUtils.isChecked() and isUnchecked() #1069
Le lun. 3 juil. 2023 à 09:41, Alex Herbert a écrit :
>
> On Mon, 3 Jul 2023 at 08:29, sebb wrote:
> >
> > Is null checked or unchecked?
> >
> > I think neither, so isUnchecked also needs to check for null.
> >
> > I wonder whether it might be better to throw NPE in both cases for null.
> >
> > It may be confusing for users if not checked != unchecked.
> > e.g. it is tempting to code:
> >
> > if (isChecked(t)) {
> > } else { // must be unChecked
> > }
> >
> > If we don’t throw NPE, then it needs to be made very clear that
> > isChecked and isUnchecked are not opposites, there is a 3rd case.
> >
> > In any case, there needs to be a unit-test specifically for null.
> >
> > Sebb
>
> +1
>
> I reiterate what I originally said, this is missing:
>
> @Test
> public void testIsUnchecked_null() {
> assertFalse(ExceptionUtils.isUnchecked(null));
> }
>
> The method implementation details are secondary to the fact that the
> code is not clear on how it handles null; the relationship between
> isChecked and isUnchecked; and the intended usage.
>
> Note that one possible usage of type determination is to decide if you
> can cast it to a certain type. Currently this method does not provide
> this functionality as isUnchecked does not ensure that a cast to
> RuntimeException is allowed (since it passes for Error). So my use
> case is satisfied by instanceof. This leaves me wondering what are the
> use cases for isChecked or isUnchecked. I presume you are in an
> exception block with a Throwable of unknown type. So why do you care
> if the exception is not checked if not for a recast?
>
> Without a use case not satisfied by instanceof then this is code bloat.
>
Reading through the discussion, I was wondering the same (What is
the use case?) and was tempted to reach the same conclusion.
After all, isn't "try/catch" the standard way to tailor behaviour according
to the exception type?
Regards,
Gilles
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
Re: [VOTE] Release Apache Commons Pool 2.12.0 based on RC1
Le jeu. 29 juin 2023 à 17:42, Elliotte Rusty Harold
a écrit :
>
> On Thu, Jun 29, 2023 at 10:48 AM Gilles Sadowski wrote:
>
> > The situation is recoverable from the caller's POV, by performing a
> > *new* call, with a correct argument. We certainly don't need a special
> > kind of exception[1] to handle this situation. What's wrong with catching
> > a "RuntimeException" if you know how to try again?
> >
>
> The problem isn't with catching a RuntimeException. The problem is
> with *not* catching the RuntimeException because the compiler doesn't
> make you do this, and the programmer forgets.
Yes, but I handled that case from the outset: If the programmer forgets,
that is a bug! And this kind of bug has no particular status wrt any other
bug (that would throw a "RuntimeException" and make the program crash
anyways if the "try/catch" block is missing).
If "no crash" is an application requirement, it probably should be ensured
through appropriate coverage (unit/fuzzy testing).
>
> Checked exceptions are for cases that SHOULD have an error handler,
> and simply makes the omission of one an easy-to-fix compile time error
> instead of a hard-to-fix runtime error.
In most cases, the sense that lower-level code is able to tell "you might
want to handle this" leads to every function advertising "Exception", just
in case some new "advice" might be deemed useful in the future; then
the cure to calling such a painful library is
---CUT---
try {
callPainfulLibrary(someArgs);
} catch(Exception e) {
thrown new RuntimeException(e);
}
---CUT---
>
> If the code in question shouldn't have an error handler, typically
> because the code in question is buggy and should be fixed so that the
> exception is never thrown in the first place, then a runtime exception
> is appropriate.
>
That's the part on which almost all agree except the writers of "painful"
libraries. ;-)
Best regards,
Gilles
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
Re: [VOTE] Release Apache Commons Pool 2.12.0 based on RC1
Le jeu. 29 juin 2023 à 16:33, Elliotte Rusty Harold a écrit : > > On Thu, Jun 29, 2023 at 10:10 AM Gilles Sadowski wrote: > > > > Le jeu. 29 juin 2023 à 15:22, Elliotte Rusty Harold > > a écrit : > > > > > > On Thu, Jun 29, 2023 at 9:07 AM Gilles Sadowski > > > wrote: > > > > > > > > Hello. > > > > > > > > Le jeu. 29 juin 2023 à 14:44, Gary Gregory a > > > > écrit : > > > > > > > I agree with the second part assuming the *current* Java > > > > best practices, not because of old APIs that are here to stay > > > > only because of infinite backwards compatibility, and not > > > > because they are deemed perfect. > > > > > > > > > Best practices on this haven't changed since Java 1.0 (Possibly Java > > > 1.0 alpha 3 if I recall versions correctly). > > > > > > Checked exceptions: all errors arising from external input to the program. > > > Runtime exceptions: program bugs > > > > A pile of arguments (tally is largely against *any* use of checked > > exceptions): > > > > https://ohadshai.medium.com/its-almost-2020-and-yet-checked-exceptions-are-still-a-thing-bfaa24c8997e > > tldr; he's wrong. More details: > https://www.youtube.com/watch?v=rJ-Ihh7RNao=419s At that point, and more than 10 minutes on, you explain the advantages of exception vs no exception. There is no debate: "exception" is much better than error-code checking. It was already in C++. > > > > > > I don't know which applies here, but 99% of the time this is all you > > > need to consider to figure out whether a checked or runtime exception > > > is called for. There are indeed a lot of old broken APIs that don't > > > follow these simple rules, > > > > The rules which you stated are far from simple because "external" > > depends on the POV (more below). > > > > Commons components like [RNG], [Geometry], [Numbers], [Math] > > only throw unchecked exceptions. > > Libraries you link to are not external to the program. Runtime > exceptions might be appropriate here. > > > The only rule that ever made sense to me is from J. Bloch's "Effective > > Java": > > ---CUT--- > > Use checked exceptions for recoverable conditions and runtime > > exceptions for programming errors > > ---CUT--- > > This is about the only thing in that book where I disagree with Bloch. > At the very least this is not said as well as it needs to be. > Recoverable vs unrecoverable distinguishes Errors from Exceptions, not > runtime exceptions from checked exceptions. You can interpret that > sentence to mean "bugs are not recoverable short of fixing the code" > in which case sure, runtime exceptions are not recoverable. I think I can understand your rationale: Something that can be corrected at runtime should be signalled by a checked exception. Right? However I don't understand why you now add "Error" to the mix... And that's possibly the main issue: There is no convincing use-case for so many "Throwable" categories at the JDK level: What is recoverable, or not, is ultimately a domain-related convention, and also perhaps a matter of definition in the context of a particular design. And the unchecked exception is simply the most convenient because it provides the significant advantage (over error code checking) while not forcing anyone to litter the code with mandatory "throws" clause, even if the code does not intend to handle any of the advertised exceptions. > > > For example, *all* precondition failures are, from the POV of the > > called function, a programming error (akin to NPE or IAE). > > This is correct. NPEs and IAEs are programming errors. > > > Whether the root cause is an "internal" or "external" error is irrelevant > > at the point where the issue is detected (where the runtime exception > > just conveys that "the call was inappropriate"). > > It's not about the root cause. It's about the immediate cause. Passing > null or another illegal argument to a method that isn't ready to > receive it is a programming error, i.e. a bug, and therefore these are > properly runtime exceptions. It's not necessarily a "bug" in the sense of "programming error". For example, a program reads user input with some rule on whether to accept it. If not accepted it throws. Whether it's recoverable depends on the wanted functionality (e.g. allow multiple attempts or not). > > > and it's never fun when a system goes down > > > in production because some random
Re: [VOTE] Release Apache Commons Pool 2.12.0 based on RC1
Le jeu. 29 juin 2023 à 16:18, Gary Gregory a écrit : > > > I never could find a convincing example of "recoverable conditions". > > Really? How about typing in a bad server name, user name, or password? Unfortunately we use different definitions of "recoverable". IMO, they are typically *non*-recoverable errors: Input is plain wrong and the called code can do *nothing* about it (apart from telling the caller to fix it on its end, and try again). > That's a classic recoverable exception (in JDBC land for example). The situation is recoverable from the caller's POV, by performing a *new* call, with a correct argument. We certainly don't need a special kind of exception[1] to handle this situation. What's wrong with catching a "RuntimeException" if you know how to try again? JDBC is old. Does any new, similarly widely used API, make similar use of checked exceptions? Regards, Gilles [1] In recent years Java borrowed several good ideas from other languages; AFAIK, no language borrowed the "checked exception" idea from Java. >> [...] - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [VOTE] Release Apache Commons Pool 2.12.0 based on RC1
Le jeu. 29 juin 2023 à 15:22, Elliotte Rusty Harold a écrit : > > On Thu, Jun 29, 2023 at 9:07 AM Gilles Sadowski wrote: > > > > Hello. > > > > Le jeu. 29 juin 2023 à 14:44, Gary Gregory a écrit > > : > > > I agree with the second part assuming the *current* Java > > best practices, not because of old APIs that are here to stay > > only because of infinite backwards compatibility, and not > > because they are deemed perfect. > > > Best practices on this haven't changed since Java 1.0 (Possibly Java > 1.0 alpha 3 if I recall versions correctly). > > Checked exceptions: all errors arising from external input to the program. > Runtime exceptions: program bugs A pile of arguments (tally is largely against *any* use of checked exceptions): https://ohadshai.medium.com/its-almost-2020-and-yet-checked-exceptions-are-still-a-thing-bfaa24c8997e > > I don't know which applies here, but 99% of the time this is all you > need to consider to figure out whether a checked or runtime exception > is called for. There are indeed a lot of old broken APIs that don't > follow these simple rules, The rules which you stated are far from simple because "external" depends on the POV (more below). Commons components like [RNG], [Geometry], [Numbers], [Math] only throw unchecked exceptions. The only rule that ever made sense to me is from J. Bloch's "Effective Java": ---CUT--- Use checked exceptions for recoverable conditions and runtime exceptions for programming errors ---CUT--- I never could find a convincing example of "recoverable conditions". In any case, Bloch's rule implies that there are several orders of magnitude more conditions that should raise an unchecked exception that there are for checked ones. For example, *all* precondition failures are, from the POV of the called function, a programming error (akin to NPE or IAE). Whether the root cause is an "internal" or "external" error is irrelevant at the point where the issue is detected (where the runtime exception just conveys that "the call was inappropriate"). > and it's never fun when a system goes down > in production because some random JSON yahoo thought checked > exceptions were "icky". A bug of the application, by the "absent-minded" developer mentioned in the previous mail. In Java, nothing prevents the throwing of a runtime exception; the developer *always* must enclose "foreign" code in a "try/catch" block, to protect the system. There is no need for checked exceptions just to remember this (really) simple rule. > > Lately I've been working in Python, and error handling practice in > this community is abominable. The lack of checked exceptions is a > large reason why Python code is expected to be unreliable and Python > programs routinely dump stack. I've heard that it's rather the result of "script"-oriented design, or lack thereof... :-) Regards, Gilles - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [VOTE] Release Apache Commons Pool 2.12.0 based on RC1
Hello. Le jeu. 29 juin 2023 à 14:44, Gary Gregory a écrit : > [...] > > Java makes a clear distinction between checked and unchecked > exceptions. As a mid-level API, I do not feel Pool should take a > design POV that is different from Java's intended pattern regarding > exceptions. I agree with the second part assuming the *current* Java best practices, not because of old APIs that are here to stay only because of infinite backwards compatibility, and not because they are deemed perfect. I don't see any relationship between "mid-level API" and "checked exceptions". Any reference (of modern code) for it? > > The 3.0 API should use checked exceptions -1 > and the implementation wrap > unchecked runtime exceptions. This will allow call sites to either > propagate or catch the one exception. The one "PoolException" need not be checked, to the same effect from an application developer POV. Gilles > > [...] - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [VOTE] Release Apache Commons Pool 2.12.0 based on RC1
Hello. [Sorry to continue a discussion that should probably go in its own thread.] Le jeu. 29 juin 2023 à 11:43, Mark Thomas a écrit : > > On 28/06/2023 14:16, Gary Gregory wrote: > > Hi All and Phil. > > I haven't been that involved in Pool recently but Pool remains a key > dependency for Tomcat (via DBCP). > > > The main driver here was two combine keeping binary compatibility > > _and_ benefit call sites of the API by _not_ having to catch Exception > > or throw Exception, which clearly is an anti-pattern. Instead, call > > sites should deal with domain exceptions, which they can in turn > > handle. IOW, when I am using IO resources or JDBC resources, I should > > expect to handle IOException and JDBCException, not Exception, so by > > extension (more on this below), I would expect to handle the same > > kinds of exceptions when I am pooling those kinds of resources. > > I understand the aim and I am generally in favour of simplification. > > However, Pool still throws unchecked exceptions (NoSuchElementException > and IllegalStateException, possibly others) during normal operations and > I think that significantly undermines what this change is trying to achieve. Looking at a commit [1] related to POOL-269 [2], a signature like void addObject(K key) throws E, IllegalStateException, UnsupportedOperationException; does not qualify as "simple". 1. Unchecked exceptions should not be referred to in the "throws" clause. 2. What is the advantage of a parameterized exception[3] over a common one (say "PoolException"), and use the standard JDK mechanism of storing more details in a "cause"[4] ? 3. Unchecked exceptions can always be thrown, so there is the old question again: What differentiates, in practice, an error condition that would raise a checked exception rather than an unchecked one?[5] 4. Protecting from a JVM crash is an application developer's decision. Do we really want to force all to handle checked exceptions just so that the compiler can remind the absent-minded (!) that a "try/catch" may be in order? > > [...] > > To fix the compilation issues and retain existing behaviour (without > worrying about the unchecked exceptions the Pool does throw during > normal operations) they are going to have to modify their code so that E > == Exception. That is going to look like a make-work task as they will > get zero benefit from it. How about * removing the "throws" clauses * reverting the addition of the "E" parameter ? > I think the majority of the benefit of this changes comes if Pool also > stops throwing unchecked exceptions - as a minimum during normal pooling > operations. How could that be achieved, short of enclosing all function bodies in a "try/catch" block and rethrowing a checked exception? For what benefit eventually (as asked above)? > I'd prefer to see this change deferred to a Pool 3.0 release preceded by > a wider discussion of the benefits of unchecked vs checked that has > started in this thread. AFAICT, unchecked exceptions was the way (a.o. setting an "IOException" as the cause of an "UncheckedIOException"[6] and rethrowing that one). Regards, Gilles [1] https://github.com/apache/commons-pool/pull/143/commits/36ca267abba54dcea11192c61df3ad74a5ac9941 [2] https://issues.apache.org/jira/browse/POOL-269 [3] Is there another library doing that? [4] https://docs.oracle.com/javase/8/docs/api/java/lang/Exception.html#Exception-java.lang.String-java.lang.Throwable- [5] Mimicking the API of the very early days of the JDK. [6] https://docs.oracle.com/javase/8/docs/api/java/io/UncheckedIOException.html - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [VOTE] Release Apache Commons IO 2.13.0 based on RC1
Hello. Maybe this report should be taken into account: https://issues.apache.org/jira/browse/IO-799 Regards, Gilles > [...] - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [IMAGING] Logging vs Throwing exceptions
Le mer. 10 mai 2023 à 12:29, Gilles Sadowski a écrit :
>
> Hello.
>
> Le mar. 9 mai 2023 à 23:43, Gary D. Gregory a écrit :
> >
> > Hi All,
> >
> > The method
> > org.apache.commons.imaging.icc.IccProfileParser.getICCProfileInfo(ByteSource)
> > looks like:
> >
> > public IccProfileInfo getICCProfileInfo(final ByteSource byteSource) {
> > // TODO Throw instead of logging?
> > final IccProfileInfo result;
> > try (InputStream is = byteSource.getInputStream()) {
> > result = readICCProfileInfo(is);
> > } catch (final Exception e) {
> > LOGGER.log(Level.SEVERE, e.getMessage(), e);
> > return null;
> > }
> > //
> > try {
> > for (final IccTag tag : result.getTags()) {
> > final byte[] bytes = byteSource.getBlock(tag.offset,
> > tag.length);
> > // Debug.debug("bytes: " + bytes.length);
> > tag.setData(bytes);
> > // tag.dump("\t" + i + ": ");
> > }
> > // result.fillInTagData(byteSource);
> > return result;
> > } catch (final Exception e) {
> > // Debug.debug("Error: " + file.getAbsolutePath());
> > LOGGER.log(Level.SEVERE, e.getMessage(), e);
> > }
> > return null;
> > }
> >
> > I find it odd and dubious that we would short-circuit the propagation of
> > exceptions
>
> In principle, exception swallowing is not good.
> Perhaps in this case, the result is considered "optional" (?). [In which
> case, the API should be upgraded to use
https://docs.oracle.com/javase/8/docs/api/java/util/Optional.html
> Perhaps the method should not be "public" (?).
>
> > with logging in such a low-level code. Unless someone can argue otherwise,
> > I would like to propagate the exceptions.
>
> Unchecked ones then, I suppose.
>
> Regards,
> Gilles
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
Re: [IMAGING] Logging vs Throwing exceptions
Hello.
Le mar. 9 mai 2023 à 23:43, Gary D. Gregory a écrit :
>
> Hi All,
>
> The method
> org.apache.commons.imaging.icc.IccProfileParser.getICCProfileInfo(ByteSource)
> looks like:
>
> public IccProfileInfo getICCProfileInfo(final ByteSource byteSource) {
> // TODO Throw instead of logging?
> final IccProfileInfo result;
> try (InputStream is = byteSource.getInputStream()) {
> result = readICCProfileInfo(is);
> } catch (final Exception e) {
> LOGGER.log(Level.SEVERE, e.getMessage(), e);
> return null;
> }
> //
> try {
> for (final IccTag tag : result.getTags()) {
> final byte[] bytes = byteSource.getBlock(tag.offset,
> tag.length);
> // Debug.debug("bytes: " + bytes.length);
> tag.setData(bytes);
> // tag.dump("\t" + i + ": ");
> }
> // result.fillInTagData(byteSource);
> return result;
> } catch (final Exception e) {
> // Debug.debug("Error: " + file.getAbsolutePath());
> LOGGER.log(Level.SEVERE, e.getMessage(), e);
> }
> return null;
> }
>
> I find it odd and dubious that we would short-circuit the propagation of
> exceptions
In principle, exception swallowing is not good.
Perhaps in this case, the result is considered "optional" (?). [In which
case, the API should be upgraded to use
Perhaps the method should not be "public" (?).
> with logging in such a low-level code. Unless someone can argue otherwise, I
> would like to propagate the exceptions.
Unchecked ones then, I suppose.
Regards,
Gilles
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
Re: [JEXL] Full Java module descriptor support
Hi. Le mar. 25 avr. 2023 à 17:37, Andres Almiray a écrit : > > Hello! > > I'd like to gauge interest in adding a full Java module descriptor (a.k.a > JPMS though the use of the acronym is discouraged) to commons-jexl. It's an interesting functionality, but I think that it should be done in a general way, applicable to all "Commons" components (through settings/profile in the "parent" POM, I guess). Regards, Gilles > > The codebase is currently Java 8 compatible. Adding a full Java descriptor > requires using Java 9+ in the build but does not force the whole codebase to > migrate. There are a couple of alternatives to make this work: > > - setup Maven so that a secondary source tree containing `module-info-.java` > is compiled with Java 9+. The compiled class should be added to the project's > JAR file inside the versioned space, such as > `/META-INF/versions/9/module-info.class`. > > - use the Moditect[1] Maven plugin to generate `module-info.class` and place > it inside the JAR. > > Full Java modules are required when creating custom Java runtimes with jlink, > regardless of the modular status of the target application. This is the use > case I'm looking for at the moment. > > If interested I can work on a PR based on feedback you may have. > > Cheers, > Andres > > [1] https://github.com/moditect/moditect > > PS: Some metadata of the latest JAR file: > > ``` > $ jarviz bytecode show --gav org.apache.commons:commons-jexl3:3.3 > subject: commons-jexl3-3.3.jar > Unversioned classes. Bytecode version: 52 (Java 8) total: 321 > > $ jarviz module name --gav org.apache.commons:commons-jexl3:3.3 > subject: commons-jexl3-3.3.jar > name: commons.jexl3 > source: filename > automatic: true > valid: true > > $ jarviz bytecode show --gav org.apache.commons:commons-jexl3:3.3 > subject: commons-jexl3-3.3.jar > Unversioned classes. Bytecode version: 52 (Java 8) total: 321 > aalmiray2:tmp aalmiray$ jarviz module descriptor --gav > org.apache.commons:commons-jexl3:3.3 > subject: commons-jexl3-3.3.jar > name: commons.jexl3 > version: 3.3 > open: false > automatic: true > requires: > java.base mandated > provides: > javax.script.ScriptEngineFactory with > org.apache.commons.jexl3.scripting.JexlScriptEngineFactory > contains: > org.apache.commons.jexl3 > org.apache.commons.jexl3.annotations > org.apache.commons.jexl3.internal > org.apache.commons.jexl3.internal.introspection > org.apache.commons.jexl3.introspection > org.apache.commons.jexl3.parser > org.apache.commons.jexl3.scripting > ``` > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [IO] 2 Patches for SymbolicLinkFileFilter
Hi. Le mar. 18 avr. 2023 à 10:20, Miguel Muñoz a écrit : > > Developers, > > (I'm new to Apache, Welcome. > so I hope this is the right way to submit patches.) The usual way would be to file a report on the bug-tracking system: https://issues.apache.org/jira/projects/IO and upload patches there. Regards, Gilles > [...] - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [math] 49 Junit test failures in 4.0 beta
Hello. Le lun. 3 avr. 2023 à 16:47, François Laferrière a écrit : > > When running Junit tests on ACM 4.0-snapshot I get a lot of failures. Mostly > (I supect) due to roundoff error beyond the tolerance of individual test. Is > it just a problem on my computer (Ubuntu 22.04, Eclipse 4.23, > java-18-openJdk-amd64 with JavaSE-1.8 compliance) or a general problem (that > should eventually be fixed). Thanks for the report, but please open a JIRA ticket, and post there (with a link here) the relevant part of the console log (maven output) so that we know what to look for. Regards, Gilles - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [ALL] Queries related to inconsistent naming of security pages
Hello. Le mar. 28 mars 2023 à 13:40, sebb a écrit : > > Here are the security page sources I could find: > > bcel/src/site/xdoc/security.xml > collections/src/site/xdoc/security-reports.xml > compress/src/site/xdoc/security.xml > configuration/src/site/xdoc/security.xml > crypto/src/site/xdoc/security.xml > email/src/site/xdoc/security-reports.xml > fileupload/src/site/xdoc/security-reports.xml > net/src/site/xdoc/security.xml > text/src/site/xdoc/security.xml > > These are not consistent, which results in problems such as the broken > link for Compress on the page: > https://commons.apache.org/security.html > > Does anyone know if there was a change in the convention for renaming these? > If so, which is correct? > > It looks like the 'security.html' links are added to the site menu via > site.xml, but that does not appear to be the case for the > 'security-reports.html' links. > > Does anyone know how these get added? > > Note, it would probably be a good idea to standardise on the placement > of the links in the menu. > Just after Downloads is probably as good a place as any. > How about having the list of vulnerabilities (that has to be managed "manually" anyways) part of the common "Commons" site? A link on each component's "sub-site" could refer back to that page but it should not be left to every component to design its "own" security listing. Note: On that page, there is this line Apache Commons BCEL Security Vulnerabilities linking to https://commons.apache.org/proper/commons-bcel/security.html that states For information about reporting or asking questions about security, please see the security page of the Apache Commons project. where "security page" links back to the common page. IMHO, all security issues should have one line on a single page, that line linking to a page with more details (such as links to CVE reports, commits, blog posts, ...). Regards, Gilles - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: Volunteering
Hi. Le mar. 28 mars 2023 à 00:17, a écrit : > > Greetings, > > I've got some time on my hands the next couple of weeks, and I figured I > could spend some of that time on the commons. Thanks! > > In particular, I've noticed that commons-cli, commons-lang, and > commons-io have a lot of jira issues and pull requests that have been > open for a long time. Is there anything I can do to help out there? > Triage, comment, test, whatever? Also: Commons Math (towards a non-beta release...) Regards, Gilles - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [Math] Needed some help as a new contributor to Apache JIRA
Hi. Please note that you should usually prefix the "Subject:" line of your post with the (short) name of the component in square brackets; here that would have been "[Math]". This is because there are so many different subjects that can be discussed on this ML, as explained there: https://commons.apache.org/mail-lists.html I've modified the email's subject accordingly. Also, I'm not sure I understand what you mean by "contributor to Apache JIRA" in the subject line... Le ven. 10 mars 2023 à 13:14, yousuf mohammed a écrit : > > I have tried to install Apache commons Math 4.0 beta 1 as binaries If you want to contribute to the "Commons Math" library, it looks like you should preferably download the "maven" project from the source repository, as briefly explained there: https://commons.apache.org/proper/commons-math/developers.html At your convenience, you might also want to use GitHub: https://github.com/apache/commons-math/ > I > extracted all the files Please give more details of what you did; there shouldn't be anything to "extract"... > but i am not aware of how to add these as external > libraries in my intelliJ IDE Again, I don't quite see what you mean. With the $ git clone https://gitbox.apache.org/repos/asf/commons-math.git command, you should get everything. Then, inside the just created commons-math directory, you should be able to run $ mvn in order to build the "binaries". > and I also require help on getting some of the > resources to really understand about how to use the library it would be > really helpful A lot of the functionality is explained in the userguide: https://commons.apache.org/proper/commons-math/userguide/index.html See also the Javadoc: https://commons.apache.org/proper/commons-math/commons-math-docs/apidocs/index.html Best regards, Gilles - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [GSoC2023] About “Add support for extended precision floating-point numbers” project
Hi.
Le lun. 6 mars 2023 à 11:22, Sentaro Onizuka a écrit :
>
> To whom it may concern,
Usually, the target audience would recognize itself through an
appropriate prefix in the "Subject:" line of the email.
In this case, instead of "[GSoC2023]", it should probably be
"[Numbers]", referring to the project (a.k.a. "component") where
the code being discussed, belongs (or should/will belong, in this
case, since the current implementation is in "Statistics").
>
> About “Add support for extended precision floating-point numbers”
> project of Google Summer of Code 2023.
>
> My name is Sentaro Onizuka.
> I emailed several days ago about my interest in this project and
> received the details and related resources.
> And I read the resources provided and would like to discuss the projects.
Many thanks for your interest and initial research into the subject!
Posting to this list is the right thing to do in order to draw attention
to a contribution proposal.
However, beyond a general discussion (e.g. whether the proposal
is within, or out of, the scope of project), the detailed plan of action
(including code excerpts) is better maintained through a dedicated
report page on the bug-tracking system (JIRA).
>
> Here is what I understood based on the resource
> ・ I understood how the user-friendly API is implemented by looking at
> what is already implemented in the Commons project (especially the Sum
> class that uses the builder pattern).
> ・ I read David Bailey's paper on the QD library and understood its
> algorithms. I also briefly looked over its C++ implementation.
> ・ I read the DD class[2] and understood the double-double
> implementation and API.
>
> What I would like to discuss is the API for a double-double. In
> particular, how I can extend it to a more user-friendly API.
> I have two ideas on this.
>
> ・ In the DD class API, simplify adding multiple DD values.
> e.g., compute the sum a1 + a2 + a3 (ai = {ai_h, ai_l}, ai == ai_h + ai_l)
> In the current DD class
> DD dd = DD.create(a1[0], a1[1]);
> dd = DD.add(dd.hi(),dd.lo(), a2[0], a2[1], dd);
> dd = DD.add(dd.hi(),dd.lo(), a3[0], a3[1], dd);
> double result = dd.doubleValue();
> In contrast, we implement the varargs factory method, which allows
> writing the following.
> double a = {a1, a2, a3};
> double result = DD.of(a).doubleValue();
> The implementation is assumed to be as follows, referring to the Sum class.
> public static DD of(double[][] values){
> return create().add(values);
> }
> public DD add(final double[][] terms) {
> for (double[] t : terms) {
> assert i.length == 2 : “ERROR”;
> add(t[0], t[1]);
> }
> return this;
> }
> public DD add(double x, double xx){
> // Adds a single term to this DD.
> return this;
> }
>
> ・ Implement QD as well as DD. As briefly mentioned in the David Bailey
> paper, for many applications, the use of DD or QD is sufficient.
> Therefore, I do not think implementing arbitrary-length floating-point
> numbers is necessary.
>
> And my question is, what specific extensions do you think are needed
> regarding the existing double-double API?
> Also, how about my ideas on extending the API to be more
> user-friendly? Am I on the right way?
Sure; your questions are certainly part of the issues that need
clarification.
However, besides the functionality itself, there is the question of
how it fits within the (math-related) components' "eco-system".
By this I mean that the code should be moved to "[Numbers]", but
where? In the "core" module (where "Sum" is implemented), or in
a new module of its own (e.g. on the assumption that it may be
too specific a utility)?
For one thing, the "Statistics" component will surely depend on
that utility; hence, porting the existing code to "[Numbers]" might
be your first pull request[1] (after ensuring locally that the calling
code is "Statistics" still works as it used to).
Thus, please create a JIRA report[2] to further elaborate on this.[3]
Anyways, thanks for posting here; it was an opportunity to provide
general information to every new contributor (particularly in view of
of potential GSoC applications).
Regards,
Gilles
[1] Perhaps we'll create a dedicated branch in the repository (so
that we don't mess with "master" until API issues are settled).
[2] https://issues.apache.org/jira/browse/NUMBERS
[3] Within JIRA, it's also possible to create "sub-tasks" (e.g. to
define "milestones").
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
Re: [math] discuss faster getEntry for RealMatrix implementations
Le sam. 4 mars 2023 à 17:08, Cyril de Catheu
a écrit :
> [...]
> > > >
> > > Let me know what you think.
> >
> > I've also added comments on JIRA.
> >
>
> Somehow I can't see any comments on JIRA -
> https://issues.apache.org/jira/browse/MATH-1654
> Am I missing something?
I wrote them... And forgot to click on "add". :-{
Done now.
Regards,
Gilles
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
Re: [math] The build is broken
Hello Gary. Le sam. 4 mars 2023 à 15:52, Gary D. Gregory a écrit : > > Hi Math, > > The build is broken locally for me, and as exemplified on GHA [1]: > https://github.com/apache/commons-math/actions/runs/4086106809/jobs/7044975362 Thanks for the notice but a button says "Sign in to view logs". No-go. > > Please fix. Could you please post the logs in a JIRA report? Two builds in a row were successful here: $ git pull Already up to date. $ mvn [...] [INFO] Reactor Summary for Apache Commons Math 4.0-SNAPSHOT: [INFO] [INFO] Apache Commons Math SUCCESS [ 4.842 s] [INFO] Miscellaneous core classes . SUCCESS [ 15.431 s] [INFO] Artificial neural networks . SUCCESS [ 9.253 s] [INFO] Transforms . SUCCESS [ 7.217 s] [INFO] Exception classes (Legacy) . SUCCESS [ 7.430 s] [INFO] Miscellaneous core classes (Legacy) SUCCESS [ 16.820 s] [INFO] Apache Commons Math (Legacy) ... SUCCESS [01:24 min] [INFO] Apache Commons Math Documentation .. SUCCESS [ 5.144 s] [INFO] Example applications ... SUCCESS [ 0.212 s] [INFO] SOFM ... SUCCESS [ 0.274 s] [INFO] SOFM: Chinese Rings SUCCESS [ 5.772 s] [INFO] SOFM: Traveling Salesman Problem ... SUCCESS [ 5.743 s] [INFO] K-Means SUCCESS [ 0.487 s] [INFO] K-Means: Image Clustering .. SUCCESS [ 5.322 s] [INFO] [INFO] BUILD SUCCESS [INFO] [INFO] Total time: 02:48 min [INFO] Finished at: 2023-03-04T16:05:58+01:00 [INFO] ---- Regards, Gilles > > Gary > [1] https://github.com/apache/commons-math/actions > - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [math] discuss faster getEntry for RealMatrix implementations
Hello. Le sam. 4 mars 2023 à 12:29, Cyril de Catheu a écrit : > > Hello, > > I just opened a ticket Thanks for the report! > describing an opportunity to optimize the getEntry > method of RealMatrix implementations. > For our specific workload in BOBYQA Advertisement: Help is very welcome for maintaining the implementation of that algorithm.[1] > this seems to be a ~10% speed > improvement. > I think it could also give a (variable) speed up to every consumer of > RealMatrix.getEntry. > > https://issues.apache.org/jira/browse/MATH-1654 Thanks for the analysis. Side note: You are most welcome to contribute to having JMH benchmarks integrated within the component's repository.[2] > If changing RealMatrix implems is not an option, there are other specific > solutions to optimize the BOBYQA optimizer. > > Let me know what you think. I've also added comments on JIRA. Best regards, Gilles [1] Cf. related issues in JIRA (and in the ML archive). [2] By coincidence, another discussion has just been restarted about it (for another functionality): https://issues.apache.org/jira/browse/MATH-1585 - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [GSoC] Commom Math project questions
Hi. Le ven. 3 mars 2023 à 01:13, Alex Ryu a écrit : > > To whom it may concern, > > > > Hello, my name is HyoungJoo Ryu. > > I am interested in participating in Apache Software Foundation’s “Common > Math” project through Google Summer of Code this summer. Especially idea > #1: Redesign and modularize the “ml” package to enable multi-thread usage. > > > > I am currently a sophomore student majoring in Computer Science at Virginia > Tech, and have a strong foundation in OOP especially in Java, and Data > Structures and Algorithms. > > > > My question is that do we have to go through all the ideas in the idea list > for this project or is it there for us to select one from the list. One or more, from the non-exhaustive list there, or other issues on the bug-tracking system or a new feature (that is within scope). But the ML area is pretty large already, indeed. Also, note that there is pending work on a relatively recent proposal to refactor the "genetics" package that could be rightfully included in that project. > Also I > am currently going through the “ML” package, and wondering if there are any > tips for newcomers going through the package and is there a way to discuss > my proposal with any potential mentors? This ML is usually the right place for a general discussion (e.g. new feature, alternative designs, ...) Technical details can then be further refined in JIRA reports dedicated to specific tasks. > > I believe that this project will provide me with a great opportunity to > expand my knowledge and expertise in programming. I am ready to learn as > much as possible and take on any new challenges, while making meaningful > contributions. You are certainly welcome to contribute here. Thanks for your interest, Gilles - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
