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
> 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.
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
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
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
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
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
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
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
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 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,
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
+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
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
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
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
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
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
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
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
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
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
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
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
+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
>
> > 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
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
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
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
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 :
> >
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:
> >
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
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)
>
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
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
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
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
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
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
> 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
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
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'
+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
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
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
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
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
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.
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
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
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
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
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
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
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
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
> >
> >
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
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,
> >
> >
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
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
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
> >>
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
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
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
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
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
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, 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
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
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
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
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
>
> 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.
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
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
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
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 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
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
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 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
+1
On Tue, Feb 19, 2019 at 1:35 PM Marcelo Vanzin
wrote:
> I'm opening a vote based on recent discussions about the extra noise
> generated by github updates going to dev@. So please vote:
>
> - +1 to redirect github updates of all commons repos to the issues@ list
> - -1 to keep things as is
>
I have read the Stack Overflow thread and will give a look at you rminimal
working example.
On Wed, Feb 13, 2019 at 10:45 AM Gilles Sadowski
wrote:
> Hi.
>
> Le mer. 13 févr. 2019 à 13:12, Roman Leventov a
> écrit :
> >
> > I try to approximate inverse CDF of BinomialDistribution with inverse C
Is it the consensus outcome for the dev list, that we all receieve a large
amount of GitBox postings? Wouldn't it be better to leave it to individuals
to track the projects they want to track? I know I do this.
Apologies if I missed any prior discussions.
Eric
Please ignore previous post which was sent by accident.
>
> Le mar. 29 janv. 2019 à 00:14, Eric Barnhill a
> écrit :
> >
> > Fraction already has a toString() method which should cover VALJO
> concerns
> > by representing the instance in one specific way.
>
> > Fraction already has a toString() method which should cover VALJO
> concerns
> > by representing the instance in one specific way.
>
> It has 2 different outputs (suppress the fraction bar and denominator
> when it is 1).
> Not sure that's very robust: Expecting a "/" as part of the represent
Fraction already has a toString() method which should cover VALJO concerns
by representing the instance in one specific way.
The FractionFormat classes allow for options beyond this such as proper
fractions or region-specific versions.
It doesn't seem to me like it violates VALJO principles to ha
It sounds like this is a worthwhile upgrade to the performance of the
Simplex solvers. I agree with Gilles that from a design perspective, the
class is accomplishing the same task only with an internal modification
difference, so if possible it should be set with an argument rather than a
whole new
10:34 AM Gilles
wrote:
> On Fri, 28 Dec 2018 09:17:08 -0800, Eric Barnhill wrote:
> > Fractions are constructed using either ints or doubles. In the case
> > of
> > ints, the numerator and denominator are passed (or the denominator is
> > assumed to be one). C
I use fraction-dev for Fraction and complex-dev for Complex. cis-method,
complex-constructors, eb-test were all I believe side branches I used for
testing but did not delete.
Eric
On Tue, Jan 8, 2019 at 5:39 AM Gilles Sadowski wrote:
> Hi.
>
> Command
> $ git branch -a
> shows several stale
with
max denominator b.
Those two processes are so different that it might be more clarifying to
distinguish them as ofInt(int a, int b) and ofDouble(double a, int b)
Eric
On Fri, Dec 28, 2018 at 4:33 AM Gilles wrote:
> Hello Eric.
>
> On Thu, 27 Dec 2018 17:00:15 -0800, Eric Barnh
Why not rely on method overload? There is no need to duplicate
> part of the the method's signature in its name.
>
> Gilles
>
> > and made
> > BigInteger-based constructor private
> > ebb8e03 is described below
> >
> > commit ebb8e03f139b8cec84564b3e558
Thanks for this response and it took me some time to think your various
points through.
On Thu, Dec 13, 2018 at 4:59 PM Gilles wrote:
>
> On Thu, 13 Dec 2018 11:20:12 -0800, Eric Barnhill wrote:
>
> > Among the elegancies afforded by this change, if a Fraction operation
> &g
For the line:
Assert.assertFalse(zero.equals(Double.valueOf(0)));
Eclipse is producing a warning:
"Unlikely argument type for equals(): Double seems to be unrelated to
Fraction"
Does anyone have a suggestion for how to handle this warning, thank you.
Eric
Right now BigFraction and Fraction are separate parallel classes.
I propose altering this so that BigFraction extends Fraction, overrides its
methods, but also keeps its own unique methods.
I think it would be an improvement to the API to have both classes share
the same interface (and indeed an
+1
On Sun, Dec 9, 2018 at 9:04 AM Oliver Heger
wrote:
> +1
>
> Oliver
>
> Am 08.12.2018 um 21:09 schrieb Rob Tompkins:
> > Infra stated that we need documented consensus on this. So, let’s have
> at it.
> >
> > I propose that we move the following repos over to gitbox:
> >
> > commons-build-plug
>
>
> Does this mean that computations can "unpredictably" overflow
> (or throw an exception)?
>
The ArithmeticUtils() methods mulAndCheck and addAndCheck throw exceptions
if there is overflow during primitive operations. That is the "check" part
of the method name.
> Is it acceptable, or should
, Nov 8, 2018 at 11:11 AM Gary Gregory
> wrote:
>
>> I'm all for the Javadoc made to reflect the reality of the code. It is
>> fine
>> to have an additional section that points out Knuth and how we may want to
>> change things as a hint or request to contributors.
>&
It reminds me uncomfortably of Microsoft's old "embrace, extend,
exterminate" philosophy in the 1990s.
On Wed, Nov 14, 2018 at 10:03 AM Pascal Schumacher
wrote:
> Isn't this basically the same as Adopt Open JDK:
>
> https://adoptopenjdk.net
>
> or am I missing something?
>
> -Pascal
>
> Am 14.11
fine
> to have an additional section that points out Knuth and how we may want to
> change things as a hint or request to contributors.
>
> Gary
>
> On Wed, Nov 7, 2018 at 10:52 AM Eric Barnhill
> wrote:
>
> > I read Kunth's "Art of Computer Programming 4.5.1"
1 - 100 of 209 matches
Mail list logo
