I am getting a maven error for the surefire plugin, but don't see it listed
as a dependency in numbers-fraction or numbers-core. I see it listed in
numbers-parent, but with no version number. Any ideas what I need to do to
get the tests running again?
I also get this error with other numbers modul
Rebasing on master fixed the problem, thank you.
On Mon, Mar 4, 2019 at 3:39 PM Gilles Sadowski wrote:
>
>
> I'd recommend that you regularly rebase from "master".
>
> Regards,
> Gilles
>
> >
> > > Here is an excerpt of the exception trace (from running "mvn -e test"):
> > > ---CUT---
> > > Caus
I am definitely willing to mentor development of the stats libraries as I
was last year. Now that I work more in data science I am happy to also
mentor the ML library -- in today's world this is NOT too distant a subject
for commons to cover and I am using those models every day, also it
integrates
On Sat, Mar 9, 2019 at 4:56 PM Gilles Sadowski wrote:
> Hi Eric.
>
> Le ven. 8 mars 2019 à 22:22, Eric Barnhill a
> écrit :
> >
> > I am definitely willing to mentor development of the stats libraries as I
> > was last year. Now that I work more in data science I a
r if we would get some
> dogfooding through projects like Apache OpenNLP (one that I know uses ML in
> Java).
>
> CheersBruno
>
> On Tuesday, 12 March 2019, 1:24:24 pm NZDT, Eric Barnhill <
> ericbarnh...@gmail.com> wrote:
>
> On Sat, Mar 9, 2019 at 4:56 PM Gille
On Tue, Mar 12, 2019 at 11:48 AM Gilles Sadowski
wrote:
>
> There are also a couple of CM packages that would be worth porting
> to [Numbers] or their own component:
> * o.a.c.math4.analysis.integration
> * o.a.c.math4.analysis.interpolation
> * o.a.c.math4.analysis.solvers
> (with adaptati
I think this class is on its way howver I agree with Sebb's comments there
has to be more flexibility about the rounding approach.
I am not sure a Utils class is the way to handle this flexibility. What
about a DurationRounder class or similar. Then an Enum for rounding method:
RoundingMethod.ROUN
erefore I don't see to much benefits from make this in more
> objectish way
>
>
> On Wed, 13 Mar 2019 at 00:20, Eric Barnhill
> wrote:
>
> > I think this class is on its way howver I agree with Sebb's comments
> there
> > has to be more flexibility a
>
> P.S. Do you know that a potential GSoC candidate is waiting for your
> feedback?
> https://issues.apache.org/jira/browse/STATISTICS-5
>
>
I did not see that! Thank you, I replied. I think STATISTICS-5 is
superseded by STATISTICS-7 which is also a bit more specific.
I'm rebasing fraction to master and the next merge is looking tricky.
Gilles, am I correct that you have added an interface and some methods to
Fraction, and pushed this to master? But master does not yet have the of()
and from() method name changes that we discussed while my branch does, also
my b
Almost done with Fraction here.
Fraction() operates with int inputs only, due to the mathematical
limitations of the fast algorithm, so of() methods only need to handle int
inputs.
But what about BigFraction()? Right now the of() methods handle BigIngeters
only. Do we want to expand this so a Big
Our ongoing discussion with potential mentees is being moved here as
suggested by Gilles.
Gilles commented on STATISTICS-7:
-
current "math-linear" will be ported to "Commons Linear" in the future?
Perhaps; we'd need expert advice on how to design a modern implem
Lam,
A warm welcome to you. I have replied within your message below.
On Mon, Apr 1, 2019 at 4:49 PM thuan wrote:
>
>
> 1. *What is the complete scope of this project?* Is it only NUMBERS-96
> or all NUMBERS-related JIRAs? I want to know it to ensure where to
> focus.
>
It is only NU
Sorry, a bad keystroke combination sent that early, one reply is not
finished. Never alternate between vim in one window and gmail in the other.
2. *Is it okay if I am not familiar with Interpolation**'now'?* The
>> truth is, Interpolation is an area I have not known about, which is
>> wh
ls? What do you think of this preliminary idea?
> I would think that appending say the LogisticRegression (and other types)
> would be more straightforward as a result, having different regression
> types each having defined behavior and in separate packages with minimal
> dependencies a
Sorry you are right I am reading Salman's. Looking forward to reading yours
as well.
On Tue, Apr 2, 2019 at 1:27 PM Ben Nguyen wrote:
> Hello Mr. Eric Barnhill
> I have not submitted my draft proposal yet, you must’ve read someone
> else’s but I will submit mine later today or
The STATISTICS-7 ticket is not relevant for the exciting regression
proposals we have received. Would the two authors of these regression
proposals please reference ticket
https://issues.apache.org/jira/browse/STATISTICS-8 . Sorry it is a bit of a
rush job, I can iterate it a bit when I have more t
Actually some objections have been raised to using Slack because it is not
open source. So the options will be either zulipchat if a group of people
want to use it, or Riot if it is just me.
Thanks, Eric
On Wed, May 1, 2019 at 1:20 PM Eric Barnhill wrote:
> I am going to set up a Slack
I am going to set up a Slack to communicate with my GSoC mentees.
I know official policy is to communicate on this list, but especially with
small setup questions the mentees might have, or gaps in their knowledge,
that will create unnecessary spam for everyone. Larger-scale decisions will
be post
On Wed, May 1, 2019 at 1:49 PM Mark Thomas wrote:
> On 01/05/2019 21:38, Eric Barnhill wrote:
> > Actually some objections have been raised to using Slack because it is
> not
> > open source. So the options will be either zulipchat if a group of people
> > want to use i
wrote:
> On 01/05/2019 21:54, Eric Barnhill wrote:
> > On Wed, May 1, 2019 at 1:49 PM Mark Thomas wrote:
> >
> >> On 01/05/2019 21:38, Eric Barnhill wrote:
> >>> Actually some objections have been raised to using Slack because it is
> >> not
> >>
I am happy to review PRs and approve merges as well, it's become part of my
daily routine at work to use GitHub in this way, so it's no trouble.
On Thu, May 2, 2019 at 3:56 AM Gilles Sadowski wrote:
> Hi.
>
> Some people are providing PRs[1] on GitHub without engaging with
> us, here, or on JIRA
sday, May 1, 2019 4:21 PM
> > To: Commons Developers List
> > Subject: Re: [numbers][GSoC] Slack for GSoC mentees
> >
> > On 01/05/2019 22:09, Eric Barnhill wrote:
> > > Thanks Mark,
> > >
> > > It looks like an apache.org domain email is required to
ulip? I’m
> excited to get started!
>
> Ben
>
> From: Mark Thomas
> Sent: Wednesday, May 1, 2019 4:21 PM
> To: Commons Developers List
> Subject: Re: [numbers][GSoC] Slack for GSoC mentees
>
> On 01/05/2019 22:09, Eric Barnhill wrote:
> > Thanks Mark,
> >
> >
Hello,
> >>
> >> Any update on which communication tool will be used? Slack, Zulip? I’m
> >> excited to get started!
> >>
> >> Ben
> >>
> >> From: Mark Thomas
> >> Sent: Wednesday, May 1, 2019 4:21 PM
> >> To: Commons Deve
ill be used? Slack, Zulip? I’m
> > excited to get started!
> >
> > Ben
> >
> > From: Mark Thomas
> > Sent: Wednesday, May 1, 2019 4:21 PM
> > To: Commons Developers List
> > Subject: Re: [numbers][GSoC] Slack for GSoC mentees
> >
> >
On Mon, May 6, 2019 at 11:51 AM Virendra singh Rajpurohit <
virendrasing...@gmail.com> wrote:
> Hey Eric, My name is there on projects list, but I haven't yet received any
> official mail from Apache or Google.
> Does that mean I'm selected?
>
Yes, congratulations you were selected. Check the sp
Since it looks like we will have some development in these libraries this
summer (whee!) I propose starting 'develop' branches for these libraries.
The mentees and others can then create feature branches off of develop, and
submit pull requests for feature branches into develop. Then develop is
mer
It looks to me like the EJML library is the best choice for linear algebra
right now, is well supported, and we should not reinvent the wheel unless
we have the motivation and expertise to do so.
EJML is under the Apache 2.0 license which I read to mean we can use it in
any derivative way we pleas
Udit, is it clear what to do here? Gilles recommends you propose some edits
to ContinuousDistribution instead, to return Mode and Median.
But then, if an interface is altered, all the classes that implement that
interface need to have these functions added, so we hope you are up for all
that addit
Awesome!
On Thu, May 9, 2019 at 10:44 AM Udit Arora wrote:
> I will see what I can do. It will take some time, but I will get to know
> more about the other distributions.
>
>
> On Thu, 9 May 2019, 10:58 pm Eric Barnhill,
> wrote:
>
> > Udit, is it clear what to do
Should we have another Slack meeting at the same time this Thursday, 5pm
UTC (9am California time)?
The first focus of this meeting will be blockers and other questions the
mentees have, trying to get up to speed on command line git, maven and
POMs, and IDEs. Everyone should bring at least one thi
Yes. This sounds great for commons-statistics. Other work in a similar vein
will be happening this summer by one of our GSOC mentees.
On Tue, May 14, 2019, 15:04 Gary Gregory wrote:
> We have a Commons Statistics component that might be a fit.
>
> Gary
>
> On Tue, May 14, 2019, 17:34 Aleksander
As I mentioned previously, there is now a "develop" branch in
commons-statistics. Recommended standard procedure from now on, create
feature branches off the develop branch, then PR into the develop branch.
Then when stability is confirmed, someone can merge develop into master.
Let's have another mentee meeting Thursday morning, same time as the
previous two. (Sorry about the miscommunication Abhishek).
As preparation for this meeting please have prepared a detailed flow
diagram for your proposed components, ideally with sufficient detail that
it includes some unit tests
Yes I regret that I did not finish up the last mile on Fraction before this
ticket was submitted. It would haved saved time as maybe I have fixed
someof those already. But, I will integrate these suggestions after I
finish my edits, all that is left to look at in my branch is the
checkstyle.
On We
+1
On Wed, May 22, 2019 at 3:15 PM Gilles Sadowski
wrote:
> Hi.
>
> Le mer. 22 mai 2019 à 18:43, Heinrich Bohne a
> écrit :
> >
> > Right now, commons-numbers is using JUnit 4.12, the last stable version
> > of JUnit 4. As far as I am aware, there is no explicit syntax in JUnit
> > 4.12 for tes
Hi Elena,
Thanks for this intriguing idea. As far as I ever knew IRLS requires a
matrix. Can you provide me with a citation where I can read about this
vector-based approach?
Thanks,
Eric
On Thu, May 23, 2019, 06:44 Елена Картышева wrote:
> Hello.
>
> I would like to propose a pull request im
+1
Users should also beware that working on a repo in Windows in an IDE can
cause the file to take on a pile of Windows line endings which git then
pushes. This has happened to me elsewhere. Maybe this fix takes care of it.
On Fri, May 24, 2019, 00:28 Alex Herbert wrote:
> The recent PR to add
Thanks for this great work.
This chart will serve you well and you are now in a great place to proceed
further. Are you able to now create a UML for the components you are going
to create? Is there a set of core functionalities that you will target
first? Can you maybe divide your proposed summer'
The previous commons-math interface for descriptive statistics used a
paradigm of constructing classes for various statistical functions and
calling evaluate(). Example
Mean mean = new Mean();
double mn = mean.evaluate(double[])
I wrote this type of code all through grad school and always found i
> Hello.
>
> Le mar. 28 mai 2019 à 20:36, Alex Herbert a
> écrit :
> >
> >
> >
> > > On 28 May 2019, at 18:09, Eric Barnhill
> wrote:
> > >
> > > The previous commons-math interface for descriptive statistics used a
> > > para
Let's have another weekly gathering tomorrow for GSoC mentees at the usual
time.
Everyone should have written at least some code, and a unit test that goes
with that code, and submitted it for review via a PR.
If you have difficulties doing this, please raise questions on the Slack.
Thanks to th
This is well worth discussing.
The protocol here could be improved. Where I work, we all write a lot of
code and we all have write access. We also *always* submit PRs rather than
push directly, and *always* request review from at least one other person.
This is because it is always risky to push c
As discussed on prior threads you should have both. There will need to be
static convenience methods for a user who wants to make a very simple call,
say Stats.mean() . But, as Alex said, this convenience class will just be a
front end for the statistics functionality itself. That needs to be in it
That looked like a list of times. How is this one for you all
https://www.timeanddate.com/worldclock/meetingdetails.html?year=2019&month=6&day=6&hour=16&min=0&sec=0&p1=136&p2=224&p3=265&p4=1249&p5=1860&iv=1800
On Wed, Jun 5, 2019 at 11:59 AM Alex Herbert
wrote:
> Time for another meeting to di
For some months I worked on the Fraction class on a fraction-dev branch,
now others are furthering it, but IIUC working off of master, plus it
sounds like my edits are out of date in other ways.
So within the next day, I will pull fraction-dev into master. I would
request any other contributors co
Changed are merged; in particular the travis updates were kept; if you are
working on Fraction kindly rebase.
On Wed, Jun 5, 2019 at 3:40 PM Eric Barnhill wrote:
> For some months I worked on the Fraction class on a fraction-dev branch,
> now others are furthering it, but IIUC working
On Tue, Jun 11, 2019 at 9:52 AM Heinrich Bohne
wrote:
> The class ArithmeticUtils in the commons-numbers-core module contains
> several methods where, since Java 8, equivalent methods in
> java.lang.Math exist. These methods are the following:
>
> addAndCheck(int, int)
> addAndCheck(long, long)
>
On Thu, Jun 13, 2019 at 9:36 AM sebb wrote:
>
>
> Rather than shuffle etc in place, how about various
> iterators/selectors to return entries in randomised order?
> [Or does that already exist?]
>
I am pretty sure random draws, and shuffling, are implemented with
different algorithms. Though sam
An iterator that dynamically shuffles as you go along. That's really nice,
I had never even thought of that. Thanks.
On Thu, Jun 13, 2019 at 10:11 AM Alex Herbert
wrote:
>
> On 13/06/2019 17:56, Eric Barnhill wrote:
> > On Thu, Jun 13, 2019 at 9:36 AM sebb wrote:
> >
I agree this increases readability and is nice.+1
The only thing that gives me the creeps is the force push in the PR. But
that is off topic, so another email for that.
On Thu, Jun 13, 2019 at 5:42 AM Gilles Sadowski
wrote:
> Hi.
>
> Le jeu. 13 juin 2019 à 01:34, Heinrich Bohne a
> écrit :
> >
Apologies if everyone knows this but...
There has been some force pushing in the git repos lately. Unfortunately
there are a lot of Stack Overflow answers that will tell the user to solve
a complex commit situation by force pushing. These answers are just
*wrong*. By the nature of our code it is b
On Mon, Jun 17, 2019 at 7:13 AM Ben Nguyen wrote:
> I don’t believe the plan is or that the use of EJML should be permanent….
>
There's no reason it couldn't be permanent. Obviously we want to give
credit where it is due in all the appropriate ways. But the code is
licensed so that others may i
Sorry for the slow reply, I thought I sent this yesterday.
I agree from a code architecture standpoint such a refactoring makes sense.
However from the perspective of unit tests it makes it no longer a unit
test.
IIUC it's best practice for a unit test that all context be within the
test. If addi
>
> > If additional context is required it fails to meet the definition of
> > a unit test and is instead an integration test, and the function being
> > tested may require rethinking.
>
> Depends what you define as a unit test. I'd say the unit was BigFraction
> or Fraction. An integration test i
+1
On Tue, Jun 25, 2019 at 6:24 PM Gilles Sadowski
wrote:
> Hi.
>
> Thanks for the suggestion, Rob.
>
> Should we contact him? [Perhaps he reads this ML...]
>https://www.linkedin.com/in/peter-abeles-59b2603
>https://github.com/lessthanoptimal/
>
> In addition to EJML, it seems that ther
Sorry for the delay, I was on vacation.
On Fri, Jul 5, 2019 at 2:09 PM Heinrich Bohne wrote:
> Hello!
>
> I think a re-design of the factory method BigFraction.from(double,
> double, int, int) is in order, because I see several problems with it:
>
> First, having a separate fraction class intend
On Tue, Jul 16, 2019 at 2:41 PM Heinrich Bohne
wrote:
> > Do you think we really even need a BigFraction class at all in the
> context
> > of these upgrades? Or should one of the Fraction factory methods just
> take
> > BigInteger argumentsm and all fractions use the lazy dynamic method of
> > ca
Phase 2 Evals are coming up starting July 22nd. For this eval we will be
emphasizing the necessity for the mentees to submit code on the same
quality level as typical commons contributors; let's get to a small amount
of code that is production-level.
We therefore present the following assignment f
I suggested the following grammar to aim for in our meeting today with the
developing OLS module. If you see anything you'd prefer to change let's
establish it now , if anyone doesn't like it later, it's on me.
RegressionData data = RegressionDataLoader.of(double[][] y, double[] x);
Regression ols
t; **always** sufficient in Fraction.addSub(Fraction, boolean).
> >>
> >> But this is beside the point, I only mentioned it because I didn't
> >> understand why you suggested to remove the BigFraction class, and
> >> actually, I still don't, as the class BigFract
Hi Virenda,
I think that's right in terms of initialization. If it is initialized to
NaN then accumulation will require an additional step getting rid of the
NaN. Just initialize to zero.
I just looked around and it's pretty clear that it is best practice to
return NaN in the edge case of an aver
I propose the following class structure for commons-statistics-regression.
The interface carried over from commons-math is more of an academic
approach to thinking about regression. For rebooting the library (and I
hinted at this when I wrote the tickets for summer of code) I was hoping to
emulate
Here is a link to the picture
https://imgur.com/a/9jjoOGB
On Tue, Oct 22, 2019 at 4:13 PM Gilles Sadowski
wrote:
> Hello.
>
> Le mar. 22 oct. 2019 à 21:50, Eric Barnhill a
> écrit :
> >
> > I propose the following class structure for
> commons-statistics-regressio
Here is a schematic for how the interface might be made more abstract.
https://imgur.com/a/izx5Xkh
In this case, we may want to just implement the simplest case, using Matrix
and double[], for now.
In principle the RegressionMetric class could extend a Metrics class later.
Do you feel this woul
On Mon, Oct 28, 2019 at 3:01 PM Gilles Sadowski
wrote:
> Hi Eric.
>
> 2019-10-28 18:55 UTC+01:00, Eric Barnhill :
> > Here is a schematic for how the interface might be made more abstract.
> >
> > https://imgur.com/a/izx5Xkh
>
> This cannot be downloaded.
&g
That's interesting. The JTransforms library performs Fourier transforms
that can take complex input, output, or both. They do this with interleaved
double[] arrays, which I suppose is much more space efficient, and the
status of a number as real or imaginary is implicit by its location being
odd or
+1 on all suggestions. Thanks, Alex.
On Wed, Nov 6, 2019 at 2:38 PM Alex Herbert
wrote:
>
>
> > On 6 Nov 2019, at 18:17, Gilles Sadowski wrote:
> >
> >> [...]
> >>
> >>
> >> Any objections to updating multiply/divide/isNaN to match the standard?
> >
> > Let me think... ;-)
>
> OK, I’ll fix it a
On Thu, Nov 7, 2019 at 3:59 AM Alex Herbert
wrote:
>
> There is a matrix for real/imaginary/complex all-vs-all additive and
> multiplicative operators in the standard (tables in G.5.1 and G.5.2).
> The question is do we want to support the entire matrix:
>
> Covered:
>
> Complex.multiplyReal(doub
On Thu, Nov 7, 2019 at 6:09 AM Gilles Sadowski wrote:
>
> This is also what started this thread: The user called the Commons Math's
> FFT utilities using arrays of "Complex" objects and got the "OutOfMemory"
> error. Hence the question of whether storing many "Complex" objects is
> ever useful,
Eric Barnhill wrote:
>
>
> On Thu, Nov 7, 2019 at 6:09 AM Gilles Sadowski
> wrote:
>
>>
>> This is also what started this thread: The user called the Commons Math's
>> FFT utilities using arrays of "Complex" objects and got the "OutOfMemory&q
On Thu, Nov 7, 2019 at 3:25 PM Gilles Sadowski wrote:
> Le jeu. 7 nov. 2019 à 18:36, Eric Barnhill a
> écrit :
> >
> > I should also add on this note, my use case for developing ComplexUtils
> in
> > the first place was compatibility with JTransforms and JOCL. In b
I agree, distributions seems stable and well supported.
You are proposing releasing it outside of numbers?
I think it's a good idea. +1
On Tue, Dec 3, 2019 at 8:00 AM Gilles Sadowski wrote:
> Hello.
>
> Most functionality of the "o.a.c.math4.distribution" package was migrated
> from Commons Ma
It seems like we're pretty close.
I can take a look at 136, 137 related to log. I have had trouble finding
the space to launch the regression project. But I could work on some
smaller things.
Regarding 70, the user guide, what do you think of submitting an
application to Google Season of Docs? I
Sorry I misspoke. Anyway I quite agree, it would work well as
commons-distribution. +1
On Tue, Dec 3, 2019 at 9:29 AM Gilles Sadowski wrote:
> Hi.
>
> Le mar. 3 déc. 2019 à 18:23, Eric Barnhill a
> écrit :
> >
> > I agree, distributions seems stable and well su
rbert
wrote:
> On Tue, 3 Dec 2019, 17:58 Gilles Sadowski, wrote:
>
> > Hello.
> >
> > Le mar. 3 déc. 2019 à 18:33, Eric Barnhill a
> > écrit :
> > >
> > > It seems like we're pretty close.
> > >
> > > I can take a look at 136
Some unsavory types are watching Apache activity. I submitted my first
Apache PR in a long time yesterday, by morning I had two phishing emails
mentioning Apache in both subject and body at the relevant email address.
I hope the community is aware of this issue? I don't recall this happening
even
Thank you for this great work. To the extent I implemented some of the
missing trig functions in Complex, I followed the implementations in
Complex.js , which seemed well worked out and supported. However I am sure
Boost would be much better engineered still. So +1
On Tue, Dec 10, 2019 at 7:42 AM
> I think that we then change it so it matches the source paper. It makes it
> a lot easier to follow the adaption from the paper (which is only about 8
> lines of pseudocode) if the variables have the same name.
>
+1 Thanks for catching this interesting issue.
Great +1
On Thu, Apr 9, 2020 at 3:59 PM Gilles Sadowski wrote:
> Le jeu. 9 avr. 2020 à 23:20, Alex Herbert a
> écrit :
> >
> >
> >
> > > On 9 Apr 2020, at 21:36, Gilles Sadowski wrote:
> > >
> > > Le jeu. 9 avr. 2020 à 22:20, Alex Herbert
> a écrit :
> > >>
> > >>
> > >>
> > >>> On 9 Apr 2020
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 comp
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 con
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 wit
Thank you Luc and Gilles, the issue is resolved.
pom.xml is throwing several errors but I will get to know Maven better, and
see if I can resolve them, before I post any issues.
Eric
On Thu, Oct 15, 2015 at 8:43 AM, Luc Maisonobe wrote:
> Hi Eric,
>
> Le 15/10/2015 00:13, Eric B
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 Gill
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 r
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?
Er
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 MATH-129
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
th
h GPU, 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 +, Eric Barnhill wrote:
Is anyone interested in some GPU support for MathArrays by u
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
I would be happy to help create Commons-Stat as I use those functions all
the time.
Eric
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:
> https://git1-us-west.apache.o
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 components that emerg
I just see a pom file. Do we start by generating an archetype?
On Sun, Jan 14, 2018 at 11:30 AM, Eric Barnhill
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 commons-math to
> commons-numbers th
initialize-repo"
Eric
On Thu, Jan 18, 2018 at 9:57 AM, Gilles
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 (thus overwriting the existing one)?
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 .
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 target.
>
> After quite a lot of ni
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
>
>
> --
1 - 100 of 209 matches
Mail list logo
