Re: [numbers] 1.0-B1 Release Proposal

Hi. Le lun. 30 mars 2020 à 16:19, Matt Juntunen a écrit : > > The issue I saw with the site [1] was that the text under the Releases > section says "There is no offcial release yet. Come and join development > work!" Clearly, that won't work for a release version. Ah OK. I had created that co

Re: [numbers] 1.0-B1 Release Proposal

Le lun. 30 mars 2020 à 15:38, Gilles Sadowski a écrit : > > Hello. > > Le lun. 30 mars 2020 à 15:06, Matt Juntunen > a écrit : > > > > I made it all the way up to the vote email and then realized that the site > > index page does not have a link to the

Re: [numbers] 1.0-B1 Release Proposal

Hello. Le lun. 30 mars 2020 à 15:06, Matt Juntunen a écrit : > > I made it all the way up to the vote email and then realized that the site > index page does not have a link to the downloads page. So, I'm going to scrap > RC1 and start RC2 either later today or tomorrow. I'm not sure what prob

Re: [VOTE] Release Apache Commons Lang 3.10 based on RC1

Hi. Le jeu. 26 mars 2020 à 15:33, Gary Gregory a écrit : > > Ping! :-) > > Gary > > On Mon, Mar 23, 2020 at 10:20 AM Gary Gregory wrote: > > > We have fixed quite a few bugs and added some significant enhancements > > since Apache Commons Lang 3.9 was released, so I would like to release > > Apa

Re: [numbers] Release?

Hello. Le mer. 25 mars 2020 à 20:28, Matt Juntunen a écrit : > > Thanks everyone for the information. I'll start working toward this and send > out an email when I'm ready to start cutting the release. > > One thing I notice is that there isn't a commons-numbers user guide to speak > of. There

Re: Re: [math] Discuss: New feature MiniBatchKMeansClusterer

Hello. > > [...] > > I have started 2 PRs to solve the problem you metioned. > > About the "CentroidInitializer" I have a new idea: > Move CentroidInitializers as inner classes of "KMeansPlusPlusCluster", > and add a construct parameter and a property "useKMea

Re: Re: [math] Discuss: New feature MiniBatchKMeansClusterer

2020-03-25 4:54 UTC+01:00, chentao...@qq.com : > Hi, > >>Hello. >> >>Le mar. 24 mars 2020 à 06:39, chentao...@qq.com a écrit >> : >>> >>> Hi, >>> >>> I have started 2 PRs to solve the problem you metioned. >>> >>> About the "CentroidInitializer" I have a new idea: >>> Move CentroidInitiali

Re: [numbers] Release?

Hello. Le mar. 24 mars 2020 à 16:19, Alex Herbert a écrit : > > > On 24/03/2020 13:30, Rob Tompkins wrote: > > Yes you’re totally welcome to, and the directions are here: > > http://commons.apache.org/releases/index.html > > > > > > Feel free to a

Re: [math] Discuss: New feature MiniBatchKMeansClusterer

Hello. Le mar. 24 mars 2020 à 06:39, chentao...@qq.com a écrit : > > Hi, > > I have started 2 PRs to solve the problem you metioned. > > About the "CentroidInitializer" I have a new idea: > Move CentroidInitializers as inner classes of "KMeansPlusPlusCluster", > and add a construct parame

Re: [math] Discuss: New feature MiniBatchKMeansClusterer

Hi Tao. I've merged PR #128 but please see my comment on the JIRA page.[1] Thanks for your interest in improving the library, Gilles [1] https://issues.apache.org/jira/browse/MATH-1509?focusedCommentId=17064306&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-1706

Re: [math]Discussion: How to move out "EmptyClusterStrategy" from KMeansPlusPlusClusterer

Hello. 2020-03-21 4:02 UTC+01:00, chentao...@qq.com : > Hi, > >>2020-03-21 2:59 UTC+01:00, chentao...@qq.com : >>> Hi, >>> >>>>Le ven. 20 mars 2020 à 04:47, chentao...@qq.com a >>>> écrit >>>> : >>>>> >>>

Re: [math]Discussion: How to move out "EmptyClusterStrategy" from KMeansPlusPlusClusterer

2020-03-21 2:59 UTC+01:00, chentao...@qq.com : > Hi, > >>Le ven. 20 mars 2020 à 04:47, chentao...@qq.com a écrit >> : >>> >>> Hi, >>> >>> >Hello. >>> > >>> >Le mer. 18 mars 2020 à 17:57, Gilles Sadowski a >>&g

Re: [math]Discussion: How to move out "EmptyClusterStrategy" from KMeansPlusPlusClusterer

Le ven. 20 mars 2020 à 04:47, chentao...@qq.com a écrit : > > Hi, > > >Hello. > > > >Le mer. 18 mars 2020 à 17:57, Gilles Sadowski a écrit > >: > >> > >> Hi. > >> > >> 2020-03-18 15:10 UTC+01:00, chentao...@qq.com : &

Re: [math]Discussion: How to move out "EmptyClusterStrategy" from KMeansPlusPlusClusterer

Hello. Le mer. 18 mars 2020 à 17:57, Gilles Sadowski a écrit : > > Hi. > > 2020-03-18 15:10 UTC+01:00, chentao...@qq.com : > > Hi, > > I have created a PR to show my aim: > > https://github.com/apache/commons-math/pull/126/files > > Am I

Re: [math]Discussion: How to move out "EmptyClusterStrategy" from KMeansPlusPlusClusterer

Hi. 2020-03-18 15:10 UTC+01:00, chentao...@qq.com : > Hi, > I have created a PR to show my aim: > https://github.com/apache/commons-math/pull/126/files Am I correct that the implementations of "ClustersPointExtractor" modify the argument of the "extract" method? If so, that seems quite unsafe

Re: [math]Discussion: How to move out "EmptyClusterStrategy" from KMeansPlusPlusClusterer

Hello. Le mer. 11 mars 2020 à 07:28, chentao...@qq.com a écrit : > > Hi all, > The "EmptyClusterStrategy" in KMeansPlusPlusClusterer can be reused > MiniBatchKMeansClusterer and other cluster altorithm. > So I think the "EmptyClusterStrategy" should move out from > KMeansPlusPlusCluster

Re: [math]Discuss: There should be a CalinskiHarabaszClusterEvaluator in ml package

Hello. 2020-03-07 14:50 UTC+01:00, chentao...@qq.com : > Hi, > >>> > [...] >>> Solution 3 is "ClusterRanking". >>> In cases where the reference algorithm would assume the >>> other convention (i.e. "lower is better"), the implementation >>> is required to apply a conversion (e.g. return the oppo

[Math] Enhance clustering API

Hello. I've collected[1] a series of old issues reported against code in the org.apache.commons.math4.ml.clustering package. The first proposed improvement[2] to the API results from a discussion in another recent thread. Any objection to that change? Best, Gilles [1] https://issues.apache.or

Re: [math]Discuss: There should be a CalinskiHarabaszClusterEvaluator in ml package

> > [...] > Solution 3 is "ClusterRanking". > In cases where the reference algorithm would assume the > other convention (i.e. "lower is better"), the implementation > is required to apply a conversion (e.g. return the opposite). s/opposite/inverse/ [We should probably enforce that ranking is p

Re: [math]Discuss: There should be a CalinskiHarabaszClusterEvaluator in ml package

Hello. >>> [...] >>> >> For machine learning centroid cluster algorithm, we often use is >>> >> Calinsk-iHarabasz score to evaluate which algorithm or how many >>> >> centers is >>> >> best for a dataset. >>> >> The python lib sklearn implements Calinsk-iHarabasz as >>> >> sklearn.metrics.

Re: Re: [math]Discuss: There should be a CalinskiHarabaszClusterEvaluator in ml package

Le ven. 6 mars 2020 à 14:35, chentao...@qq.com a écrit : > > Hi, > > >Hello. > > > >2020-03-06 9:48 UTC+01:00, chentao...@qq.com : > >> Hi, > >> For machine learning centroid cluster algorithm, we often use is > >> Calinsk-iHarabasz score to evaluate which algorithm or how many centers is > >>

Re: [math]Discuss: There should be a CalinskiHarabaszClusterEvaluator in ml package

Hello. 2020-03-06 9:48 UTC+01:00, chentao...@qq.com : > Hi, > For machine learning centroid cluster algorithm, we often use is > Calinsk-iHarabasz score to evaluate which algorithm or how many centers is > best for a dataset. > The python lib sklearn implements Calinsk-iHarabasz as > sklea

Re: [math] Discuss: New feature MiniBatchKMeansClusterer

Hello. Le jeu. 5 mars 2020 à 13:23, chentao...@qq.com a écrit : > > [...] > It is a API change, how do we start it? I'd suggest putting the new API in a (temporary) package org.apache.math4.ml.clustering2 Regards, Gilles > [...] --

Re: [lang] NPE vs IAE

o maintain. Gilles > > Regards, > Peter > > > On Thu, Mar 5, 2020 at 4:12 PM sebb wrote: > > > On Wed, 4 Mar 2020 at 14:20, Gilles Sadowski wrote: > > > > > > Le mer. 4 mars 2020 à 15:16, sebb a écrit : > > > > > > > > On We

Re: [lang] NPE vs IAE

Le jeu. 5 mars 2020 à 16:12, sebb a écrit : > > On Wed, 4 Mar 2020 at 14:20, Gilles Sadowski wrote: > > > > Le mer. 4 mars 2020 à 15:16, sebb a écrit : > > > > > > On Wed, 4 Mar 2020 at 14:09, Gary Gregory wrote: > > > > > > > >

Re: [math] Discuss: New feature MiniBatchKMeansClusterer

Hello. 2020-03-05 4:50 UTC+01:00, chentao...@qq.com : > Hi, > >>Hi. >> >>Le ven. 28 févr. 2020 à 05:04, chentao...@qq.com a >> écrit : >>> >>> >>> >>> >>> -- >>> chentao...@qq.com >>> >Hi. >>> > >>> >Le jeu. 27 févr. 2020 à 06:17, chentao...@qq.com a >>> > écrit : >>> >> >>> >> Hi, >

Re: [lang] NPE vs IAE

Le mer. 4 mars 2020 à 15:16, Gilles Sadowski a écrit : > > Le mer. 4 mars 2020 à 15:09, Gary Gregory a écrit : > > > > IMO, until we are all on Java 14 and benefit from its more detailed NPE > > message, we need to call Validate.notNull _with a message_ that says w

Re: [lang] NPE vs IAE

Le mer. 4 mars 2020 à 15:16, sebb a écrit : > > On Wed, 4 Mar 2020 at 14:09, Gary Gregory wrote: > > > > IMO, until we are all on Java 14 and benefit from its more detailed NPE > > message, we need to call Validate.notNull _with a message_ that says what > > variable blew up. > > +1 > > That is a

Re: [lang] NPE vs IAE

sly), but you may *want* to. Gilles > > Gary > > On Wed, Mar 4, 2020 at 9:01 AM Gilles Sadowski wrote: > > > Le mer. 4 mars 2020 à 14:19, Gary Gregory a > > écrit : > > > > > > On Wed, Mar 4, 2020 at 7:58 AM sebb wrote: > > &g

Re: [lang] NPE vs IAE

Le mer. 4 mars 2020 à 14:19, Gary Gregory a écrit : > > On Wed, Mar 4, 2020 at 7:58 AM sebb wrote: > > > On Sat, 29 Feb 2020 at 18:09, Gilles Sadowski > > wrote: > > > > > > Le sam. 29 févr. 2020 à 18:39, Gary Gregory a > > écrit : > > >

Re: [collections] Bloom filters

Hello. Le lun. 2 mars 2020 à 14:19, Manas Kalangan a écrit : > > hey guys , i am manas , 2nd year computer engineering student, this is my > first time in GSoC, could someone help me with project idea? Welcome at the Commons project's discussion forum, but please do not hijack threads.[1] Best

Re: [lang] NPE vs IAE

Le sam. 29 févr. 2020 à 18:39, Gary Gregory a écrit : > > On Sat, Feb 22, 2020 at 5:25 PM Gary Gregory wrote: > > > I would like to do the same in Lang as with Collections (see below.)\ > > > > We currently perform checks like: > > > > Validate.isTrue(foo != null, ...) > > > > Which should be IMO

Re: Re: [math] Discuss: New feature MiniBatchKMeansClusterer

Hi. Le ven. 28 févr. 2020 à 05:04, chentao...@qq.com a écrit : > > > > > -- > chentao...@qq.com > >Hi. > > > >Le jeu. 27 févr. 2020 à 06:17, chentao...@qq.com a écrit > >: > >> > >> Hi, > >> > >> > [...] > >> >> >> > >> >> >> Do you mean I should fire a JIRA issue about reuse "centr

Re: [math] Discuss: New feature MiniBatchKMeansClusterer

Hi. Le jeu. 27 févr. 2020 à 06:17, chentao...@qq.com a écrit : > > Hi, > > > [...] > >> >> > >> >> Do you mean I should fire a JIRA issue about reuse "centroidOf" > >> >> and "chooseInitialCenters", > >> >> then start a PR and a disscuss about "ClusterUtils"? > >> >> And then start the PR of "Mi

Re: [math] Discuss: New feature MiniBatchKMeansClusterer

Hello. [Message formatting is fine now. Thanks!] Le mer. 26 févr. 2020 à 15:20, chentao...@qq.com a écrit : > > Hi, > > >Hello. > > > >[Please try and set your mail client to send plain text messages.] > > > >Le mer. 26 févr. 2020 à 14:05, CT a écrit : > >> > >> Hi Gilles, > >> ---

Re: [math] Discuss: New feature MiniBatchKMeansClusterer

Hello. [Please try and set your mail client to send plain text messages.] Le mer. 26 févr. 2020 à 14:05, CT a écrit : > > Hi Gilles, > -- Original -- > From: "GillesSadowski" Date: Wed, Feb 26, 2020 05:41 PM > To: "Commons Developers List" > Subject: Re: [math] Di

Re: [math] Discuss: New feature MiniBatchKMeansClusterer

should remove them? As you've noticed that some functionality must be factored out of "KMeansPlusPlusClusterer", this should be done first as a separate JIRA issue. IIUC, you propose "ClusterUtils". By reviewing a minimal PR, we should be able to examine whether another

Re: [math] Discuss: New feature MiniBatchKMeansClusterer

We try and avoid bloating the API, hence the changes which I've suggested: * remove the constructors with default parameters Overall, each PR should probably contain a single commit, in order to ease review. > I remain have one question below: > > ------ Original

Re: [math] Discuss: New feature MiniBatchKMeansClusterer

Hi. Le sam. 22 févr. 2020 à 14:37, CT a écrit : > > Hi Gilles: > I really appricate for your patient to help me to solve the mail sending > problem, I try to set the only setting about charset "Use Unicode" for this > mail. The contents seems fine. However, there is something wrong: replyin

Re: [numbers] Release?

Le sam. 22 févr. 2020 à 01:30, Alex Herbert a écrit : > > > > > On 22 Feb 2020, at 00:29, Gilles Sadowski wrote: > > > > Hi. > > > > Le ven. 21 févr. 2020 à 23:15, Matt Juntunen > > a écrit : > >> > >> Are we waiting on anythi

Re: [numbers] Release?

Hi. Le ven. 21 févr. 2020 à 23:15, Matt Juntunen a écrit : > > Are we waiting on anything for a numbers release? I don't think so. Best, Gilles > > > [...] - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For addi

Re: [math] Discuss: New feature MiniBatchKMeansClusterer

[Re-sending post so that it is attached to the original thread.] Hello. Le mar. 18 févr. 2020 à 04:49, 陈 涛 a écrit : > > Hi Gilles: > >I really do not know if anyone received my last mail, no one replay me for > a long time so I send it again and copy to you with another email system. Sorr

Fwd: [math] Discuss: New feature MiniBatchKMeansClusterer

Hello. Le mar. 18 févr. 2020 à 04:49, 陈 涛 a écrit : > > Hi Gilles: > >I really do not know if anyone received my last mail, no one replay me for > a long time so I send it again and copy to you with another email system. Sorry for the delay. :-} > > > Some remarks: > > > * I didn't get why

Re: [numbers] Release?

Hi. Le jeu. 23 janv. 2020 à 15:04, Matt Juntunen a écrit : > > Hello, > > Any chance we can get a release (beta or full) for commons-numbers? Non-exhaustive check-list is here: https://issues.apache.org/jira/browse/NUMBERS-25 All "crosses" to be changed to "checks"? Anyways, +1 to making b

Re: [All] Do we want to apply for "mentored" contributions?

the non math-related components. Hence the suggestion that internship must be supported by "Commons" as a whole. Regards, Gilles > > On Tue, Feb 4, 2020 at 05:47 Gilles Sadowski wrote: > > > Hello. > > > > Is "Commons" willing to set up i

[All] Do we want to apply for "mentored" contributions?

Hello. Is "Commons" willing to set up itself for welcoming new people who, in order to contribute to the projects, might need more support than the usual asynchronous review of patches? The ASF participates in GSoC[1] and Outreachy[2] and some Apache projects seem well prepared for dealing with t

Re: [numbers] NUMBERS-40: Exception Consistency

Hi. 2020-01-26 16:54 UTC+01:00, Matt Juntunen : > Hello, > > I'm looking into NUMBERS-40, which suggests that the exception behavior of > commons-numbers (specifically the gamma package) needs to be made more > consistent. Below is a summary of the public exception types explicitly > thrown by eac

Re: [LANG] Start contributing

Amarasinghe < > > ahamarasin...@gmail.com> wrote: > > > >> Hi Gilles, > >> > >> Thanks for the support. I was able to setup work space and build the > >> project > >> > >> *Best Regards * > >> *Asanka Amarasinghe* > >>

Re: [All] Sonarcloud reports zero coverage

Hi. Le lun. 27 janv. 2020 à 09:56, Amey Jadiye a écrit : > > On Mon, Jan 27, 2020, 4:57 AM Gilles Sadowski wrote: > > > Hello. > > > Hi, > > > > > Le dim. 26 janv. 2020 à 18:06, Amey Jadiye a écrit > > : > > > > > > For almost

Re: [All] Sonarcloud reports zero coverage

amp;id=commons-rng > [3] > https://sonarcloud.io/organizations/apache/quality_profiles/changelog?language=java&name=Sonar+way Thanks for looking into it. I too had noticed that "something" is reported as changed, but couldn't figure out what... Regards, Gilles > Regards,

Re: [All] Sonarcloud reports zero coverage

ks, Gilles > > -Matt > ________ > From: Gilles Sadowski > Sent: Wednesday, January 15, 2020 10:47 AM > To: Commons Developers List > Subject: [All] Sonarcloud reports zero coverage > > Hello. > > "Sonar" reports are created for several projects, a.o. >

Re: Working on a Stream-based Java statistical processing library

Hello. Le sam. 25 janv. 2020 à 17:56, Kartik Ohri a écrit : > > Hi, I am interested in working on a Stream-based Java statistical > processing library Thanks for your interest in contributing. > as described here at > https://issues.apache.org/jira/browse/STATISTICS-7 . Can someone point > me t

Re: [LANG] Start contributing

Hi. 2020-01-25 7:00 UTC+01:00, Asanka Amarasinghe : > Hi, > > I'm new to open source community, and I would like to contribute to > commons.lang project. I read all the materials for beginners and I already > joined JIRA issue tracker. Welcome. > > Could someone guide me to where I can find a do

Re: [numbers] Complex to use code ported with a permissive licence

; Only tempProject0 has to make its license be license0 , but that will not > pollute apache-commons-numbers. > although I'm not sure if this way be morals to do so, it does not break any > rules IMO. > > 发件人: Gilles Sadowski > 发送时间: 2020

Re: [numbers] Complex to use code ported with a permissive licence

w to comply with that license in an Apache project). Or I must be missing something... Gilles > > ________ > From: Gilles Sadowski > Sent: Friday, January 24, 2020 5:43:49 PM > To: Commons Developers List > Subject: Re: [numbers] Complex to use code

Re: [numbers] Complex to use code ported with a permissive licence

Hi. 2020-01-24 5:21 UTC+01:00, Xeno Amess : > how about create a new project who contains the modified source function > and original license，and in commons we just invoke that function？ > Then, the same question(s) will be asked for that new project (?). Regards, Gilles ---

Re: [numbers] Complex to use code ported with a permissive licence

Hi. 2020-01-24 1:42 UTC+01:00, Alex Herbert : > > >> On 24 Jan 2020, at 00:07, Gilles Sadowski wrote: >> >> Hello. >> >> 2020-01-24 0:30 UTC+01:00, Alex Herbert > <mailto:alex.d.herb...@gmail.com>>: >>> In short: >>> >>

Re: [numbers] Complex to use code ported with a permissive licence

Hello. 2020-01-24 0:30 UTC+01:00, Alex Herbert : > In short: > > - Math.hypot is required in Complex to compute sqrt(x^2 + y^2) without > over/underflow to 1 ULP precision. > - Complex also requires the same computation without the sqrt or > over/underflow protection > - I found the reference for

Re: [numbers] Release?

numbers/pull/6 > > From: Gilles Sadowski > Sent: Thursday, January 23, 2020 11:11 AM > To: Commons Developers List > Subject: Re: [numbers] Release? > > Hi. > > Le jeu. 23 janv. 2020 à 15:04, Matt Juntunen > a écrit : >> >> He

Re: [numbers] Release?

Hi. Le jeu. 23 janv. 2020 à 15:04, Matt Juntunen a écrit : > > Hello, > > Any chance we can get a release (beta or full) for commons-numbers? Currently, only one unresolved issue tagged for the first release.[1] Regards, Gilles [1] https://issues.apache.org/jira/issues/?jql=project%20%3D%20NU

Re: [geometry] Beta Release

kly jump > > to 2.0 (if needed). > > > >> Note that "Numbers" should be released first (eventually "beta" too). > > > > Is commons-numbers ready for a beta release as well? I think so (this should be discussed in another post). Regards, Gilles >

Re: [geometry] Beta Release

Hello. Le mar. 21 janv. 2020 à 14:41, Matt Juntunen a écrit : > > Hello, > > I think that commons-geometry is ready for a beta release, as discussed > previously. If there are no objections, how do we make that happen? Note that "Numbers" should be released first (eventually "beta" too). Best,

Re: [geometry] Beta Release

Hi. Le mar. 21 janv. 2020 à 14:47, Rob Tompkins a écrit : > > I can try to help with that later this week potentially. My main question is: > do we want to change the base package name across the component to > `org.apache.commons.beta` for the beta release? +1 Follow-up question: Do we agree

Re: [geometry] Rename Transform to AffineTransform

Hello. 2020-01-20 20:39 UTC+01:00, Matt Juntunen : > Gilles, > >> I was not indicating that the name "EuclideanTransform" would be >> better than "AffineTransform", I was wondering about whether the >> class itself is redundant. > > Oh, I misunderstood. The "EuclideanTransform" interface is import

Re: [geometry] Rename Transform to AffineTransform

Hello. Le lun. 20 janv. 2020 à 16:57, Matt Juntunen a écrit : > > Gilles, > > > From a design POV, I still think that "AffineTransform" is redundant: > > The "AffineTransform" name change has been reverted. It is now the original > "EuclideanTransform". I was not indicating that the name "Eucli

Re: [geometry] Rename Transform to AffineTransform

that seems >> to >> only contain convenience methods for internal use (whereas having them >> "protected" put them in the public API). > > That class also contains other matrix-specific methods (eg, "determinant") > and the overridden "preservesOrientatio

Re: [math]New feature MiniBatchKMeansClusterer

Hi. 2020-01-20 3:08 UTC+01:00, CT : > Hi,  In my picture search project, I need a cluster algorithm to narrow > the dataset, for accelerate the search on millions of pictures. >   First we use python+pytorch+kmean, with the growing data from > thousands to millions, the KMeans clustering became sl

Re: [geometry] Rename Transform to AffineTransform

f "Transform" can only be affine, it looks strange to have "AffineTransform" (re)defined. I'm also a bit puzzled by the "AbstractAffineTransformMatrix" that seems to only contain convenience methods for internal use (whereas having them "protected" put

Re: [geometry] Rename Transform to AffineTransform

t; commons-geometry-core >Transform > > commons-geometry-euclidean > EuclideanTransform extends Transform > AffineTransformMatrixXD implements EuclideanTransform > Rotation3D extends EuclideanTransform > QuaternionRotation implements Rotation3D > > commo

Re: [rng] FiniteDoubleSampler to sample uniformly from a range of representable double values

Hi. Le ven. 17 janv. 2020 à 13:15, Alex Herbert a écrit : > > The UniformRandomProvider and ContinuousUniformSampler can create > doubles uniformly in a range [0, 1) and [x, y). > > I would like to create a sampler that can create doubles with random > mantissa bits and a specified range of expon

[Math] Bypassing official channels... (Was: [GitHub] [commons-math] chentao106 opened a new pull request #117: Implement the MiniBatchKMeansClusterer)

Hi. Can someone comment on GitHub that communication should be through the "dev" ML and/or JIRA? Thanks, Gilles Le jeu. 16 janv. 2020 à 17:37, GitBox a écrit : > > chentao106 opened a new pull request #117: Implement the > MiniBatchKMeansClusterer > URL: https://github.com/apache/commons-math/

[All] Sonarcloud reports zero coverage

Hello. "Sonar" reports are created for several projects, a.o. https://sonarcloud.io/dashboard?id=commons-numbers https://sonarcloud.io/dashboard?id=commons-geometry https://sonarcloud.io/dashboard?id=commons-rng https://sonarcloud.io/dashboard?id=commons-statistics for which covera

Re: [commons-numbers] branch master updated: Add benchmark for sin/cos computation.

Hi. Le mar. 14 janv. 2020 à 12:24, a écrit : > > [...] > > Add benchmark for sin/cos computation. > > Computing sin/cos together would improve many of the functions in > Complex. This benchmark investigates the possibility of using the > Commons FastMath implementation instead of

Re: [geometry] Rename Transform to AffineTransform

ity. If the "Transform" is intimately related to the "core" and there is a single set of properties that make it "affine" (and work correctly), I'd tend to keep the name "Transform". [As long as unit tests ensure that concrete implementations possess the exp

Re: [numbers] LinearCombination dot product accuracy

Hi. Le ven. 10 janv. 2020 à 22:45, Alex Herbert a écrit : > > > > > On 10 Jan 2020, at 18:12, Gilles Sadowski wrote: > > > >> ... > > > > IIUC, precision (without resorting to "BigDecimal") was the purpose of > > "LinearCombinati

Re: [numbers] LinearCombination dot product accuracy

Hi Alex. Thanks a lot for this work (and all the "Complex" stuff)! Le ven. 10 janv. 2020 à 18:18, Alex Herbert a écrit : > > I have been investigating the accuracy of the LinearCombination class. This > was because I was using it to perform high precision computations in the > Complex class an

Re: [collections] bloom filters comments

Le mer. 8 janv. 2020 à 15:15, Gary Gregory a écrit : > > I think it is time to bring this PR in and make any adjustments within > master beyond that. This will be quicker and simpler than going round and > round for simple things like Javadoc tweaks and small non-functional > changes (formatting,

Re: [geometry] Rename Transform to AffineTransform

e transform must exist" does not translate into a method ---CUT--- Transform getInverse(); ---CUT--- Regards, Gilles > -Matt > > From: Gilles Sadowski > Sent: Tuesday, January 7, 2020 6:41 PM > To: Commons Developers List > Subject:

Re: [geometry] Rename Transform to AffineTransform

n, which included an > applyTransform(Transform) method. So the "affine" requirement (in the doc) applied there too. Anyways, what would be the issue(s) of a non-affine transform? IOW why should implementations of "Transfrom" be restricted to affine transform? Regards, Gilles

Re: [geometry] Rename Transform to AffineTransform

Hello. Le mar. 7 janv. 2020 à 16:00, Matt Juntunen a écrit : > > Hi all, > > The documentation for the o.a.c.geometry.core.Transform interface (which > comes from the original commons-math version) states that implementations > must be affine. Therefore, I think we should rename this interface

Fwd: [Geometry] Class "Equivalency"

Forwarding to ML. Gilles P.S. Please don't send to me directly when the post is meant for the list, as otherwise hitting "Reply" will move the conversation off-list... -- Forwarded message ----- De : Gilles Sadowski Date: sam. 4 janv. 2020 à 19:54 Subject: Re: [

Re: [Geometry] Class "Equivalency"

; WDYT? +1 For further consolidation, could we rename "eq" to "equals", and make "equals(Object)" call "equals(T, DoublePrecisionContext)"? Gilles > > -Matt > > From: Gilles Sadowski > Sent: Friday, January

Re: [Geometry] Class "Equivalency"

In effect, I could imagine that "fuzzy" equality could not be commutative (random, perhaps naive, thought): an instance with low precision would indicate that some result (where precision could have been lost) would consider itself equal to another instance (that may have have been set wit

[Geometry] Class "Equivalency"

Hello. I'm wary about making that class part of the public API. I thought that the original idea was that users would be responsible of how they handle the "PrecisionContext". However, it seems that "Equivalency" requires equality of "PrecisionContext" instances (not the "double" value). This is n

Re: [numbers] Complex missing some C++ standards

Hi. Le dim. 29 déc. 2019 à 23:25, Alex Herbert a écrit : > > I’ve dropped the static equals methods and reciprocal and pushed the updated > class with MathJax. > > I put MathJax in whenever possible. This may be a bit too much. The rendered > javadoc looks good but the javadoc rendered by my ID

Re: [collections] bloom filters comments

Le dim. 29 déc. 2019 à 15:30, Claude Warren a écrit : > > If the Shape class (BloomFilter.Shape) is extracted from the BloomFilter > interface and made a stand-alone class would the name change or is the fact > that it is in the o.a.c.c.bloomfilter package enough? > > I prefer the name Shape to Bl

Re: [NUMBERS-96][GSoC-2020] Port and redevelop interpolation libraries from commons-math

Hi. 2019-12-28 19:59 UTC+01:00, Rishabh Budhouliya : > Hi everyone, > > I would like to know two things: > > 1) Which ported module/classes should I read and compare from commons-math > to understand the architectural decisions taken to use lambda functions, > streams etc all the FP paradigms in c

Re: [numbers] Complex missing some C++ standards

Hi. 2019-12-29 1:15 UTC+01:00, Alex Herbert : > > >> On 21 Dec 2019, at 11:42, Gilles Sadowski wrote: >> >>> ... >> >> So, would you suggest that no "Number"-like class should ever throw >> an exception (but instead return the equivalen

Re: [numbers] Complex missing some C++ standards

Hi. 2019-12-21 1:07 UTC+01:00, Alex Herbert : > > >> On 20 Dec 2019, at 23:45, Gilles Sadowski wrote: >> >> Le sam. 21 déc. 2019 à 00:05, Alex Herbert > <mailto:alex.d.herb...@gmail.com>> a écrit : >>> >>> Looking at the c++ standard [1] we

Re: [numbers] Complex missing some C++ standards

Le sam. 21 déc. 2019 à 00:05, Alex Herbert a écrit : > > Looking at the c++ standard [1] we are missing this function: > > norm() = a^2 + b^2 > > The field norm of the complex, or the square of the absolute. An example on > C++ reference states that this is faster for comparing magnitudes for ran

Re: [numbers] Complex.ofImaginary and multiplyI

Le jeu. 12 déc. 2019 à 16:23, Alex Herbert a écrit : > > > > OK. I'll remove ofReal() and ofImaginary(). > > > > They can always be added later. > > The same may apply to square(): > > public Complex square() { > return multiply(this); > } Sure. > > It could be defined differently: > > re =

Re: [numbers] Complex.ofImaginary and multiplyI

Le jeu. 12 déc. 2019 à 15:20, Alex Herbert a écrit : > > > On 12/12/2019 13:50, Gilles Sadowski wrote: > > Hello. > > > > Le jeu. 12 déc. 2019 à 10:04, Alex Herbert a > > écrit : > >> There is a factory constructor: > >> > >> Complex

Re: [numbers] Complex.ofImaginary and multiplyI

Hello. Le jeu. 12 déc. 2019 à 10:04, Alex Herbert a écrit : > > There is a factory constructor: > > Complex.ofReal(double) > > For completeness I think we should add: > > Complex.ofImaginary(double) I wonder whether we should remove "ofReal". It's a shortcut that does not save a lot of typing, I

Re: [commons-numbers] 02/03: Added getAbsolute() to complement getArgument().

2019-12-08 18:52 UTC+01:00, Alex Herbert : > > >> … > > Would this also apply to conjugate() and conj()? > > ISO C99 uses conj(). +1 (Why not?) Gilles - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional

Re: [commons-numbers] 02/03: Added getAbsolute() to complement getArgument().

Le dim. 8 déc. 2019 à 13:32, Alex Herbert a écrit : > > > > > On 8 Dec 2019, at 11:24, Gilles Sadowski wrote: > > > > Hi. > > > > 2019-12-08 10:45 UTC+01:00, Alex Herbert > <mailto:alex.d.herb...@gmail.com>>: > >> On Sun, 8 Dec 2019, 0

Re: [commons-numbers] 02/03: Added getAbsolute() to complement getArgument().

Hi. 2019-12-08 10:45 UTC+01:00, Alex Herbert : > On Sun, 8 Dec 2019, 01:50 Gilles Sadowski, wrote: > >> 2019-12-08 2:00 UTC+01:00, aherb...@apache.org : >> > This is an automated email from the ASF dual-hosted git repository. >> > >> > aherbert pushed a com

Re: [commons-numbers] 02/03: Added getAbsolute() to complement getArgument().

2019-12-08 2:00 UTC+01:00, aherb...@apache.org : > This is an automated email from the ASF dual-hosted git repository. > > aherbert pushed a commit to branch master > in repository https://gitbox.apache.org/repos/asf/commons-numbers.git > > commit 65f60835e2afe26bdaba9665d62edb25195bfff6 > Author:

Re: [numbers] Complex

Hi. Le ven. 6 déc. 2019 à 16:47, Alex Herbert a écrit : > > I think this method is redundant: > > public Complex multiply(final int factor) { > return new Complex(real * factor, imaginary * factor); > } > > given that there is: > > public Complex multiply(double factor) { > return new C

Re: [commons-numbers] 04/04: Preserve even function in cosh

Test failure here: ---CUT--- ERROR] Failures: [ERROR] CStandardTest.testCosh:692->assertComplex:275 Operation failed (z=(-Infinity,0.5)). Expected: (-Infinity,-Infinity) but was: (Infinity,-Infinity) ---CUT--- Gilles 2019-12-05 1:45 UTC+01:00, aherb...@apache.org : > This is an automated email

Re: [Geometry] Coveralls stuck

Le mar. 3 déc. 2019 à 19:21, Alex Herbert a écrit : > > > On 03/12/2019 16:43, Alex Herbert wrote: > > > > ... > > > > I am going to try option 1. > > Seems to be fixed now. Thanks! Gilles > > Alex > > - To unsubscribe, e-mail

<    4   5   6   7   8   9   10   11   12   13   >