2020-03-21 2:59 UTC+01:00, chentao...@qq.com :
> Hi,
>
>>Le ven. 20 mars 2020 à 04:47, chentao...@qq.com a écrit
>> :
>>>
>>> Hi,
>>>
>>> >Hello.
>>> >
>>> >Le mer. 18 mars 2020 à 17:57, Gilles Sadowski a
>>&g
Le ven. 20 mars 2020 à 04:47, chentao...@qq.com a écrit :
>
> Hi,
>
> >Hello.
> >
> >Le mer. 18 mars 2020 à 17:57, Gilles Sadowski a écrit
> >:
> >>
> >> Hi.
> >>
> >> 2020-03-18 15:10 UTC+01:00, chentao...@qq.com :
&
Hello.
Le mer. 18 mars 2020 à 17:57, Gilles Sadowski a écrit :
>
> Hi.
>
> 2020-03-18 15:10 UTC+01:00, chentao...@qq.com :
> > Hi,
> > I have created a PR to show my aim:
> > https://github.com/apache/commons-math/pull/126/files
>
> A
Hi.
2020-03-18 15:10 UTC+01:00, chentao...@qq.com :
> Hi,
> I have created a PR to show my aim:
> https://github.com/apache/commons-math/pull/126/files
Am I correct that the implementations of "ClustersPointExtractor"
modify the argument of the "extract" method?
If so, that seems quite
Hello.
Le mer. 11 mars 2020 à 07:28, chentao...@qq.com a écrit :
>
> Hi all,
> The "EmptyClusterStrategy" in KMeansPlusPlusClusterer can be reused
> MiniBatchKMeansClusterer and other cluster altorithm.
> So I think the "EmptyClusterStrategy" should move out from
>
Hello.
2020-03-07 14:50 UTC+01:00, chentao...@qq.com :
> Hi,
>
>>> > [...]
>>> Solution 3 is "ClusterRanking".
>>> In cases where the reference algorithm would assume the
>>> other convention (i.e. "lower is better"), the implementation
>>> is required to apply a conversion (e.g. return the
Hello.
I've collected[1] a series of old issues reported against code in the
org.apache.commons.math4.ml.clustering
package.
The first proposed improvement[2] to the API results from a discussion
in another recent thread.
Any objection to that change?
Best,
Gilles
[1]
> > [...]
> Solution 3 is "ClusterRanking".
> In cases where the reference algorithm would assume the
> other convention (i.e. "lower is better"), the implementation
> is required to apply a conversion (e.g. return the opposite).
s/opposite/inverse/
[We should probably enforce that ranking is
Hello.
>>> [...]
>>> >> For machine learning centroid cluster algorithm, we often use is
>>> >> Calinsk-iHarabasz score to evaluate which algorithm or how many
>>> >> centers is
>>> >> best for a dataset.
>>> >> The python lib sklearn implements Calinsk-iHarabasz as
>>> >>
Le ven. 6 mars 2020 à 14:35, chentao...@qq.com a écrit :
>
> Hi,
>
> >Hello.
> >
> >2020-03-06 9:48 UTC+01:00, chentao...@qq.com :
> >> Hi,
> >> For machine learning centroid cluster algorithm, we often use is
> >> Calinsk-iHarabasz score to evaluate which algorithm or how many centers is
>
Hello.
2020-03-06 9:48 UTC+01:00, chentao...@qq.com :
> Hi,
> For machine learning centroid cluster algorithm, we often use is
> Calinsk-iHarabasz score to evaluate which algorithm or how many centers is
> best for a dataset.
> The python lib sklearn implements Calinsk-iHarabasz as
>
Hello.
Le jeu. 5 mars 2020 à 13:23, chentao...@qq.com a écrit :
>
> [...]
> It is a API change, how do we start it?
I'd suggest putting the new API in a (temporary) package
org.apache.math4.ml.clustering2
Regards,
Gilles
> [...]
o
maintain.
Gilles
>
> Regards,
> Peter
>
>
> On Thu, Mar 5, 2020 at 4:12 PM sebb wrote:
>
> > On Wed, 4 Mar 2020 at 14:20, Gilles Sadowski wrote:
> > >
> > > Le mer. 4 mars 2020 à 15:16, sebb a écrit :
> > > >
> > > > On We
Le jeu. 5 mars 2020 à 16:12, sebb a écrit :
>
> On Wed, 4 Mar 2020 at 14:20, Gilles Sadowski wrote:
> >
> > Le mer. 4 mars 2020 à 15:16, sebb a écrit :
> > >
> > > On Wed, 4 Mar 2020 at 14:09, Gary Gregory wrote:
> > > >
> > > >
Hello.
2020-03-05 4:50 UTC+01:00, chentao...@qq.com :
> Hi,
>
>>Hi.
>>
>>Le ven. 28 févr. 2020 à 05:04, chentao...@qq.com a
>> écrit :
>>>
>>>
>>>
>>>
>>> --
>>> chentao...@qq.com
>>> >Hi.
>>> >
>>> >Le jeu. 27 févr. 2020 à 06:17, chentao...@qq.com a
>>> > écrit :
>>> >>
>>> >> Hi,
Le mer. 4 mars 2020 à 15:16, Gilles Sadowski a écrit :
>
> Le mer. 4 mars 2020 à 15:09, Gary Gregory a écrit :
> >
> > IMO, until we are all on Java 14 and benefit from its more detailed NPE
> > message, we need to call Validate.notNull _with a message_ that says w
Le mer. 4 mars 2020 à 15:16, sebb a écrit :
>
> On Wed, 4 Mar 2020 at 14:09, Gary Gregory wrote:
> >
> > IMO, until we are all on Java 14 and benefit from its more detailed NPE
> > message, we need to call Validate.notNull _with a message_ that says what
> > variable blew up.
>
> +1
>
> That is
but you
may *want* to.
Gilles
>
> Gary
>
> On Wed, Mar 4, 2020 at 9:01 AM Gilles Sadowski wrote:
>
> > Le mer. 4 mars 2020 à 14:19, Gary Gregory a
> > écrit :
> > >
> > > On Wed, Mar 4, 2020 at 7:58 AM sebb wrote:
> > >
&g
Le mer. 4 mars 2020 à 14:19, Gary Gregory a écrit :
>
> On Wed, Mar 4, 2020 at 7:58 AM sebb wrote:
>
> > On Sat, 29 Feb 2020 at 18:09, Gilles Sadowski
> > wrote:
> > >
> > > Le sam. 29 févr. 2020 à 18:39, Gary Gregory a
> > écrit :
> > >
Hello.
Le lun. 2 mars 2020 à 14:19, Manas Kalangan a écrit :
>
> hey guys , i am manas , 2nd year computer engineering student, this is my
> first time in GSoC, could someone help me with project idea?
Welcome at the Commons project's discussion forum, but please
do not hijack threads.[1]
Best
Le sam. 29 févr. 2020 à 18:39, Gary Gregory a écrit :
>
> On Sat, Feb 22, 2020 at 5:25 PM Gary Gregory wrote:
>
> > I would like to do the same in Lang as with Collections (see below.)\
> >
> > We currently perform checks like:
> >
> > Validate.isTrue(foo != null, ...)
> >
> > Which should be
Hi.
Le ven. 28 févr. 2020 à 05:04, chentao...@qq.com a écrit :
>
>
>
>
> --
> chentao...@qq.com
> >Hi.
> >
> >Le jeu. 27 févr. 2020 à 06:17, chentao...@qq.com a écrit
> >:
> >>
> >> Hi,
> >>
> >> > [...]
> >> >> >>
> >> >> >> Do you mean I should fire a JIRA issue about
Hi.
Le jeu. 27 févr. 2020 à 06:17, chentao...@qq.com a écrit :
>
> Hi,
>
> > [...]
> >> >>
> >> >> Do you mean I should fire a JIRA issue about reuse"centroidOf"
> >> >> and "chooseInitialCenters",
> >> >> then start a PR and a disscuss about "ClusterUtils"?
> >> >> And thenstart the PR of
Hello.
[Message formatting is fine now. Thanks!]
Le mer. 26 févr. 2020 à 15:20, chentao...@qq.com a écrit :
>
> Hi,
>
> >Hello.
> >
> >[Please try and set your mail client to send plain text messages.]
> >
> >Le mer. 26 févr. 2020 à 14:05, CT a écrit :
> >>
> >> Hi Gilles,
> >>
Hello.
[Please try and set your mail client to send plain text messages.]
Le mer. 26 févr. 2020 à 14:05, CT a écrit :
>
> Hi Gilles,
> --Original--
> From:"GillesSadowski" Date:Wed, Feb 26, 2020 05:41 PM
> To:"Commons Developers List"
> Subject:Re: [math]
e done first as a separate
JIRA issue. IIUC, you propose "ClusterUtils". By reviewing a
minimal PR, we should be able to examine whether another
approach might be better (than a "utility" class) in order to expose
functionality common to all clusterer algorithms.
For example, cou
We try and avoid bloating the API, hence the changes which
I've suggested:
* remove the constructors with default parameters
Overall, each PR should probably contain a single commit, in
order to ease review.
> I remain have one question below:
>
> -- Original -
Hi.
Le sam. 22 févr. 2020 à 14:37, CT a écrit :
>
> Hi Gilles:
> I really appricate for your patient to help me to solve the mail sending
> problem, I try to set the only setting about charset "Use Unicode" for this
> mail.
The contents seems fine. However, there is something wrong:
Le sam. 22 févr. 2020 à 01:30, Alex Herbert a écrit :
>
>
>
> > On 22 Feb 2020, at 00:29, Gilles Sadowski wrote:
> >
> > Hi.
> >
> > Le ven. 21 févr. 2020 à 23:15, Matt Juntunen
> > a écrit :
> >>
> >> Are we waiting on anythi
Hi.
Le ven. 21 févr. 2020 à 23:15, Matt Juntunen
a écrit :
>
> Are we waiting on anything for a numbers release?
I don't think so.
Best,
Gilles
>
> > [...]
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For
[Re-sending post so that it is attached to the original thread.]
Hello.
Le mar. 18 févr. 2020 à 04:49, 陈 涛 a écrit :
>
> Hi Gilles:
>
>I really do not know if anyone received my last mail, no one replay me for
> a long time so I send it again and copy to you with another email system.
Hello.
Le mar. 18 févr. 2020 à 04:49, 陈 涛 a écrit :
>
> Hi Gilles:
>
>I really do not know if anyone received my last mail, no one replay me for
> a long time so I send it again and copy to you with another email system.
Sorry for the delay. :-}
>
> > Some remarks:
>
> > * I didn't get
Hi.
Le jeu. 23 janv. 2020 à 15:04, Matt Juntunen
a écrit :
>
> Hello,
>
> Any chance we can get a release (beta or full) for commons-numbers?
Non-exhaustive check-list is here:
https://issues.apache.org/jira/browse/NUMBERS-25
All "crosses" to be changed to "checks"?
Anyways, +1 to making
lated
components. Hence the suggestion that internship must be supported
by "Commons" as a whole.
Regards,
Gilles
>
> On Tue, Feb 4, 2020 at 05:47 Gilles Sadowski wrote:
>
> > Hello.
> >
> > Is "Commons" willing to set up itself for welco
Hello.
Is "Commons" willing to set up itself for welcoming new
people who, in order to contribute to the projects, might
need more support than the usual asynchronous review
of patches?
The ASF participates in GSoC[1] and Outreachy[2] and
some Apache projects seem well prepared for dealing with
Hi.
2020-01-26 16:54 UTC+01:00, Matt Juntunen :
> Hello,
>
> I'm looking into NUMBERS-40, which suggests that the exception behavior of
> commons-numbers (specifically the gamma package) needs to be made more
> consistent. Below is a summary of the public exception types explicitly
> thrown by
asinghe <
> > ahamarasin...@gmail.com> wrote:
> >
> >> Hi Gilles,
> >>
> >> Thanks for the support. I was able to setup work space and build the
> >> project
> >>
> >> *Best Regards *
> >> *Asanka Amarasinghe*
> >>
Hi.
Le lun. 27 janv. 2020 à 09:56, Amey Jadiye a écrit :
>
> On Mon, Jan 27, 2020, 4:57 AM Gilles Sadowski wrote:
>
> > Hello.
> >
> Hi,
>
> >
> > Le dim. 26 janv. 2020 à 18:06, Amey Jadiye a écrit
> > :
> > >
> > > For almost
narcloud.io/organizations/apache/quality_profiles/changelog?language=java=Sonar+way
Thanks for looking into it.
I too had noticed that "something" is reported as changed, but
couldn't figure out what...
Regards,
Gilles
> Regards,
> Amey
>
> On Wed, Jan 15, 2020 at 9:17 PM Gil
illes
>
> -Matt
> ____
> From: Gilles Sadowski
> Sent: Wednesday, January 15, 2020 10:47 AM
> To: Commons Developers List
> Subject: [All] Sonarcloud reports zero coverage
>
> Hello.
>
> "Sonar" reports are created for several projects, a.o.
>
Hello.
Le sam. 25 janv. 2020 à 17:56, Kartik Ohri a écrit :
>
> Hi, I am interested in working on a Stream-based Java statistical
> processing library
Thanks for your interest in contributing.
> as described here at
> https://issues.apache.org/jira/browse/STATISTICS-7 . Can someone point
> me
Hi.
2020-01-25 7:00 UTC+01:00, Asanka Amarasinghe :
> Hi,
>
> I'm new to open source community, and I would like to contribute to
> commons.lang project. I read all the materials for beginners and I already
> joined JIRA issue tracker.
Welcome.
>
> Could someone guide me to where I can find a
ds,
Gilles
> Only tempProject0 has to make its license be license0 , but that will not
> pollute apache-commons-numbers.
> although I'm not sure if this way be morals to do so, it does not break any
> rules IMO.
>
> 发件人: Gilles Sadowski
> 发送时间: 2020年1月
comply
with that license in an Apache project).
Or I must be missing something...
Gilles
>
> ____
> From: Gilles Sadowski
> Sent: Friday, January 24, 2020 5:43:49 PM
> To: Commons Developers List
> Subject: Re: [numbers] Complex to use code ported with a p
Hi.
2020-01-24 5:21 UTC+01:00, Xeno Amess :
> how about create a new project who contains the modified source function
> and original license，and in commons we just invoke that function？
>
Then, the same question(s) will be asked for that new project (?).
Regards,
Gilles
Hi.
2020-01-24 1:42 UTC+01:00, Alex Herbert :
>
>
>> On 24 Jan 2020, at 00:07, Gilles Sadowski wrote:
>>
>> Hello.
>>
>> 2020-01-24 0:30 UTC+01:00, Alex Herbert > <mailto:alex.d.herb...@gmail.com>>:
>>> In short:
>>>
>>
Hello.
2020-01-24 0:30 UTC+01:00, Alex Herbert :
> In short:
>
> - Math.hypot is required in Complex to compute sqrt(x^2 + y^2) without
> over/underflow to 1 ULP precision.
> - Complex also requires the same computation without the sqrt or
> over/underflow protection
> - I found the reference for
though the PR was closed over
> 2 years ago. Is this issue still valid?
Yes.
IOW, the question, and report, is about whether usage is consistent
across all of "Commons Numbers".
Regards,
Gilles
>
> Regards,
> Matt
>
> [1] https://github.com/apache/commons-numbers/pull
Hi.
Le jeu. 23 janv. 2020 à 15:04, Matt Juntunen
a écrit :
>
> Hello,
>
> Any chance we can get a release (beta or full) for commons-numbers?
Currently, only one unresolved issue tagged for the first release.[1]
Regards,
Gilles
[1]
> > to 2.0 (if needed).
> >
> >> Note that "Numbers" should be released first (eventually "beta" too).
> >
> > Is commons-numbers ready for a beta release as well?
I think so (this should be discussed in another post).
Regards,
Gilles
> >
>
Hello.
Le mar. 21 janv. 2020 à 14:41, Matt Juntunen
a écrit :
>
> Hello,
>
> I think that commons-geometry is ready for a beta release, as discussed
> previously. If there are no objections, how do we make that happen?
Note that "Numbers" should be released first (eventually "beta" too).
Hi.
Le mar. 21 janv. 2020 à 14:47, Rob Tompkins a écrit :
>
> I can try to help with that later this week potentially. My main question is:
> do we want to change the base package name across the component to
> `org.apache.commons.beta` for the beta release?
+1
Follow-up question: Do we
Hello.
2020-01-20 20:39 UTC+01:00, Matt Juntunen :
> Gilles,
>
>> I was not indicating that the name "EuclideanTransform" would be
>> better than "AffineTransform", I was wondering about whether the
>> class itself is redundant.
>
> Oh, I misunderstood. The "EuclideanTransform" interface is
Hello.
Le lun. 20 janv. 2020 à 16:57, Matt Juntunen
a écrit :
>
> Gilles,
>
> > From a design POV, I still think that "AffineTransform" is redundant:
>
> The "AffineTransform" name change has been reverted. It is now the original
> "EuclideanTransform".
I was not indicating that the name
>> to
>> only contain convenience methods for internal use (whereas having them
>> "protected" put them in the public API).
>
> That class also contains other matrix-specific methods (eg, "determinant")
> and the overridden "preservesOrientation". G
Hi.
2020-01-20 3:08 UTC+01:00, CT :
> Hi, In my picture search project, I need a cluster algorithm to narrow
> the dataset, for accelerate the search on millions of pictures.
> First we use python+pytorch+kmean, with the growing data from
> thousands to millions, the KMeans clustering became
ot;Transform"
can only be affine, it looks strange to have "AffineTransform" (re)defined.
I'm also a bit puzzled by the "AbstractAffineTransformMatrix" that seems to
only contain convenience methods for internal use (whereas having them
"protected" put them in t
rm
>
> commons-geometry-euclidean
> EuclideanTransform extends Transform
> AffineTransformMatrixXD implements EuclideanTransform
> Rotation3D extends EuclideanTransform
> QuaternionRotation implements Rotation3D
>
> commons-geometry-spherical
> Transform
Hi.
Le ven. 17 janv. 2020 à 13:15, Alex Herbert a écrit :
>
> The UniformRandomProvider and ContinuousUniformSampler can create
> doubles uniformly in a range [0, 1) and [x, y).
>
> I would like to create a sampler that can create doubles with random
> mantissa bits and a specified range of
Hi.
Can someone comment on GitHub that communication should be through
the "dev" ML and/or JIRA?
Thanks,
Gilles
Le jeu. 16 janv. 2020 à 17:37, GitBox a écrit :
>
> chentao106 opened a new pull request #117: Implement the
> MiniBatchKMeansClusterer
> URL:
Hello.
"Sonar" reports are created for several projects, a.o.
https://sonarcloud.io/dashboard?id=commons-numbers
https://sonarcloud.io/dashboard?id=commons-geometry
https://sonarcloud.io/dashboard?id=commons-rng
https://sonarcloud.io/dashboard?id=commons-statistics
for which
Hi.
Le mar. 14 janv. 2020 à 12:24, a écrit :
>
> [...]
>
> Add benchmark for sin/cos computation.
>
> Computing sin/cos together would improve many of the functions in
> Complex. This benchmark investigates the possibility of using the
> Commons FastMath implementation instead of
e "Transform" is intimately related to the "core" and there is a single
set of properties that make it "affine" (and work correctly), I'd tend to
keep the name "Transform". [As long as unit tests ensure that concrete
implementations possess the expected propertie
Hi.
Le ven. 10 janv. 2020 à 22:45, Alex Herbert a écrit :
>
>
>
> > On 10 Jan 2020, at 18:12, Gilles Sadowski wrote:
> >
> >> ...
> >
> > IIUC, precision (without resorting to "BigDecimal") was the purpose of
> > "LinearCombinati
Hi Alex.
Thanks a lot for this work (and all the "Complex" stuff)!
Le ven. 10 janv. 2020 à 18:18, Alex Herbert a écrit :
>
> I have been investigating the accuracy of the LinearCombination class. This
> was because I was using it to perform high precision computations in the
> Complex class
Le mer. 8 janv. 2020 à 15:15, Gary Gregory a écrit :
>
> I think it is time to bring this PR in and make any adjustments within
> master beyond that. This will be quicker and simpler than going round and
> round for simple things like Javadoc tweaks and small non-functional
> changes (formatting,
nsform
must exist" does not translate into a method
---CUT---
Transform getInverse();
---CUT---
Regards,
Gilles
> -Matt
>
> From: Gilles Sadowski
> Sent: Tuesday, January 7, 2020 6:41 PM
> To: Commons Developers List
> Subject: Re:
ich included an
> applyTransform(Transform) method.
So the "affine" requirement (in the doc) applied there too.
Anyways, what would be the issue(s) of a non-affine transform?
IOW why should implementations of "Transfrom" be restricted to affine
transform?
Regards,
Gilles
[1] h
Hello.
Le mar. 7 janv. 2020 à 16:00, Matt Juntunen
a écrit :
>
> Hi all,
>
> The documentation for the o.a.c.geometry.core.Transform interface (which
> comes from the original commons-math version) states that implementations
> must be affine. Therefore, I think we should rename this interface
Forwarding to ML.
Gilles
P.S. Please don't send to me directly when the post is meant for
the list, as otherwise hitting "Reply" will move the conversation
off-list...
-- Forwarded message -
De : Gilles Sadowski
Date: sam. 4 janv. 2020 à 19:54
Subject: Re: [Geome
?
+1
For further consolidation, could we rename "eq" to "equals", and
make "equals(Object)" call "equals(T, DoublePrecisionContext)"?
Gilles
>
> -Matt
>
> From: Gilles Sadowski
> Sent: Friday, January 3, 2020 8:
In effect, I could imagine that "fuzzy" equality could not be
commutative (random, perhaps naive, thought): an instance with
low precision would indicate that some result (where precision
could have been lost) would consider itself equal to another
instance (that may have have been set with hig
Hello.
I'm wary about making that class part of the public API.
I thought that the original idea was that users would be
responsible of how they handle the "PrecisionContext".
However, it seems that "Equivalency" requires equality
of "PrecisionContext" instances (not the "double" value).
This is
Hi.
Le dim. 29 déc. 2019 à 23:25, Alex Herbert a écrit :
>
> I’ve dropped the static equals methods and reciprocal and pushed the updated
> class with MathJax.
>
> I put MathJax in whenever possible. This may be a bit too much. The rendered
> javadoc looks good but the javadoc rendered by my
Le dim. 29 déc. 2019 à 15:30, Claude Warren a écrit :
>
> If the Shape class (BloomFilter.Shape) is extracted from the BloomFilter
> interface and made a stand-alone class would the name change or is the fact
> that it is in the o.a.c.c.bloomfilter package enough?
>
> I prefer the name Shape to
Hi.
2019-12-28 19:59 UTC+01:00, Rishabh Budhouliya :
> Hi everyone,
>
> I would like to know two things:
>
> 1) Which ported module/classes should I read and compare from commons-math
> to understand the architectural decisions taken to use lambda functions,
> streams etc all the FP paradigms in
Hi.
2019-12-29 1:15 UTC+01:00, Alex Herbert :
>
>
>> On 21 Dec 2019, at 11:42, Gilles Sadowski wrote:
>>
>>> ...
>>
>> So, would you suggest that no "Number"-like class should ever throw
>> an exception (but instead return the equivalen
Hi.
2019-12-21 1:07 UTC+01:00, Alex Herbert :
>
>
>> On 20 Dec 2019, at 23:45, Gilles Sadowski wrote:
>>
>> Le sam. 21 déc. 2019 à 00:05, Alex Herbert > <mailto:alex.d.herb...@gmail.com>> a écrit :
>>>
>>> Looking at the c++ standard [1] we
Le sam. 21 déc. 2019 à 00:05, Alex Herbert a écrit :
>
> Looking at the c++ standard [1] we are missing this function:
>
> norm() = a^2 + b^2
>
> The field norm of the complex, or the square of the absolute. An example on
> C++ reference states that this is faster for comparing magnitudes for
Le jeu. 12 déc. 2019 à 16:23, Alex Herbert a écrit :
>
>
> > OK. I'll remove ofReal() and ofImaginary().
> >
> > They can always be added later.
>
> The same may apply to square():
>
> public Complex square() {
> return multiply(this);
> }
Sure.
>
> It could be defined differently:
>
> re
Le jeu. 12 déc. 2019 à 15:20, Alex Herbert a écrit :
>
>
> On 12/12/2019 13:50, Gilles Sadowski wrote:
> > Hello.
> >
> > Le jeu. 12 déc. 2019 à 10:04, Alex Herbert a
> > écrit :
> >> There is a factory constructor:
> >>
> >> Complex
Hello.
Le jeu. 12 déc. 2019 à 10:04, Alex Herbert a écrit :
>
> There is a factory constructor:
>
> Complex.ofReal(double)
>
> For completeness I think we should add:
>
> Complex.ofImaginary(double)
I wonder whether we should remove "ofReal".
It's a shortcut that does not save a lot of typing,
2019-12-08 18:52 UTC+01:00, Alex Herbert :
>
>
>> …
>
> Would this also apply to conjugate() and conj()?
>
> ISO C99 uses conj().
+1 (Why not?)
Gilles
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional
Le dim. 8 déc. 2019 à 13:32, Alex Herbert a écrit :
>
>
>
> > On 8 Dec 2019, at 11:24, Gilles Sadowski wrote:
> >
> > Hi.
> >
> > 2019-12-08 10:45 UTC+01:00, Alex Herbert > <mailto:alex.d.herb...@gmail.com>>:
> >> On Sun, 8 Dec 2019, 0
Hi.
2019-12-08 10:45 UTC+01:00, Alex Herbert :
> On Sun, 8 Dec 2019, 01:50 Gilles Sadowski, wrote:
>
>> 2019-12-08 2:00 UTC+01:00, aherb...@apache.org :
>> > This is an automated email from the ASF dual-hosted git repository.
>> >
>> > aherbert pushed a com
2019-12-08 2:00 UTC+01:00, aherb...@apache.org :
> This is an automated email from the ASF dual-hosted git repository.
>
> aherbert pushed a commit to branch master
> in repository https://gitbox.apache.org/repos/asf/commons-numbers.git
>
> commit 65f60835e2afe26bdaba9665d62edb25195bfff6
> Author:
Hi.
Le ven. 6 déc. 2019 à 16:47, Alex Herbert a écrit :
>
> I think this method is redundant:
>
> public Complex multiply(final int factor) {
> return new Complex(real * factor, imaginary * factor);
> }
>
> given that there is:
>
> public Complex multiply(double factor) {
> return new
Test failure here:
---CUT---
ERROR] Failures:
[ERROR] CStandardTest.testCosh:692->assertComplex:275 Operation
failed (z=(-Infinity,0.5)). Expected: (-Infinity,-Infinity) but was:
(Infinity,-Infinity)
---CUT---
Gilles
2019-12-05 1:45 UTC+01:00, aherb...@apache.org :
> This is an automated email
Le mar. 3 déc. 2019 à 19:21, Alex Herbert a écrit :
>
>
> On 03/12/2019 16:43, Alex Herbert wrote:
> >
> > ...
> >
> > I am going to try option 1.
>
> Seems to be fixed now.
Thanks!
Gilles
>
> Alex
>
>
-
To unsubscribe,
measures?id=commons-statistics=coverage=list
>
> 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 supported.
>
elease) so that we can get all the possible collective
help in order
to be confident that the API is universally (!) useful.
Best regards,
Gilles
>
> -Matt
> ________
> From: Gilles Sadowski
> Sent: Tuesday, December 3, 2019 11:08 AM
> To: Commons Develope
se/GEOMETRY-73
>
> Eric
>
>
> On Tue, Dec 3, 2019 at 7:41 AM Gilles Sadowski wrote:
>
> > Hello.
> >
> > What do you think of releasing "Commons Numbers"?
> > Please have a look at the list of pending issues.[1]
> >
> > Gilles
> &
actually: the sole non-empty module!).
The proposal is to have a standalone "Commons Distribution" component
(that will depend on "Commons Numbers" and "Commons RNG").
Gilles
>
> I think it's a good idea. +1
>
> On Tue, Dec 3, 2019 at 8:00 AM
that are backwards BC.
Gilles
>
> -Matt
>
>
> [1]
> https://github.com/apache/commons-geometry/blob/master/commons-geometry-euclidean/src/main/java/org/apache/commons/geometry/euclidean/threed/Plane.java#L733
>
>
> From: Gilles Sadowski
Hello.
Are there blocking issues?
Would i be useful to release a "beta" version?
Gilles
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
Hello.
Most functionality of the "o.a.c.math4.distribution" package was migrated
from Commons Math almost 2 years ago.
The [Statistics] component should also host a refactoring of CM's "stat"
package but development has stalled. Obviously, it is unlikely that we can
perform this task in the
Hello.
What do you think of releasing "Commons Numbers"?
Please have a look at the list of pending issues.[1]
Gilles
[1]
https://issues.apache.org/jira/issues/?jql=project%20%3D%20NUMBERS%20AND%20fixVersion%20%3D%201.0%20AND%20statusCategory%20%3D%20new
Hello.
Any idea why Coveralls does not pick up the latest build for "Commons Geometry"
https://coveralls.io/github/apache/commons-geometry?branch=master
?
Coverage is quite good in fact:
https://sonarcloud.io/dashboard?id=commons-geometry
Regards,
Gilles
Hello.
Class "ConstantContinuousDistribution"[1] was ported (and renamed)
from CM's "ConstantRealDistribution".[2]
It has some strange (?) features, and no reference is mentioned in the
Javadoc.
It turns out that its sole usage is in "EmpiricalDistribution", and that
latter class is still in CM.
Hi.
Le ven. 29 nov. 2019 à 18:41, Alex Herbert a écrit :
>
> On 29/11/2019 16:48, Gilles Sadowski wrote:
> > Hello.
> >
> > For all implemented distributions, what convention should be adopted
> > when methods
> > * density(x)
> > * log
801 - 900 of 2452 matches
Mail list logo
