[MATH] ComplexUtils pull request; some future proposals

Dear all, Thanks for the feedback on ComplexUtils and I have submitted a pull request with the edits. I have added functionality to convert between Complex arrays and real double, real float, interleaved double, interleaved float, split double (one real, one imag) and split float arrays. Per

Re: [MATH] ComplexUtils pull request; some future proposals

On 30/10/15 02:15, Gilles wrote: There are some problems with the Javadoc (wrong "@return" comment). Not all local variables that are constant are declared "final". I am happy to give it all another proof read. I take it the procedure is to fork the dedicated branch and then submit a pull

Re: [MATH] ComplexUtils pull request; some future proposals

On 30/10/15 02:35, Gilles wrote: Unless I'm mistaken, there is no report on the project's bug-tracking system: https://issues.apache.org/jira/browse/MATH Could you please open one? I see that I need someone to assign me the create issue project permission. Can I request that here?

Re: Issue using git checkouts of commons(-math) in Eclipse

5/10/2015 00:13, Eric Barnhill a écrit : > > When I check out the commons-math repo from git and import into Eclipse, > > the package structure causes errors. Because the dir structure is > > src/main/java/org/apache etc., Eclipse throws an error on all import > >

Issue using git checkouts of commons(-math) in Eclipse

When I check out the commons-math repo from git and import into Eclipse, the package structure causes errors. Because the dir structure is src/main/java/org/apache etc., Eclipse throws an error on all import statements beginning with "org.apache" . It is looking for import statements that begin

[MATH] Complex.getInterleaved()

Dear commons-math.complex maintainers, I would like to add a static method to the Complex class that would work as follows: double[] d = Complex.getInterleaved(Complex[] c); It would export the data from a Complex[] as a double[] twice the size of the Complex[] array with real and imaginary

Re: [MATH] Complex.interleaved2Complex()

Bruce and Gilles, Thanks for thinking through the problem so well. Your suggestions sound like a good way to do. For method names, I agree that accessor names are not right. I propose sticking with the convention I see currently in ComplexUtils e.g. polar2Complex. That's a fairly typical

MathArrays -> JogAmp -> OpenCL

Is anyone interested in some GPU support for MathArrays by using, say, the JogAmp bindings and OpenCL methods. I have implemented such an architecture for my own convolution library I am developing, and it would not be much trouble for me to add this kind of support for commons-math some time in

Re: MathArrays -> JogAmp -> OpenCL

, up on my GitHub page some time next week, and link to it here, and then you can see what you think. Eric On 25/11/15 09:20, luc wrote: Le 2015-11-24 22:26, Gilles a écrit : On Tue, 24 Nov 2015 20:58:14 +0000, Eric Barnhill wrote: Is anyone interested in some GPU support for MathArrays by u

[MATH] Comment request for MATH-1291 and MATH-1292: Patches to ComplexUtils and LaguerreSolver to match proposed ComplexUtils nomenclature

I have filed two trivial JIRA issues, MATH-1291 and MATH-1292 and request comment. I would like to replace a current method "convertToComplex" with "real2Complex" so that it matches the nomenclature of the other proposed methods for ComplexUtils currently in my fork (these are in issue

Re: [Math] Commons Math (r)evolution

On Wed, Jun 8, 2016 at 12:08 AM, Gilles wrote: > Which parts of Commons Math would be dependencies for this type > of applications? > Which algorithms of your applications would be generic enough to > warrant becoming part of a toolbox based on the "Complex" class?

Re: [Math] Commons Math (r)evolution

he > last 2 months: > * Gilles74 > * Artem Barger 20 > * sebb 15 > * Rob Tompkins 9 > * Eric Barnhill 7 > * 19 other people 46 > 3. development/maintenance activity in the last 4 months: > * com

Proposed changes to Complex method nomenclature

I propose some minor changes in Complex() methods nomenclature for 4.0 . These relate to the collection of methods abs(), getArgument(), getReal() and getImaginary() . Personally I switch frequently and freely between Cartesian and polar representations of complex numbers in my code. So to me it

Re: Proposed changes to Complex method nomenclature

On 31/05/16 14:12, Gilles wrote: Short as can be and close to math notation. Another possibility may be to keep long names and to add syntactic sugar such as - public static double im(Complex c) { return c.getImaginary(); } - I have been looking at std::complex to get some

Re: [VOTE] New component: Complex numbers

+1 although some of the transforms are on the reals, so this may need to be nuanced later On Tue, Jun 21, 2016 at 9:31 PM, Gilles wrote: > Hello. > > This is one of several votes for establishing new Commons components > out of functionality developed inside the

Re: [VOTE] New component: Rational numbers

+1 this seems like a useful and self-contained functionality that is not in the Java API On Wed, Jun 22, 2016 at 8:26 AM, Jochen Wiedmann wrote: > -0 > > (I keep insisting, that we finish the organizational things first, so > that CM can take such decisions without

Re: [MATH] what a commons-TLP split could look like

On Tue, Jun 21, 2016 at 12:45 AM, Gilles wrote: > Mostly yes, but some utilities are used by packages that would > be good components (e.g. "o.a.c.m.distribution"). For example, > an efficient and robust root solver ("BrentSolver"). > The analysis library is

Re: [Math] Getting things done

There has been a lot of support in the discussions for, as Emmanuel put it, a "base commons-math component". Where does that factor into this proposal? On Thu, Jun 23, 2016 at 2:33 PM, Jochen Wiedmann wrote: > Hi, > > I'd like an attempt to put an end to all those

Re: [Math] Getting things done

Jochen Wiedmann <jochen.wiedm...@gmail.com> > wrote: > > > > It doesn't, at least in my opinion. If the future Math project decides > > to have a "base" component: Very well. But, if the other components > > are elsewhere: Why should the base stay at Commo

Re: [MATH] MATH-1378: KMeansPlusPlusClusterer optimize seeding procedure.

I use kmeans a bit and I will look at it. On Thu, Jun 23, 2016 at 2:10 PM, Artem Barger wrote: > Hi all, > > While I understand there is a project decision threads are going on ML, > however I'd like to suggest and provide some improvements of CM kmeans++ > implementation in

[MATH] what a commons-TLP split could look like

Here's a proposed draft for how o.a.c.m might be split into a commons component, and more sophisticated spin-out components, around which we might develop a new Math TLP or incubator project in which components of the project that find backers continue on, and those that do not are frozen at their

Re: [MATH] what a commons-TLP split could look like

Like I said, my untrained eye. Sounds like it should definitely be kept. Eric On Mon, Jun 20, 2016 at 11:47 AM, sebb <seb...@gmail.com> wrote: > On 20 June 2016 at 10:31, Eric Barnhill <ericbarnh...@gmail.com> wrote: > > Here's a proposed draft for how o.a.c.m might be

Re: [MATH] what a commons-TLP split could look like

I think I made a respectable case for such a split in my thread titled apache,commons,math . Perhaps you could identify some points in that post that you disagree with? That's what others did. On Tue, Jun 21, 2016 at 9:30 AM, Jochen Wiedmann wrote: > > > Whoever would

Re: [math] Go back to the basics

On Thu, Jun 23, 2016 at 3:54 PM, Dimitri Pourbaix wrote: > > What about the actual users? What do they/we want? My first guess would > be that most of them simply do not want to have to reinvent the wheel +1

apache, commons, math

I am new to protocols here and not sure which thread to jump on. But I am quite interested in the viability of the math project and hope the following observation is helpful. I think one reason people are talking past each other in this debate is because those outside the commons-math community

Re: [RESULT] [math] Name of the new TLP

Congratulations to the math team for the exciting news of starting the new TLP. Sorry to have promised some developments in December that I have not yet delivered. Our immigration situation changed and we had to move overseas. I should get the contributions out of the docket this month. -Eric

Re: [math] New finite differencing framework for math4

Dear Fran, this is very interesting especially the bandwidth control which I would find useful. I will be happy to look this code over and test it on some problems in my field. Right now that will be in a month or two due to some personal issues. I added a couple of questions to the JIRA.

[MATH] patch for MATH-1290

I have submitted a patch for MATH-1290 " Additions to Complex Utils" for the consideration of the committers. It includes both ComplexUtils.java and ComplexUtilsTest.java which runs JUnit tests on all methods. Let me know what else is needed, Eric

[MATH] adding maven repo for math4 to other projects

Right now my projects that use commons-math4 are compiled using Eclipse's "Configure Build Path" feature. I would like to change over to using maven builds, however I don't see a publicly available repo for math4 that I can add to the POM. Consequently I am running "maven package" in my

Re: [Math] Changes to ComplexUtils

Apologies for the 3 months' delay but we had to move to a new country and I didn't feel I had the time to contribute. If you don't mind me picking up where I left off, I went through ComplexUtils and took the following steps: Per request of the committers, I have done a thorough proofread

Re: [Math] About MATH-667 (Complex numbers)

That is interesting. I'd be happy to work on synchronizing the way commons-math and octave handle complex numbers for a next project. JIRA is on some kind of spam shutdown with no letup in sight, so... My latest pull followed your instructions including tracking the branch. However I thought

Re: [ALL] Performance of foreach loop with arrays.

the index, than redesign the iteration. However I would be happy to stick with iterators as a matter of style in apache commons. On Tue, May 17, 2016 at 7:04 AM, Eric Barnhill <ericbarnh...@gmail.com> wrote: > I have a related story. There is a class in commons-math 4.0 called >

Re: [ALL] Performance of foreach loop with arrays.

I have a related story. There is a class in commons-math 4.0 called IntegerRange. Stylistically I much prefer Iterating over such a range than C style loops and was ready to convert. However I found it many times slower, at least in not terribly rigorous home micro-benchmarking. Any good reason

Re: [Math] About MATH-667 (Complex numbers)

Reading over the discussion, there were some contrasting views about which of the common complex number behaviors Complex() ought to emulate. One commentator suggested GNU Octave. My quick take is that Octave has some good momentum right now, with its new editor and it's GSOC presence, and

Re: [Math] "Help wanted!" Or not (?)

I don't see commons-math as legacy code. Just to look around my corner of the world, ImageJ has a solid place in the biomedical imaging world and commons-math is its workhorse. Second, I think Java is, or should be anyway, a natural step outside of scientific computing environments like Matlab

Re: [rng] New repository for "Commons Rng"

what is the link? I searched for this repo on github, but can't see it there. Sorry if you put the link in a thread I can't find. On Mon, Aug 8, 2016 at 6:03 PM, Gilles wrote: > On Mon, 08 Aug 2016 03:10:13 +0200, Gilles wrote: > >> Hi. >> >> A new git repository

Re: [RESULT][VOTE] New component: Standard math functions

+1 On 03/07/16 16:12, Gilles wrote: Vote thread: http://markmail.org/message/xisnvgq7f5w7c6o2 +1 Gilles Sadowski Artem Barger Rob Tompkins Venkatesha Murthy +0 Benedikt Ritter Stian Soiland-Reyes Feel free to fill in any missing names. People who forgot to vote are welcome to do so. :-)

Re: [RESULT][VOTE] New component: Random number generators

+1 On 03/07/16 16:13, Gilles wrote: Vote thread: http://markmail.org/message/qxwpdxb2z3h7omxz +1 Gilles Sadowski Emmanuel Bourg Benedikt Ritter Brent Worden Stian Soiland-Reyes Artem Barger Rob Tompkins Feel free to fill in any missing names. People who forgot to vote are welcome to do so.

Re: [Numbers] Scope?

I agree the solvers don't seem to be in the scope. The MathArrays are a great idea but could use some rethinking. First of all there are leftover references to classes like Field that have disappeared with the larger math framework and these should go. Also, there are a lot of basic array-wise

Re: [Numbers] Scope?

On Mon, Jan 30, 2017 at 12:51 PM, sebb wrote: > > > Also, there are a lot of basic array-wise operations that might benefit > > from inclusion. To pick an example at random, element-by-element cosine. > In > > fact I already have a whole library of these (very simple) methods

Re: [Numbers] Java version? (Was: Scope?)

Okay. I will catch myself up on Lambdas and come back with a proposal for this class at that time. Eric On Tue, Jan 31, 2017 at 3:05 AM, Gary Gregory wrote: > +1 on Java 8. > > Gary > > On Mon, Jan 30, 2017 at 5:25 PM, Gilles > wrote: > >

Re: [LANG] LANG-1252 - NumberUtils.isNumber and NumberUtils.createNumber resolve inconsistently

> Implementation thoughts: > (1) Switch implementation “isNumber” -> “isParsable” > (2) Deprecate “isNumber” and have it call “isParsable" > (3) Rename “createNumber” to “parseNumber” (with Deprecation) > (4) Fix subtle differences between “parseNumber” and newly implemented > “isParsable" > (5)

Re: [RNG] Release of v1.0: Schedule update

On Fri, Oct 7, 2016 at 8:54 AM, Jörg Schaible < joerg.schai...@bpm-inspire.com> wrote: > Dave Brosius wrote: > > > I'd just release it, and > > get some momentum going. > +1

Re: [ALL] Git repository for a sandbox component?

Speaking for myself either is fine. I find svn commands easier to deal with than git, but github is easy to use as a site. Eric On Sat, Nov 5, 2016 at 4:43 PM, Gilles wrote: > On Sat, 5 Nov 2016 09:53:01 -0500, Matt Sicker wrote: > >> Is this a vote of some sort

Re: [math] IIR filter library (Butterworth,Bessel,...)

Dear Bernd, Thank you for this interesting contribution. I use these sorts of filters frequently so I will be interested to give it a look. I just build my Butterworths in k space so I will be interested to see how yours work differently. The math package is in flux as others can tell you,

[complex] commons-complex module

As the recent contribution shows the commons-math complex library remains quite useful to many applications. Following in the footsteps of commons-rng, commons-complex seems like a good next component of math to spin out and actively maintain. I am willing to oversee and maintain the project. It

Re: [math] IIR filter library (Butterworth,Bessel,...)

> > > > It will be a good fit if the code comes with developer(s) willing > > to provide support too. > Yes of course I would provide support and of course see it through to > the release. That comes without saying. > > Myself as well. One possibility would be to use this new code to spin off the

Re: [math] IIR filter library (Butterworth,Bessel,...)

> > >> Interesting! I think also looking at what is already existing in > the commons library your contribution is clearly on the image processing > side. Is that right? It's badly needed. I also would love to have it. > Crucial point here is that this is in signal processing terminology >

[PROPOSAL] sandbox request for commons-filter

have two initial core contributors to commons-filter, Bernd Porr (contributor) and Eric Barnhill (committer). Sufficient code for commons-filter has already been developed, tested, and integrated into maven. Both contributors are professionals in the field of signal and image processing. The library

Re: [complex] commons-complex module

On Tue, Oct 25, 2016 at 7:32 PM, Gary Gregory wrote: > > I am against this constant spinning out. > > Gary > > The proposed commons-filter is not a spin out. There was one filter in math and it didn't belong there. Now we have at least couple of people around who know

Re: [math] IIR filter library (Butterworth,Bessel,...)

Hi Bernd, sounds like we agree on basically everything there is to do. > I've spent the weekend adding maven support to the IIRJ library. So now > a simple "mvn install" does the job. Also done the testing properly with > "mvn test" which generates all the different kinds of impulse responses >

[MATH] [Complex] FFT

Since FFT discussions appear to have begun...I have long noticed that the FFT in CM is only a Radix-4 implementation. Bernd, is improving the performance of the CM FFT be something that interests you? Either way, I should be able to pick up activity here in a couple of weeks, and I could look

commons-filter sandbox is operational

I have set up a sandbox project for commons-filter in the commons sandbox subversion repository. I used models in the sandbox for LICENSE.txt, NOTICE.txt and the pom.xml, and set up a folder tree for src . mvn install runs successfully, mvn site does not. The pom model I used (cli2) had

Re: [complex] commons-complex module

On Wed, Oct 26, 2016 at 2:25 PM, Gilles wrote: > >> It sounds like you can create your new component on top of math4, correct? >> > > Would you rather reply to the technical arguments put forward in the > preceding paragraph? > > I've already answered your question

Re: commons-filter sandbox is operational

required for "mvn > site"? > > /Bernd > > > On 01/11/16 16:17, Eric Barnhill wrote: > >> I have set up a sandbox project for commons-filter in the commons sandbox >> subversion repository. >> >> I used models in the sandbox for LICENSE.txt, NOTIC

Re: [Filter] Better name? (Was: [math] IIR filter library [...])

Changed sandbox folder name to "sigproc". Eric On Fri, Nov 25, 2016 at 9:01 PM, Gary Gregory wrote: > On Thu, Nov 24, 2016 at 12:20 AM, Bernd Porr wrote: > > > Hi Gilles, > > > > I like the idea of "SigProc". Filter is a bit too narrow especially

Re: [complex][math-util] dependencies

On Tue, Nov 29, 2016 at 8:48 PM, Gilles wrote: > In "Commons RNG", I completely dropped all custom-made exceptions. > I suggest you do the same here. > IMO, "simple", low-level, components can do with just throwing > runtime exceptions from the standard library

Re: [ALL][SigProc] Repository for component candidate? (Was: No code?)

I would also add that this was part of the expected development path of math modules. The first thing was to see what actually got developed and supported; this would then shed light on how best to organize it, rather than lay out an organization for a "best case" set of math libraries that might

[numbers] JTransforms and commons-math

On the subject of FFT and other transforms, I went to take another look at the JTransforms code, which is AFAIK the premiere transforms package for Java (even outperforming FFTW) and which I myself use over Commons. It is now on GitHub so it was easy to browse the source code. It is in pure Java

Re: [numbers] JTransforms and commons-math

Do you know which methods, and why (precision and/or performance)? I can look at the code this week, alternatively I could contact the developer. On the other hand we will need an FFT going forward, >> > As for similar issues (cf TEXT), "SigProc" can define custom interfaces > and bridge(s). >

Re: [VOTE] Rename "Complex" to "Numbers" (Was: [complex] Make multi-module and rename component?)

UTC). > > > > Thanks, > > Gilles > > > > > > On Mon, 9 Jan 2017 15:57:51 +, sebb wrote: > > > >> On 9 January 2017 at 11:46, Gilles <gil...@harfang.homelinux.org> > wrote: > >> > >>> On Mon, 9 Jan 2017

Re: [Filter] No code?

That was where we left it. I asked Bernd if he did not have write access to the sandbox. If there was a reply to that I didn't see it. This would be the key thing to sort out. Can Bernd write to the sandbox or is it committers only? If it is only committers, I am happily to push Bernd's

[complex][math-util] dependencies

I thought it would be good to raise a structural question here rather than in the commons-complex JIRA. The Complex library has multiple dependencies on three packages: -- commons-math base classes (e.g. Field et al.) -- commons-math exceptions -- commons-math util (numerous classes) Otherwise

Re: [complex][math-util] dependencies

On Tue, Nov 29, 2016 at 8:48 PM, Gilles <gil...@harfang.homelinux.org> wrote: > Hello Eric. > > On Tue, 29 Nov 2016 14:19:54 +0100, Eric Barnhill wrote: > >> I thought it would be good to raise a structural question here rather than >> in the commons-complex JIRA.

Re: [3/3] commons-complex git commit: Two patches from Raymond DeCampo

://git-wip-us.apache.org/repos/asf/commons-complex/commit/dbad5ed4 >> Tree: http://git-wip-us.apache.org/repos/asf/commons-complex/tree/ >> dbad5ed4 >> Diff: http://git-wip-us.apache.org/repos/asf/commons-complex/diff/ >> dbad5ed4 >> >> Branch: refs/heads/master &g

Re: [complex] Contributing code

Good to see it is up. Patches or pull requests are both fine by me. Eric On Fri, Jan 6, 2017 at 7:25 PM, Gilles wrote: > On Fri, 06 Jan 2017 18:48:58 +0100, Gilles wrote: > >> On Fri, 6 Jan 2017 12:21:55 -0500, Raymond DeCampo wrote: >> >>> Gilles, Eric, what is

Re: [math] (MATH-1397) Complex.ZERO.pow(2.0) is NaN

-- > > Hello Mario and Raymond. > > Having complex numbers (and related functionality) in their own component > was on the roadmap; an effort led by Eric Barnhill (to whom I've just > assigned this issue). > If you'd like to help move the

[commons-complex] Pushing Apache git repo to Github mirror

I have read the information regarding read-only git mirrors at http://apache.org/dev/git.html . However I have a git mirror for commons-complex at https://github.com/apache/commons-complex , it is empty while the apache git repo at https://git-wip-us.apache.org/repos/asf?p=commons-complex.git has

First commit to commons-complex git page

To enable others to work on the code, I have posted the first commit to commons-complex. Please note that the code compiles but does not yet pass mvn test. This is what I am working on right now. Between replacing Precision.equals() type methods with private local equals() methods for each

Re: [complex] Make multi-module and rename component?

It is overall a fine plan by me. A precision class makes more sense than duplicating equals methods. >From a practical standpoint I think it would be better to see Quaternion in its own subpackage than with Complex. Simply because I don't use them and packages are better maintained by those who

Re: [complex] Drop "ComplexFormat"?

This is fine with me and absent other objections I will take it out. Eric On 8 Jan 2017 04:51, "Gilles" wrote: > Hi. > > Does a such a formatting class belong to the component? > IIRC they were issues with number formatting classes in > Commons Math. IMO, in a

Re: commons-numbers git commit: Complex class [...]

ee: http://git-wip-us.apache.org/repos/asf/commons-numbers/tree/ >> 85703373 >> Diff: http://git-wip-us.apache.org/repos/asf/commons-numbers/diff/ >> 85703373 >> >> Branch: refs/heads/master >> Commit: 857033738c5f470289f3ff4ea325e5b7f6adae52

Re: [ALL] The Commons Math issue

On Wed, Apr 12, 2017 at 5:29 PM, Gilles wrote: > On Wed, 12 Apr 2017 15:56:23 +0200, Emmanuel Bourg wrote: > >> On 04/12/2017 02:56 PM, Gilles wrote: >> >> Yes; and it is good per se, of course. Unforunately, it didn't change >>> the Commons Math issue: it's still

Re: commons-numbers git commit: NUMBERS-13: Some tests in the old ComplexTest tested the old NaN behavior (i.e. turn the whole Complex into NaN) and these were deleted. There is also an error in the t

che.org/repos/asf/commons-numbers/commit/0a01e2d0 >> Tree: http://git-wip-us.apache.org/repos/asf/commons-numbers/tree/ >> 0a01e2d0 >> Diff: http://git-wip-us.apache.org/repos/asf/commons-numbers/diff/ >> 0a01e2d0 >> >> Branch: refs/heads/complex-dev >> Comm

Re: Attaching Apache repository pushes to GitHub page

; on-my-profile/ > > On Thu, Aug 3, 2017 at 2:38 PM, Eric Barnhill <ericbarnh...@gmail.com> > wrote: > > > I am applying for jobs soon and want my work on commons-numbers to be > > visible on my GitHub page. However I am pushing to an Apache repository &

Attaching Apache repository pushes to GitHub page

I am applying for jobs soon and want my work on commons-numbers to be visible on my GitHub page. However I am pushing to an Apache repository rather than to my own fork, so it doesn't show up on my GitHub page. Is there a way to link the two?

Re: [Numbers] How far from a first release?

As far as commons-complex goes. To conform the library to C standards, the entire approach to NaN had to be rethought. In fact it is not clear from the code what the justification was for the NaN approach in the present code. To handle corner cases of nearly every operation in accordance with the

Re: [Math][Numbers] Move Field, etc. to numbers?

I am also not in favor of retaining the Field class. In the context of a large mathematical library that was attempting to meaningfully fuse OOP concepts with mathematical functionality it might make sense (although it should be pointed out, all the mathematicians I know are not really interested

[numbers-complex] Checkstyle "unknown tag: if"

Running checkstyle on commons-numbers-complex, I get several unknown tag: if > errors that predate me. Has there been a change in accepted style, so that these tags don't work anymore, but they once did? In which case I will replace them. Eric

Re: [numbers-complex] Checkstyle "unknown tag: if"

the branch is called complex-dev On Wed, Sep 13, 2017 at 4:27 PM, Gilles <gil...@harfang.homelinux.org> wrote: > On Wed, 13 Sep 2017 15:54:59 +0200, Eric Barnhill wrote: > >> Running checkstyle on commons-numbers-complex, I get several >> >> unknown tag: if >&g

Re: [Statistics] Ready for work

I will try to start giving the code a look later this week. I take it one starting point would be moving any dependencies from commons-math to commons-numbers that can be so moved. Eric On Sat, Jan 13, 2018 at 12:54 PM, Gilles wrote: > Hi. > > Tools are set up: >

Re: [Statistics] Distributions

On Tue, Jan 16, 2018 at 3:29 PM, Bill Igoe wrote: > > Thinking aloud. 'Math' is of course a broad subject and your goal of a > solid all encompassing package is admirable. > I am not sure that is the goal of the projects here actually. Commons is more about small re-usable

Re: [Numbers] Where do we stand?

First of all, AFAICT, none of the issues I worked on have ever been marked "resolved". I don't believe I have the power to mark them this way myself. Eric On Fri, Jan 26, 2018 at 1:49 AM, Gilles wrote: > Hello. > > JIRA lists 12 unresolved issues for the v1.0

Re: [Numbers] Jenkins build failure

ok will fix On Fri, Jan 26, 2018 at 4:23 PM, Gilles wrote: > Hi Eric. > > Your recent merge contains Javadoc errors that make Java 8 > unhappy: > https://builds.apache.org/view/A-D/view/Commons/job/commons- > numbers/62/console > > Regards, > Gilles > > >

Re: [Statistics] Ready for work

I just see a pom file. Do we start by generating an archetype? On Sun, Jan 14, 2018 at 11:30 AM, Eric Barnhill <ericbarnh...@gmail.com> wrote: > I will try to start giving the code a look later this week. I take it one > starting point would be moving any dependencies from

[statistics] Storeless statistics - two points about Mean()

Overall I think the old math-statistics functioned well and I would not be inclined to mess with the old object hierarchy without reason. But there are some strange design choices in this code. Mean() is used here as an example. 1) In Mean() the two constructors create a FirstMoment() object:

Re: [Numbers] Where do we stand?

On Wed, Jan 31, 2018 at 2:25 PM, Gilles wrote: > Hi Eric. > > It would be great if we could either resolve the following issues > or have a path forward for them that would not block the release > of "Commons Numbers": >

Re: [Numbers] Jenkins build failure

It doesn't like a custom @if tag. Is there any reason for me to keep it? It doesn't seem to be used very gramatically anyway. I have started looking through stats as well. On Fri, Jan 26, 2018 at 4:35 PM, Eric Barnhill <ericbarnh...@gmail.com> wrote: > ok will fix > > On Fri, Ja

[statistics] Java 8 and summary statistics

If we are going to target Java 8 with commons-statistics, then we should make use of the built in DoubleSummaryStatistics() ( https://docs.oracle.com/javase/8/docs/api/java/util/DoubleSummaryStatistics.html) class, related classes for other numeric types, and related interfaces in the

Re: [Math] Not releasing 3.X (Was: Linear Programming in Math [...])

I would be happy to help create Commons-Stat as I use those functions all the time. Eric

Re: [Statistics] Ready for work

initialize-repo" Eric On Thu, Jan 18, 2018 at 9:57 AM, Gilles <gil...@harfang.homelinux.org> wrote: > On Thu, 18 Jan 2018 09:37:15 +0100, Eric Barnhill wrote: > >> I just see a pom file. Do we start by generating an archetype? >> > > Won't this create a POM (t

Re: [Statistics] Ready for work

On Sun, Jan 21, 2018 at 5:45 PM, Gilles wrote: > >> Next step should probably be: > * create the web site directory > Do you mean with mvn site? The target folder is in the .gitignore .

Re: [Statistics]Port codes from Commons Math

On Tue, Mar 13, 2018 at 12:47 AM, Gilles wrote: > >> >> Where can we find the old code before port into new Commons components? >> > > The code bases are managed by the "git" software; the whole history is > available: >

[complex] What remains for numbers-complex release

Based on my review of the JIRA open issues, I think there are three remaining issues for a numbers-complex release, assuming we proceed with the plan to leave ComplexUtils out of the first release: 1) a parse method, so that Complex fits all requirements for being a VALJO 2) deciding whether we

Re: [Statistics] Port codes from Commons Math

HI Gimhana, Sorry for the delay in response, but you posted this right before our two-week Easter holiday, for which I was completely absent ; then I needed a few days back at work to clean up all the mess. :) Your overall goals look good to me. You have gone right to the heart of the matter and

Re: [Statistics] Port codes from Commons Math

() is still likely to produce the best and most consistent performance with the JVM. On Thu, Apr 12, 2018 at 2:03 PM, Eric Barnhill <ericbarnh...@gmail.com> wrote: > HI Gimhana, > > Sorry for the delay in response, but you posted this right before our > two-week Easter ho

Re: [Numbers] Re: [...] NUMBERS-68: parse() [...]

Just to clarify, so the spec for parse() will handle decimal points in numbers but not commas. Fine by me. Eric On Tue, Apr 24, 2018 at 8:53 PM, Gilles <gil...@harfang.homelinux.org> wrote: > On Tue, 24 Apr 2018 16:29:58 +0200, Gilles wrote: > >> On Tue, 24 Apr 2018 16

[JIRA] Need committer privileges for JIRA

I appear to be lacking appropriate committer privileges in the Apache commons JIRA. I can close and resolve my own issues but not those of others. Can someone help with this? Thanks, Eric

Re: [Numbers] Re: [...] NUMBERS-68: parse() [...]

I would prefer to conform toString() to the current formats accepted by parse() . The toString() method separates the real and imaginary components by commas. Separating numbers by commas strikes me as dangerous given that the input expressions to be parsed may also contain commas within the

Re: [numbers] Making fractions VALJOs

e second and third of the double constructors could be fromDoubleEpsMaxInt and fromDoubleMaxDenom . Eric On Thu, Oct 11, 2018 at 7:00 AM Gilles wrote: > On Wed, 10 Oct 2018 16:18:50 -0700, Eric Barnhill wrote: > > I am interested in moving forward on making the Fraction classes

  1   2   3   >