Re: [Math] FastMath missing methods from java.lang.Math...

Hi. Le jeu. 27 mai 2021 à 11:32, Erik Svensson a écrit : > > Howdy all! > > > > I’m comparing FastMath with java.lang.Math and I notice that FastMath is no > longer Math-complete. > > Ie, jlM has methods that FastMath doesn’t have. Incidentally, that's why the unit test suite fails when

Re: [RNG] Multiple samplers, shared "UniformRandomProvider"

Le mer. 26 mai 2021 à 00:06, Alex Herbert a écrit : > > On Tue, 25 May 2021 at 20:15, Gilles Sadowski wrote: > > > Hi. > > > > I wonder if/how we would introduce the following functionality: > > ---CUT--- > > /** > > * @param rng Generato

[RNG] Multiple samplers, shared "UniformRandomProvider"

Hi. I wonder if/how we would introduce the following functionality: ---CUT--- /** * @param rng Generator that will be shared in the returned sampler. * @param list Samplers whose underlying generators will be discarded in * the returned instance. * @return a sampler

Re: [Math][Numbers][Geometry][Statistics] Road map for next release(s)

Le dim. 23 mai 2021 à 22:54, Alex Herbert a écrit : > > On Sun, 23 May 2021 at 15:58, Gilles Sadowski wrote: > > > > > I've created a multi-module[1] version of the code base with a > > corresponding JIRA issue: > > https://issues.apache.org/jira/browse/MAT

Re: [Math][Numbers][Geometry][Statistics] Road map for next release(s)

Le dim. 23 mai 2021 à 22:54, Alex Herbert a écrit : > > On Sun, 23 May 2021 at 15:58, Gilles Sadowski wrote: > > > > > I've created a multi-module[1] version of the code base with a > > corresponding JIRA issue: > > https://issues.apache.org/jira/browse/MAT

[Math][Numbers][Geometry][Statistics] Road map for next release(s)

Hi. Following recent discussions (with too few participants), no consensus emerged about the best way to support the [Math] component. I've created a multi-module[1] version of the code base with a corresponding JIRA issue: https://issues.apache.org/jira/browse/MATH-1575 The new layout of

Re: [math] working on increasing performance for Math3

the name. It should be a "core" module (independend of the "legacy" module). Regards, Gilles Le sam. 15 mai 2021 à 18:38, Gilles Sadowski a écrit : > > Le mer. 12 mai 2021 à 13:23, Erik Svensson a écrit > : > > > > Howdy all, > >

Re: [math] working on increasing performance for Math3

Le mer. 12 mai 2021 à 13:23, Erik Svensson a écrit : > > Howdy all, > > Irrespective of how it's implemented we would like to implement the > performance improvements possible to the commons-math lib. > While I can certainly fork the project and we could have our own version of > commons-math,

Re: [rng] Add ObjectSampler interfaces and a CompositeSampler

Hi Alex. Would the proposal be any different if with Java 8+ features? [IOW, is it still useful (in any sense) to stick with Java 6?] Regards, Gilles > [...] - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For

Re: [text][geometry] DoubleFormats utility

Hi. Le ven. 14 mai 2021 à 04:17, Matt Juntunen a écrit : > > Hello, > > Yes, the JDK definitely has number formatting capabilities. The class that I > propose moving to text was designed specifically for data IO operations, > where large numbers of doubles need to be serialized to strings in

Re: [math] working on increasing performance for Math3

Hi. Le mer. 12 mai 2021 à 13:23, Erik Svensson a écrit : > > Howdy all, > > Irrespective of how it's implemented we would like to implement the > performance improvements possible to the commons-math lib. > While I can certainly fork the project and we could have our own version of >

Re: [math] working on increasing performance for Math3

>> [...] > > It might make sense to update the FastMath Javadoc to clarify that the > main focus of the class is now accuracy (and portability?) rather than > speed. Done. > This should help manage user expectations. Yet the idea that though some API (TBD), an application could select which

Re: [math] working on increasing performance for Math3

Hello. Le sam. 8 mai 2021 à 08:42, Benjamin Marwell a écrit : > > Instead of using byte buddy, why not just maven multi release jars? *1 Thanks for the suggestion. Again, I don't know how to do it concretely[1] nor the implications (IIRC, the mention of multi-release JARs was frowned upon some

Re: [math] working on increasing performance for Math3

Hello. Le ven. 7 mai 2021 à 10:52, Erik Svensson a écrit : > > Howdy all! > > > > I’m looking to do some work on FastMath Thanks for your interest. > to increase performance by using java.lang.Math where it is applicable (ie > where there is an @HotspotIntrinsicCandidate annotation on the

Re: The case for a Commons component

Le jeu. 6 mai 2021 à 20:29, Oliver Heger a écrit : > > > > Am 05.05.21 um 21:54 schrieb Gilles Sadowski: > > Le mer. 5 mai 2021 à 20:33, Oliver Heger > > a écrit : > >> > >> > >> > >> Am 05.05.21 um 20:26 schrieb Gilles Sadow

Re: The case for a Commons component

> > [...] > >> > >> So a procedural vote requires a majority. > > > > There is a small majority (irrespective of the binding vs non-binding > > categories). > > In votes ONLY PMC member votes are counted. Other votes are > advisory. PMC members should take those votes into account > when voting.

Re: The case for a Commons component

Le jeu. 6 mai 2021 à 14:48, Emmanuel Bourg a écrit : > > Le 2021-05-06 13:06, Gilles Sadowski a écrit : > > > It is not nice to decide for others what they may need. > > It is not nice to suggest I shouldn't voice my opinions. Your argued opinion is welcome. In the te

Re: The case for a Commons component

Le jeu. 6 mai 2021 à 02:24, Emmanuel Bourg a écrit : > > Le 2021-05-05 20:31, Oliver Heger a écrit : > > > What about the sandbox? IIUC, every committer can start a new > > component there. If then a community forms around this component, it > > can move to proper (which would then require a

Re: The case for a Commons component

Le jeu. 6 mai 2021 à 07:53, Ralph Goers a écrit : > > > > On May 5, 2021, at 11:13 AM, Gilles Sadowski wrote: > > > > Le mer. 5 mai 2021 à 17:44, Ralph Goers a > > écrit : > >> > >> > >> > >>> On May 5, 2021, at 6:38 AM,

Re: The case for a Commons component

Le mer. 5 mai 2021 à 20:33, Oliver Heger a écrit : > > > > Am 05.05.21 um 20:26 schrieb Gilles Sadowski: > > Le mer. 5 mai 2021 à 18:57, Gary Gregory a écrit : > >> > >> IMO the lack of +1s shows the lack of appetite to manage another component > >

Re: The case for a Commons component

Le mer. 5 mai 2021 à 18:57, Gary Gregory a écrit : > > IMO the lack of +1s shows the lack of appetite to manage another component That's certainly true. And nobody is forced to do anything. When the other CM spin-offs started, there was only _one_ person willing to do the work. Gilles > [...]

Re: The case for a Commons component

Le mer. 5 mai 2021 à 17:44, Ralph Goers a écrit : > > > > > On May 5, 2021, at 6:38 AM, Gilles Sadowski wrote: > > > > Le mar. 4 mai 2021 à 02:49, Ralph Goers a > > écrit : > >> > >> I apologize. I started another thread regarding th

Re: Jacoco 0.8.7

Hi. Le mer. 5 mai 2021 à 13:11, Melloware a écrit : > > Jacoco 0.8.7 was released: Thanks for the info. > > https://github.com/jacoco/jacoco/releases/tag/v0.8.7 > > Any commons projects using Jacoco like BeanUtils2 should upgrade It seems that this is usually done through "Commons Parent":

Re: The case for a Commons component

les [1] Three Java implementations of the SOFM turned up as the top results of a web search; none seem to include multi-threading. [2] https://gitbox.apache.org/repos/asf?p=commons-graph.git > > Ralph > > > On May 2, 2021, at 3:59 PM, Gilles Sadowski wrote: > > > > Hi. >

Re: The case for a Commons component

Hello. Le lun. 3 mai 2021 à 08:53, Avijit Basak a écrit : > > Hi > > I would like to vote for *commons-ml*. Wrong thread, again. Sorry for the nit-picking, but whenever a vote is requested, it is often the basis of an official decision that must be traceable by other parties, such as

Re: [Vote] Create repository for "machine learning" algorithms.

Recording a vote in the proper thread on behalf of Avijit Basak (who inadequately posted his vote in two other threads). Le mer. 21 avr. 2021 à 19:05, Gilles Sadowski a écrit : > > [...] > > Name of component: "Commons Machine Learning" > Name of "git" reposito

Re: The case for a Commons component

Hi. > [... Discussion about GA data-structures...] I'd suggest that we finalize the [Vote] before getting into the details... Currently, there have been votes by: Emmanuel Bourg (-1) Sebastian Bazley (-0) Ralph Goers (+0) Paul King (+1) So currently, the discussion should be focused on

Re: The case for a Commons component

Le ven. 30 avr. 2021 à 17:40, Avijit Basak a écrit : > > Hi > > >>lot of spurious references to "Commons Numbers" > --I have only created the basic project structure. Changes > need to be made. Can anyone from the existing commons team help in doing > this. Wel, you should

Re: [Vote] Create a "machine learning" component

Le ven. 30 avr. 2021 à 18:00, Avijit Basak a écrit : > > Hi > > I would like to vote for *commons-ml*. Wrong thread (the vote on this one has been cancelled due to being idle for too long): The new vote is there: https://markmail.org/message/g5gwof3qdkzyvedc >>> [...]

Re: Redesign of Commons website generation (was: CMS Deprecated. Removal of configs and move to new publishing area)

Le jeu. 29 avr. 2021 à 01:45, sebb a écrit : > > On Thu, 29 Apr 2021 at 00:10, Gilles Sadowski wrote: > > > > It occurs to me that we *should* create a specific "git" repository > > for holding web site contents; having the "asf-site" and "asf-st

Re: Redesign of Commons website generation (was: CMS Deprecated. Removal of configs and move to new publishing area)

27 Apr 2021 at 17:03, Ralph Goers wrote: > > > > > > > > > On Apr 27, 2021, at 6:57 AM, Gilles Sadowski wrote: > > > > > > Le mar. 27 avr. 2021 à 12:32, sebb > > <mailto:seb...@gmail.com>> a écrit : > > >> > > >&

Re: The case for a Commons component

Le lun. 26 avr. 2021 à 16:18, Avijit Basak a écrit : > > Hi > > As per previous discussions, I have created a temporary repository > in GitHub under my personal GitHub Id(avijitbasak). The artifacts have been > copied from commons-numbers. A preliminary structure has been created for >

Re: Redesign of Commons website generation (was: CMS Deprecated. Removal of configs and move to new publishing area)

Le mar. 27 avr. 2021 à 12:32, sebb a écrit : > > On Tue, 27 Apr 2021 at 02:10, Gilles Sadowski wrote: > > > > >>> [...] > > > > > > > > OK to create the > > > > commons-site > > > > "git" repository? > &

Re: Redesign of Commons website generation (was: CMS Deprecated. Removal of configs and move to new publishing area)

>>> [...] > > > > OK to create the > > commons-site > > "git" repository? > > Are you offering to do the work? If the option is still on the table, I could test the website-related feature of ".asf.yaml":

Re: Redesign of Commons website generation (was: CMS Deprecated. Removal of configs and move to new publishing area)

Le lun. 26 avr. 2021 à 17:08, Ralph Goers a écrit : > > See below > > > On Apr 18, 2021, at 3:21 PM, sebb wrote: > > > > On Sun, 18 Apr 2021 at 18:40, Gilles Sadowski > <mailto:gillese...@gmail.com>> wrote: > >> > >> Le dim. 18 avr. 2021

Re: The case for a Commons component

Le lun. 26 avr. 2021 à 17:08, Ralph Goers a écrit : > > How many committers will be active for this component? No less than there were for [RNG], [Numbers] and [Geometry]. ;-) Those new components have attracted high-quality contributions; two of the people who provided them have become

Re: The case for a Commons component

"place" will of course pave the way to a self-fulfilling prophecy. Gilles > On Sat, 24 Apr 2021 at 23:32, Paul King wrote: > > > > Thanks Gilles, > > > > I can provide the same sort of stats across a clustering example > > across commons-math

Re: Redesign of Commons website generation (was: CMS Deprecated. Removal of configs and move to new publishing area)

Hi. [Not replying to the previously last message in the thread but a heads-up following Bruno's reminder about ".asf.yaml" and Ralph's mention of it earlier in this thread.] Could we start from the bottom-up, i.e. create a git repository for hosting each component's web site? Then we can

Re: The case for a Commons component

h (a.o. things) multi-threading (in much the same way as for GA, I guess). Best regards, Gilles [1] https://issues.apache.org/jira/browse/MATH-1515 [2] Fixes and enhancements are already in CM "master" branch. > > Cheers, Paul. > > On Sun, Apr 25, 2021 at 8:15 AM Gilles Sa

Re: [RNG][Geometry] TriangleSampler and other shape samplers

Le sam. 24 avr. 2021 à 23:32, Alex Herbert a écrit : > > On Sat, 24 Apr 2021 at 17:36, Matt Juntunen > wrote: > > > This is very interesting. With this amount of geometry code, I could > > picture this as part of a commons-geometry-rng module. The SurfaceSampler, > > for example, could make use

The case for a Commons component

Hello Paul. Le sam. 24 avr. 2021 à 04:42, Paul King a écrit : > > I added some more comments relevant to if the proposed algorithm > belongs somewhere in the commons "math" area back in the Jira: > > https://issues.apache.org/jira/browse/MATH-1563 Thanks for a "real" user's testimony. As the

Re: [RNG][Geometry] TriangleSampler and other shape samplers

Le ven. 23 avr. 2021 à 23:42, Alex Herbert a écrit : > > I recently added a UnitBallSampler to the sampling module to sample > coordinates inside a unit ball. I also have a working TriangleSampler to > sample within a triangle and intend to create a TetrahedronSampler to > sample within a

[Vote] Create repository for "machine learning" algorithms.

Hi. [This a reboot of the proposal for which the preceding vote has just been cancelled.] Name of component: "Commons Machine Learning" Name of "git" repository: "commons-machinelearning" Top-level package name: "org.apache.commons.machinelearning" Component rationale and scope (copied verbatim

[Cancel][Vote] Create a "machine learning" component

>>> [...] > > > > So currently, IIRC the tally (on creating a dedicated component) is > > Gilles Sadowski +1 > > Avijit Basak +1 > > Paul King +1 > > And several -1 on the initially suggested name; but the proposed > > name has been changed

Re: [Vote] Create a "machine learning" component

; Fair enough. I am +1 (non-binding). So currently, IIRC the tally (on creating a dedicated component) is Gilles Sadowski +1 Avijit Basak +1 Paul King +1 And several -1 on the initially suggested name; but the proposed name has been changed early on to "commons-machinelearning&q

Re: [Vote] Create a "machine learning" component

odebase. This doesn't preclude that other committers might want to do that for you; however judging by the last 5 years, I wouldn't count too much on it. ;-) Regards, Gilles > > > Thanks & Regards > --Avijit Basak > > On Mon, 19 Apr 2021 at 18:51, Gilles Sadows

Re: [geometry] 1.0-beta2

Hi Alex. Le mar. 20 avr. 2021 à 11:17, Alex Herbert a écrit : > > [...] I'm a bit lost in all these bits... ;-) > Any opinions on how changing LinearComination may affect Geometry? Either > we clean up the implementation to use the fast dot2s algorithm with correct > support for splitting

Re: [geometry] 1.0-beta2

Le lun. 19 avr. 2021 à 20:26, Matt Juntunen a écrit : > > Hi Gilles, > > Are you suggesting skipping another beta version and having numbers 1.0 and > geometry 1.0 be the next releases? Yes, that's the question which I'm asking. There is no point in waiting much longer for feedback that may

Re: [geometry] 1.0-beta2

Hello Matt. Le lun. 19 avr. 2021 à 15:20, Matt Juntunen a écrit : > > I'd like to release commons-geometry 1.0-beta2 within the next couple of > weeks. I'm planning on including GEOMETRY-118 (additional methods for > transform matrix classes) in that if possible. Is there anything else anyone

Re: [Vote] Create a "machine learning" component

Hello. Le lun. 19 avr. 2021 à 08:35, Avijit Basak a écrit : > > Hi > > >Isn't a GA inherently parallel? > >If so, why not take advantage of the concurrency tools provided by the JDK? > -- Are we planning to implement multi-threading for GA operations even as > part of a single population This

Re: Redesign of Commons website generation (was: CMS Deprecated. Removal of configs and move to new publishing area)

proper component POM > will need updating, and existing checkouts will need replacing. > At least it's a one-off change, and it won't change processes, except > perhaps for the top-level site. > > > > Gary > > > > > > On Sun, Apr 18, 2021, 08:27 Gilles Sadow

Re: Redesign of Commons website generation (was: CMS Deprecated. Removal of configs and move to new publishing area)

Le dim. 18 avr. 2021 à 12:51, sebb a écrit : > > On Sun, 18 Apr 2021 at 00:03, Ralph Goers wrote: > > > > > > > > > On Apr 17, 2021, at 3:32 PM, sebb wrote: > > > > > > On Sat, 17 Apr 2021 at 22:57, Ralph Goers > > > wrote: > > >> > > >> > > >> When I release

Re: Redesign of Commons website generation (was: CMS Deprecated. Removal of configs and move to new publishing area)

e repository?[1] Regards, Gilles [1] The "Manage the Git Hosted Web Site" link on https://github.com/apache/logging-site points to https://cwiki.apache.org/confluence > > Ralph > > > > > On Apr 16, 2021, at 5:27 AM, sebb wrote: > > > > On T

Re: Redesign of Commons website generation (was: CMS Deprecated. Removal of configs and move to new publishing area)

Hi. Le ven. 16 avr. 2021 à 15:15, sebb a écrit : > > On Fri, 16 Apr 2021 at 13:40, Gilles Sadowski wrote: > > > > Hi. > > > > Le ven. 16 avr. 2021 à 14:28, sebb a écrit : > > > > > > On Thu, 15 Apr 2021 at 14:41, Gilles Sadowski > >

Re: Redesign of Commons website generation (was: CMS Deprecated. Removal of configs and move to new publishing area)

Hi. Le ven. 16 avr. 2021 à 14:28, sebb a écrit : > > On Thu, 15 Apr 2021 at 14:41, Gilles Sadowski wrote: > > > > Hello. > > > > [Sorry for jumping into the discussion while missing the meaning of > > most of what is being said (and cutting it).] >

Re: [jira] [Closed] (STATISTICS-30) Gain Marks in Oracle Certified - 1Z0-997-20 Dumps PDF [2021] - Prepare4test

Hello Alex. Le ven. 16 avr. 2021 à 13:27, Alex Herbert (Jira) a écrit : > > > [ > https://issues.apache.org/jira/browse/STATISTICS-30?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel > ] > > Alex Herbert closed STATISTICS-30. > -- >

Re: CMS Deprecated. Removal of configs and move to new publishing area

Hello. [Sorry for jumping into the discussion while missing the meaning of most of what is being said (and cutting it).] > [...] > > So why cause additional work for projects that no longer use the CMS? > > I repeat, projects hopped on to the SVN area of the CMS , that is unsupported > and

Re: [Vote] Create a "machine learning" component

ar component. https://github.com/apache/commons-rng https://github.com/apache/commons-numbers https://github.com/apache/commons-geometry https://github.com/apache/commons-statistics > > Thanks & Regards > --Avijit Basak > > > On Tue, 13 Apr 2021 at 18:29, Gilles Sadowski w

Re: [Vote] Create a "machine learning" component

Hello. Le lun. 12 avr. 2021 à 17:21, Avijit Basak a écrit : > > Hi > > Sorry for the delayed response. Thanks for your patience. Please > find my comments below: > > (1) Why not Spark? [At least post over there (?).] > --We can move to Spark. But it will be very much useful if

Re: GitHub license display confused by LICENSE-header.txt

Le mar. 9 mars 2021 à 11:58, sebb a écrit : > > On Tue, 9 Mar 2021 at 01:39, Gilles Sadowski wrote: > > > > Le mar. 9 mars 2021 à 01:41, sebb a écrit : > > > > > > Most of the Commons projects show up in GitHub as having the Apache 2.0 > > > Licens

Re: GitHub license display confused by LICENSE-header.txt

Le mar. 9 mars 2021 à 01:41, sebb a écrit : > > Most of the Commons projects show up in GitHub as having the Apache 2.0 > License > > However a few show up as 'other': > > commons-codec > commons-csv > commons-dbutils > commons-exec > commons-jelly > commons-logging > commons-math > commons-rdf

Re: [crypto] Interest in adding support for cryptographic hash function?

Le sam. 27 févr. 2021 à 19:00, Bernd Eckenfels a écrit : > > Hello, > > I don’t think it’s a Good idea to introduce native dependencies to formerly > pure Java projects. +1 [I thought that the idea was a (pure) Java implementation.] > So i think native optimized hash implementations would fit

Re: [crypto] Interest in adding support for cryptographic hash function?

Hi. Le sam. 27 févr. 2021 à 15:51, Alex Remily a écrit : > > I'm working on a project that makes heavy use of hashing, and I'd like to > use the OpenSSL implementation. Thoughts on adding support for the SHA-2

Re: [STATISTICS] Truncated Normal Distribution

Hello. Le ven. 19 févr. 2021 à 08:43, Marko Malenic a écrit : > > Hi Gilles, > > Thanks, I've sent that through, and opened a pull request on the > commons-statistics github page. Thanks! Nit-pick: When you've implemented the changes suggested by Alex, please mention the JIRA identifier in the

Re: [STATISTICS] Truncated Normal Distribution

Hi. Le ven. 19 févr. 2021 à 00:59, Marko Malenic a écrit : > > Hi Gilles, > > Do I need to sign a contributor license agreement for this? Yes, it is preferable.[1] Thank you for asking. Regards, Gilles [1] http://www.apache.org/licenses/contributor-agreements.html > > [...]

Re: [STATISTICS] Truncated Normal Distribution

Hello. Le mer. 17 févr. 2021 à 04:25, Marko Malenic a écrit : > > Hi all, > > I've completed an implementation of a truncated normal distribution for > commons-statistics, > as described by: > https://issues.apache.org/jira/browse/STATISTICS-27 > at: >

Re: [Vote] Create a "machine learning" component

will do it?] (3) Modularize CM? [Who will do it?] (4) New component (with another name) with the proposed contents? To make things clear from my side: As a *user*, I've currently some stake at having a clean, independent "ml" component or an independent "sofm" module. So I

Re: [Vote] Create a "machine learning" component

Le mer. 10 févr. 2021 à 13:19, sebb a écrit : > > Likewise, commons-ml is too cryptic. > > Also, the Spark project has a machine-learning library: > > https://spark.apache.org/mllib/ Thanks for the pointer. > > Maybe that would be better home? On the face of it, probably. [For sure, Avijit

Re: [Vote] Create a "machine learning" component

Le mer. 10 févr. 2021 à 09:27, Emmanuel Bourg a écrit : > > -1 for commons-ml for the same reasons. > > What about commons-machine-learning or commons-math-learning? The latter > is as long as commons-configuration. Java users should be used to lengthy names. It should thus be

[Vote] Create a "machine learning" component

Hi. Because of an offered contribution, a discussion happened on JIRA[1] and in another thread[2] about improving the genetic algorithm (GA) implementation currently in the org.apache.commons.math4.genetic package of the "Commons Math" component. It would make sense to group "machine learning"

Re: [lang] Introduce @NonNull, and @Nullable

Le lun. 1 févr. 2021 à 14:49, Jochen Wiedmann a écrit : > > On Mon, Feb 1, 2021 at 2:34 PM Gary Gregory wrote: > > > 1) Don't add and use custom annotations, this opens the door to each of our > > 20+ components doing the same thing, so pick a library and stick with it. > > I suggested starting

Re: [lang] Introduce @NonNull, and @Nullable

Le lun. 1 févr. 2021 à 14:34, Gary Gregory a écrit : > > My concerns are: > > 1) Don't add and use custom annotations, this opens the door to each of our > 20+ components doing the same thing, so pick a library and stick with it. +1 > 2) Make sure there are no licensing issues with that

[Vote] New "git" repository (Was: [All][Math] New GA component)

Hello. Assuming lazy consensus[1], please state any objection to creating a new repository that will host the GA-related functionality (spin-off from "Commons Math"). More context on JIRA.[2] I'll take care of setting up the new component (a.o. moving the relevant codes over to the new

Re: [geometry] IO Modules

quot;cube.obj"))' This would just work (the devil being in the details) with the hypothetical "handlers.conf" file containing: ---CUT--- formats=OBJ OBJ.extensions=obj,OBJ OBJ.reader=org.apache.commons.geometry.io.euclidean.threed.ObjFormatReader ---CUT-- Regards, Gilles >

Re: NPE in CSVFormat

Le jeu. 28 janv. 2021 à 02:30, Gary Gregory a écrit : > > You can't attach files to this mailing list. > > You'll have to figure out GitHub PRs so we can see what you're proposing to > do ;-) Or use JIRA... But about the issue itself: Hasn't "Commons Logging" been superseded by the "Log4j"

Re: [math] FastMath isn't fast...

Hi. Le mer. 27 janv. 2021 à 17:39, Erik Svensson a écrit : > > Hello all! > > I work for a fintech company and we do a lot of risk computations using, > among other things, FastMath. > Recently I had the opportunity to do some performance testing using JMH and > found, to my surprise, that

Re: [geometry] IO Modules

Hi. Le ven. 22 janv. 2021 à 03:38, Matt Juntunen a écrit : > > Hi Gilles, > > > Really, the main point is to separate format (contents) from filename > > (container). > > This makes sense. What would you think of the approach below? I have no strong objections, as I do not graps all the

Re: [geometry] IO Modules

also make the difference pointed out above: https://docs.oracle.com/javase/7/docs/api/javax/imageio/ImageIO.html#getImageReadersByMIMEType(java.lang.String) https://docs.oracle.com/javase/7/docs/api/javax/imageio/ImageIO.html#getImageReadersBySuffix(java.lang.String) Sorry if I've cut some corners.

Re: [geometry] IO Modules

t I would think at a higher level; mapping to either the "enum", or to custom code. > For example, we will soon be creating a custom geometry format for an > application at my day job and I would like to be able to use these IO modules > to read and write that format (using custom Boundar

Re: [geometry] IO Modules

Hi Matt. Le mer. 20 janv. 2021 à 05:03, Matt Juntunen a écrit : > > Hello, > > I've created GEOMETRY-115 and an associated PR [1] containing new modules for > IO functionality. The new modules are > > * commons-geometry-core-io - Common space-independent interfaces and > classes > *

Re: [All][Math] New GA component

Hello. Le mer. 20 janv. 2021 à 11:11, Avijit Basak a écrit : > > Hello Gilles Sadowski > > Thanks for your reply. Yes I intend to contribute to enhancement > of the GA functionality as per the JIRA (MATH-1563) proposal. My proposal was to first create a new compo

[All][Math] New GA component

Hi Avijit. [I've changed the "Subject:" line.] Le mar. 19 janv. 2021 à 08:31, Avijit Basak a écrit : > > Hello Gilles Sadowski > > I have extended the current implementation of Genetic Algorithm in > a.c.m package and made the probability generation process a

Re: [All][Math] GH PR and Travis-CI

che/commons-math/builds/210145524 > > but the build result is not shown in github. > > Maybe it's just a accidental error and we can have a look till next PR? > > > > cheers, > > Lee > > > > > > On 12 21 2020, at 11:31, Gilles Sadowski wrote:

[All][Math] GH PR and Travis-CI

Hi. Does someone know why PRs don't seem to trigger a Travis build anymore? Example: PR https://github.com/apache/commons-math/pull/168 is not picked up here: https://travis-ci.com/github/apache/commons-math/pull_requests while nothing has changed in

Re: [All][Math] A Proposal for Implementation of Adaptive Probability Generation Strategy for Genetic Algorithm

lternative Java projects that provide GA). Thanks, Gilles Le ven. 18 déc. 2020 à 16:56, Gilles Sadowski a écrit : > > Le ven. 18 déc. 2020 à 16:25, Avijit Basak a écrit : > > > > Hi All > > > > I would like to propose incorporation of adaptive probability >

[All][Math] A Proposal for Implementation of Adaptive Probability Generation Strategy for Genetic Algorithm

Le ven. 18 déc. 2020 à 16:25, Avijit Basak a écrit : > > Hi All > > I would like to propose incorporation of adaptive probability > generation strategy for Genetic Algorithm implementation of apache commons > maths library. > Currently Apache's API works on constant probability

Re: [geometry] Parse error type

Hello Matt. Le ven. 18 déc. 2020 à 16:16, Matt Juntunen a écrit : > > Hi all, > > I've created a simple text parser Did you consider leaving that job to a specialized tool[1] ? Because... > class [1] as part of writing the 3D file format IO functionality for > GEOMETRY-101. One of the primary

Re: [geometry] Rename BoundarySource factory methods

Le jeu. 17 déc. 2020 à 03:48, Matt Juntunen a écrit : > > Hi all, > > I opened GEOMETRY-109 to rename the BoundarySource2D and BoundarySource3D > "from()" static factory methods to "of()" to be more in line with the JDK's > similar Stream.of() method. I also think it better reflects the

Re: [MATH] - Truncated Normal Distribution

Hello. Le mar. 1 déc. 2020 à 06:02, Marko Malenic a écrit : > > Awesome. > > Should I submit a jira ticket for this? Yes. https://issues.apache.org/jira/browse/STATISTICS Regards, Gilles > > On Tue, Dec 1, 2020 at 12:11 PM Gilles Sadowski > wrote: > > > Hello.

Re: [MATH] - Truncated Normal Distribution

Hello. Le mar. 1 déc. 2020 à 01:42, Marko Malenic a écrit : > > Hi, > > I'm a bit new to all this stuff, so bear with me while I ask some questions > :) > > There's a few ways to do this. > > In terms of number generation, there's a few algorithms, some of which at > described at: >

Re: [MATH] - Truncated Normal Distribution

Hello. Le lun. 30 nov. 2020 à 08:22, Marko Malenic a écrit : > > Hi all, > > I'm interested in contributing here, and have been wanting to implement and > add a truncated normal distribution. Would anyone be interested in this? Contributions welcome. ;-) This would be an addition for the new

Re: [apache/commons-codec] (doc) Remove duplicate "from"s in javadoc comments (#66)

> > > > > [...] > > > > > This is an open-source project and to me that means being open *and* > > > > > transparent. > > > > > > > > I agree, but that's beside my point: You require undue work from a > > > > committer. People who want/need to engage in history tracking will > > > > need to turn

Re: [apache/commons-codec] (doc) Remove duplicate "from"s in javadoc comments (#66)

Le jeu. 26 nov. 2020 à 16:04, Gary Gregory a écrit : > > On Thu, Nov 26, 2020 at 10:00 AM Gilles Sadowski > wrote: > > > Gary, > > > > Le jeu. 26 nov. 2020 à 15:47, Gary Gregory a > > écrit : > > > > > > On Thu, Nov 26, 2020 at 9:43 AM

Re: [apache/commons-codec] (doc) Remove duplicate "from"s in javadoc comments (#66)

Gary, Le jeu. 26 nov. 2020 à 15:47, Gary Gregory a écrit : > > On Thu, Nov 26, 2020 at 9:43 AM Gilles Sadowski > wrote: > > > Hello Gary. > > > > Le jeu. 26 nov. 2020 à 15:09, Gary Gregory a > > écrit : > > > > > > Please update changes.xml

Re: [apache/commons-codec] (doc) Remove duplicate "from"s in javadoc comments (#66)

Hello Gary. Le jeu. 26 nov. 2020 à 15:09, Gary Gregory a écrit : > > Please update changes.xml when you merge a PR. Since when do we require that for Javadoc clean-up? Regards, Gilles - To unsubscribe, e-mail:

Re: [commons-codec] branch master updated: Track changes

Hello. Le jeu. 26 nov. 2020 à 15:22, Gary Gregory a écrit : > > May you please show the PR number in the description? See the first action > in the list. This will give us better provenance for changes. At first thought, I don't see that this info belongs in the "changes" file. [Rationale:

Re: Hello Apache Commons :)

Hello. Le mar. 24 nov. 2020 à 21:10, Kanak Sony a écrit : > > Hey all, > > I am very new to OSS Contribution and would like to help. Welcome. > Is there > anything that I can start with and pick up? Many things! ;-) A general approach would be to review the bug-tracking project of the

Re: Dependabot pr's

It would be so great to be able to act differently (i.e. redirecting to *different* lists) depending on whether the sender is a bot or a human being. This used to be considered a feature (cf. "robots.txt" for web crawlers). Gilles Le ven. 16 oct. 2020 à 14:36, Rob Tompkins a écrit : > > I’m a

Re: Dependabot pr's

Hi. Le jeu. 15 oct. 2020 à 19:57, Bernd Eckenfels a écrit : > > Before we do that, I need help. I am considering to ignore or unsubscribe the > commit mailing list. Which is IMHO not a good thing (from the point of > security reviews). However I cannot keep up with dependable suggestions (and

Re: JUnit assertAll and assertThrows question

Hi. Le jeu. 15 oct. 2020 à 17:29, Alex Herbert a écrit : > > > > > On 15 Oct 2020, at 15:56, John Patrick wrote: > > > > <— snip --> > > > > Will look at vfs and maybe also rng regarding tidying up the tests etc. > > Did you mean ’tidying up math’? > > Regarding RNG, [...] I fully concur with

<    1   2   3   4   5   6   7   8   9   10   >