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
thod?
If so, that seems quite unsafe. I would not expect this behaviour
in a public API.
Unless I missed some point, I'd ask again that the API be reviewed
*before* implementing several features (such as those "extractors")
on top of something that does not look right.
Best regards,
Gilles
e usage by class name and function name.
> ```java
> @FunctionalInterface
> public interface ClusterBreeder {
> T newCenterPoint((final
> Collection> clusters);
> }
What is a "Breeder"?
This seems to further complicates the matter; what is a "center"
s alternative interpretations
of the "score". Higher will always mean better.
I've just sent another post for discussing enhancements to
the clustering API. The functional interface presented earlier
is the first topic in that other thread; let's discuss further over
there.
Regards,
Gilles
---
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] https
e should probably enforce that ranking is positive.]
Gilles
>>> [...]
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
r"), the implementation
is required to apply a conversion (e.g. return the opposite).
>>> >> }
>>> >> ```
>>> >>
>>> >> The code can be implemented by read the algorithm documents,
>>> >> or translate from python skl
}
> >
> >This method does not seem very useful.
I've now seen how this used by "MultiKMeansPlusPlusClusterer".
However, I wonder why the "Multi" feature is only available for that
implementation...
> >> }
> >> ```
> >>
> >> The cod
}
This method does not seem very useful.
> }
> ```
>
> The code can be implemented by read the algorithm documents,
> or translate from python sklearn.metrics.calinski_harabasz_score.
What's the license of that code?
Regards,
Gilles
[1]
https://commons.apache.org/proper/commons-rng/commons-rng-simple/j
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
Regard
>
> The only reason I cannot argue with is performance if it was properly
> measured in the relevant desired use cases and the measurement proves that
> the assertions pose significant performance cost.
And it was my sole point.
I obviously agree that more info is nicer, and easier t
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:
> > > >
> > > >
t; should
>>rather be:
>>---CUT---
>>public List> cluster(Collections points, DistanceMeasure
>> dist)
>>---CUT---
>>
>>And, similarly,
>>---CUT---
>>@FunctionalInterface
>>public interface ClusterFinder {
>>public int indexOf(T
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
able to fix the bug
without the stack trace?
If so, I fail to see how having the name of a variable will
make it less tricky to locate the cause of the issue...
Gilles
>> [...]
-
To unsubscribe, e-mail: dev-unsubscr.
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 :
> > >
[1]
Best regards,
Gilles
[1] https://www.urbandictionary.com/define.php?term=Thread%20Hijacking
> On Mon, Mar 2, 2020 at 6:42 PM Alex Herbert
> wrote:
>
> >
> > [Entirely unrelated conversation skipped.]
---
eNonNull() to throw an NPE, so I'd like to keep normalizing
> > on that.
> >
>
> Any thoughts? Should I proceed?
+1 for NPE on unexpected null.
[But perhaps it is not necessary to double-check, as the JRE
will do it anyway (and throw NPE).]
Gilles
>
> Gary
>
>
> >
&
eration of k-means Clustering,
> always with points reassign to clusters.
> We often use k-means as two pharse:
> Pharse 1: Training, classify thousands of points to set of clusters.
> Pharse 2: Predict, predict which cluster is best for a new point,
> or add a new point to the best c
uot;Cluster[er]" is a (Interface of )algorithm that classify points to sets
> of Cluster.
> * "CentroidCluster" is the result of a group of special Clusterer algorithm
> like k-means,
> "centroidOf" is a specific logic to calculate the center point for a
> collection of points.
> [Instead the DBScan cluster algorithm dose not care about the "Centroid"]
>
> So, "centroidOf" may be a method of "CentroidCluster[er]"(not exists yet),
> but different with "CentroidCluster.getCenter".
I may be missing something about the existing design,
but it seems strange that "CentroidCluster" is initialized
with a given "center", yet it is possible to add points after
initialization (which IIUC would invalidate the "center").
It would seem that "center" should be a property computed
from the contents of "Cluster" e.g.:
@FunctionalInterface
public interface ClusterCenterComputer {
T centroidOf(Cluster cluster);
}
Regards,
Gilles
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
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 à 1
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
Hello.
Le mer. 26 févr. 2020 à 03:49, CT a écrit :
>
> Hi Gilles,
>
>
> -- Original --
> From:"GillesSadowski" Date:Wed, Feb 26, 2020 00:32 AM
> To:"Commons Developers List"
> Subject:Re: [math] Discuss: New fe
Hello.
[Side question: Do you send a copy of your posts directly to me?
If so, that is not necessary and is even annoying because when I
hit "reply" in my mail client, the conversation continues off-list...]
Le mar. 25 févr. 2020 à 14:53, CT a écrit :
>
> Hi Gilles:
> Sorr
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,
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...@com
[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 anoth
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 remar
with CM (v3.6.1).
> but we need commons-numbers to be released before we can do that.
Indeed.
Gilles
>
> Regards,
> Matt J
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
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
ome people start to ask questions about their eventual
application.[4][5]
Is "Commons" too complicated for the target audience of
those initiatives?
Regards,
Gilles
[1] https://summerofcode.withgoogle.com/
[2] https://www.outreachy.org/
[3] Rob Tompkins, Eric Barnhill, Alex Herbe
t;
> gamma
> IllegalArgumentException
Some methods throw "ArithmeticException" while others throw
"IllegalArgumentException". IIRC, my issue was whether there
were cases where the behaviour is not consistent from a
user POV (IOW, where the same behaviour wou
there.
HTH,
Gilles
>
> On Sun, Jan 26, 2020, 7:33 PM Asanka Amarasinghe
> wrote:
>
> > Hi,
> >
> > I started with LANG-1499 (
> > https://issues.apache.org/jira/projects/LANG/issues/LANG-1499 ) . I'm
> > looking for a mentor to work with, get to know the
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
Hi.
Le dim. 26 janv. 2020 à 17:05, Matt Juntunen
a écrit :
>
> Any word on this?
I've reported this to INFRA:
https://issues.apache.org/jira/browse/INFRA-19763
See comment there: Whoever is "admin", please follow up on their
inquiry.
Thanks,
G
"stat" package, so the refactoring
is more work than porting the classes.
If you have other questions, do not hesitate to ask.
Regards,
Gilles
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
roper/commons-lang/scm.html
>
> Pardon if this is a dummy query.
It's not. Don't hesitate to ask if you find that some
documentation for beginners is difficult to find, unclear,
or outdated.
Regards,
Gilles
>
numbers is just a user of tempProject0, thus does
> not need to add license0 into apache-commons-numbers's license.
But there is no problem adding "licence0" in the "LICENSE" file (if
the license is acceptable for an ASF project, as is the case here).
Regar
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 (?).
Regard
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:
>>>
>>
the complex
> module where it applies.
IIUC, this would agree with the recommendations here:
http://www.apache.org/dev/licensing-howto.html
[By the way, we should perhaps remove the ".txt" suffix.]
Regards,
Gilles
>
>
> Background
>
> The complex class uses the Math.hypo
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]
https://issues.apache.org/jira/issues/?jql=p
> > 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
> >
>
tually "beta" too).
Best,
Gilles
>
> Regards,
> Matt J
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
stion: Do we agree that compatibility can be broken
under package "org.apache.commons.beta"?
Gilles
>
> -Rob
>
> > On Jan 21, 2020, at 8:41 AM, Matt Juntunen
> > wrote:
> >
> > Hello,
> >
> > I think that commons-geometry is ready for a beta rel
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
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
> "Euclide
Hello.
2020-01-20 14:28 UTC+01:00, Matt Juntunen :
> Gilles,
>
>> I had a (quick) look; is it necessary to split functionality among
>> "Transform"
>> (in "core") and its subinterfaces/classes in other modules? IOW, if
>> "Tra
rse when I use RandomSource.create(RandomSource.MT_64, 0)for
> the random generator ┐(´-｀)┌.
"MT_64" is probably not the best default. And this is one of the
parameters from which there should not be a default IMO.
[Note: there are spurious characters in your message (see e.g. the
paragraph
Hi.
Le sam. 18 janv. 2020 à 23:14, Matt Juntunen
a écrit :
>
> Gilles,
>
> >> There, we can simply sample the user-defined function
> > I'm not sure I understand.
>
> Just an implementation detail. We need to pass some sample points through the
> user-defin
Hello.
2020-01-18 15:40 UTC+01:00, Matt Juntunen :
> Gilles,
>
>> If the "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
t;
> // Random numbers: [0, Double.MAX_VALUE]
> FiniteDoubleSampler.of(rng);
> FiniteDoubleSampler.of(rng, -1023, 1023);
> // Random sub-normal numbers: [0, Double.MIN_NORMAL)
> FiniteDoubleSampler.of(rng, -1023, -1023);
> // Random numbers that are close to overflow: (Double.M
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: https://github.c
for which coverage is now reported as 0%, although it was reported
correctly earlier.
Regards,
Gilles
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
h implementation instead of java.util.Math.
Related issues:
https://issues.apache.org/jira/browse/MATH-901
https://issues.apache.org/jira/browse/MATH-1113
https://issues.apache.org/jira/browse/MATH-740
But CM does not provide sine and cosine in a single functio
Hi.
Le lun. 13 janv. 2020 à 04:39, Matt Juntunen
a écrit :
>
> Gilles,
>
> > How about keeping "Transform" for the interface name and define a method
> > ... boolean isAffine();
>
> I would prefer to have separate types for each kind of transform.
> This
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
hat use 3-fold precision and unroll the loops for
> small vectors.
>
>
> I think that option 2 is preferred as all split multiply methods should use
> the correct split from Dekker.
>
> I would vote for option 3 to add a higher precision version if a user
> desires. Since t
ges (formatting, variable names, and so on.) I'll proceed with that
> tonight.
Design issues were raised on the ML: With no agreement and no opinions
other than Claude's and mine, things stayed where they were.
Gilles
>> [...]
Hi.
Le mer. 8 janv. 2020 à 04:39, Matt Juntunen
a écrit :
>
> Gilles,
>
> > I thought that the question was how to replace "transform"...
>
> I should probably clarify. I want to change the name of the Transform class
> to make it clear that it only r
Le mar. 7 janv. 2020 à 17:55, Matt Juntunen
a écrit :
>
> Gilles,
>
> > "AffineMap" (?)
>
> I think any name that doesn't include the word "transform" somehow would
> probably be confusing.
This is supposed to be a synonym.[1]
I thought tha
?)
> - I'm not sure if the term "affine" can technically be applied to
> non-Euclidean geometries, such as spherical geometry (there may be nuances
> there that I'm not aware of).
Was the same "Transform" interface used in both the "euclidean" and the
&quo
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
Hello.
2020-01-04 6:10 UTC+01:00, Matt Juntunen :
> Gilles,
>
> I took another look at the code and it turns out we can easily remove the
> entire Equivalency interface and just use methods of the form "eq(T,
> DoublePrecisionContext)", exactly the same way that the Vec
Hi.
2020-01-03 22:02 UTC+01:00, Matt Juntunen :
> Gilles,
>
> Yes, users are responsible for handling their own PrecisionContexts. The
> idea behind the Equivalency interface was to provide an easy way to perform
> "fuzzy" comparisons between objects. The interface itse
tances (not the "double" value).
This is non-obvious and IMHO deserves some explanation
in the Javadoc and user guide.
Regards,
Gilles
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
ut and
> reformat from the ISO C99 Annex G that the class has been tested against.
How about including a link to the respective C++ doc pages?
Regards,
Gilles
>
> [1] https://en.cppreference.com/w/c/numeric/complex/cacos
> <https://en.cppreference.com/w/c/numeric/complex/
fer the name Shape to BloomFilterShape.
If "Shape" is only used for "BloomFilter" (as the suggestion above
seems to indicate, why not declare it as a sub-interface:
---CUT---
public interface BloomFilter {
// ...
public interface Shape {
// ...
}
}
---CUT---
?
kage should be user
in place of the function object defined in Commons Math.
> I hope this is the appropriate channel to raise such requests, I apologize
> if I spammed some guys!
It's the right place.
Thanks for your interest,
Gilles
>
> Regards,
> Rishabh Budhouliya
>
---
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
finite even when
> the other part is nan.
>
>
> I suggest we update ofPolar to not throw exceptions and return NAN unless
> theta is finite and rho is non-negative and non-nan.
+0
Not sure how useful it is to instantiate a useless object.
Regards,
Gilles
>
> Ale
e overflow protection and handling of
> special cases done in multiply. So I'd rather leave it calling
> multiply(this). So the square() method seems redundant and I would
> recommend dropping it.
+1
>
> It was originally used in computations. Now it is not.
Thanks,
Gilles
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
ternally. I'd keep those "private".
For the API, perhaps a more general
---CUT---
public Complex multiplyImaginary(double im) {
return ofCartesian(-im * imaginary, im * real);
}
---CUT---
?
Gilles
> These two operations appear a lot in the formulas for the trigonomic
> funct
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.a
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
5195bfff6
> Author: Alex Herbert
> AuthorDate: Sun Dec 8 00:54:03 2019 +
>
> Added getAbsolute() to complement getArgument().
Is that name part of the reference?
If not, "getMagnitude" or "getModulus" would be clearer.
Gilles
> ---
>
valent for divide(double) (i.e. divide(int)).
>
> I propose to remove this method.
+1
>
>
> I would like to reorder the internals of Complex to be like the order of
> the C99 reference.
+1
Gilles
> At the moment the methods are a bit jumbled.
>
> I think something l
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
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
>
>
entions are uniform
(we had some issues raised in relation to the naming of the parameters): i.e.
all implementations should ideally comply with the articles on Wikipedia and/or
MathWorld,
* increase code coverage (through unit tests).[1]
Best,
Gilles
[1]
https://sonarcloud.io/component_
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
> enough of that sort of thing.
Indeed, delegating documentation tasks was often more work than it would
have been doing it! :-}
However, a user guide for "Commons Geometry" is on the TODO list.[1]
You should then coordinate with Matt.
Thanks,
Gilles
[1] https://issues.apache.org/jira/brow
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
ethod) and GeometryException
> or an appropriate subclass for errors related to geometric operations.
I understand the willingness to make a distinction but what purpose
does it serve from a user's POV? And from our POV, all these "little"
things will get in the way of making changes
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
an
perform this task in the short term, while the design of the "distribution"
module looks fairly stable (and it had already been refactored within CM).
IMO, it should belong to its own maven project so it can be released without
being encumbered for months (or years?) by the instability of the rest
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%2
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
Regar
at
latter class is still in CM. Perhaps this special-purpose implementation
was needed there as a workaround... Hence I propose to move it back
to CM. Moreover I would make it a private nested class of class
"EmpiricalDistribution"
Any objection?
Regards,
Gilles
[1]
https
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 4251 matches
Mail list logo
