Re: [Numbers] Towards a release?
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, 137 related to log. I have had trouble finding > > the space to launch the regression project. But I could work on some > > smaller things. > > Great. ;-) > Hi Eric, I have another bunch of changes to complex to push. I'll do this tomorrow and then I think the c99 standard is almost done. There are a few outstanding items that I was investigating today. I'll provide a status update with a bit more time tomorrow. I don't think any work on the log functions will clash with what I have done but it would be simpler if I push first as I have tweaked a lot of the c99 functions and it may affect the log function. Alex > > > > Regarding 70, the user guide, what do you think of submitting an > > application to Google Season of Docs? > > It would be nice, but probably low(er) priority; in effect, having split > off > several components out of Commons Math has the nice (IMO) side-effect > that any of them is easier to grasp, and figuring out what it does and how > to use it is in general relatively straightforward. > Moreover, most developers looking for such tools don't have to be told what > a complex number is, and (maven) modules make it easy to navigate the > code base. > > > I can initiate if you have had quite > > 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/browse/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 > > > > > > [1] > > > > https://issues.apache.org/jira/issues/?jql=project%20%3D%20NUMBERS%20AND%20fixVersion%20%3D%201.0%20AND%20statusCategory%20%3D%20new > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > >
Re: [Geometry] Towards a release?
Gilles, I definitely agree that getting a beta release out there would be good in order to gain attention and get input from more users on the API. I don't think any of those issues I listed would be indispensable to such a release. However, it might be a good idea to 1) remove GeometryException like you've been suggesting and 2) have at least a minimal user guide in place. I can make the user guide my next focus. -Matt From: Gilles Sadowski Sent: Tuesday, December 3, 2019 1:02 PM To: Commons Developers List Subject: Re: [Geometry] Towards a release? Hi Matt. Le mar. 3 déc. 2019 à 18:37, Matt Juntunen a écrit : > > I just added a number of new issues to JIRA. The ones that I would consider > required for a 1.0 release are: > > -GEOMETRY-67 - OutlineExtractor > -GEOMETRY-68 - Raycast/Linecast API > -GEOMETRY-69 - BSPTreeVisitor stop visit > -GEOMETRY-72 - Boundary API > -GEOMETRY-77 - BoundsXD classes > -GEOMETRY-73 - Create User Guide Nice list! But which tasks would be indispensable for a 0.1 (beta) release? Indeed, I wonder whether we should try and attract some attention (through an official release) 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 Developers List > Subject: [Geometry] Towards a release? > > 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
Re: [Geometry] Coveralls stuck
On 03/12/2019 18:25, Gilles Sadowski wrote: 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 The same config fix may be needed in statistics and numbers. I'll check those later. Alex Alex - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [Geometry] Coveralls stuck
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, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [Geometry] Coveralls stuck
On 03/12/2019 16:43, Alex Herbert wrote: ... I am going to try option 1. Seems to be fixed now. Alex - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [Statistics] New component for (standard) distributions?
Hello. Le mar. 3 déc. 2019 à 18:41, Eric Barnhill a écrit : > > Sorry I misspoke. Anyway I quite agree, it would work well as > commons-distribution. +1 No problem. :) If you have time, some "little" things would be: * review the distribution classes and ensure that the conventions 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_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. > > > > > > You are proposing releasing it outside of numbers? > > > > Code is currently in module "commons-statistics-distribution", within > > the [Statistics] component (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 Gilles Sadowski > > wrote: > > > > > > > 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 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 > > of > > > > the port... > > > > > > > > WDYT? > > > > > > > > Gilles > > > > > > > > - > > > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > > > For additional commands, e-mail: dev-h...@commons.apache.org > > > > > > > > > > > > - > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > For additional commands, e-mail: dev-h...@commons.apache.org > > > > - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [Geometry] Towards a release?
Hi Matt. Le mar. 3 déc. 2019 à 18:37, Matt Juntunen a écrit : > > I just added a number of new issues to JIRA. The ones that I would consider > required for a 1.0 release are: > > -GEOMETRY-67 - OutlineExtractor > -GEOMETRY-68 - Raycast/Linecast API > -GEOMETRY-69 - BSPTreeVisitor stop visit > -GEOMETRY-72 - Boundary API > -GEOMETRY-77 - BoundsXD classes > -GEOMETRY-73 - Create User Guide Nice list! But which tasks would be indispensable for a 0.1 (beta) release? Indeed, I wonder whether we should try and attract some attention (through an official release) 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 Developers List > Subject: [Geometry] Towards a release? > > 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
Re: [Numbers] Towards a release?
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, 137 related to log. I have had trouble finding > the space to launch the regression project. But I could work on some > smaller things. Great. ;-) > > Regarding 70, the user guide, what do you think of submitting an > application to Google Season of Docs? It would be nice, but probably low(er) priority; in effect, having split off several components out of Commons Math has the nice (IMO) side-effect that any of them is easier to grasp, and figuring out what it does and how to use it is in general relatively straightforward. Moreover, most developers looking for such tools don't have to be told what a complex number is, and (maven) modules make it easy to navigate the code base. > I can initiate if you have had quite > 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/browse/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 > > > > [1] > > https://issues.apache.org/jira/issues/?jql=project%20%3D%20NUMBERS%20AND%20fixVersion%20%3D%201.0%20AND%20statusCategory%20%3D%20new - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [Statistics] New component for (standard) distributions?
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 supported. > > > > You are proposing releasing it outside of numbers? > > Code is currently in module "commons-statistics-distribution", within > the [Statistics] component (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 Gilles Sadowski > wrote: > > > > > 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 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 > of > > > the port... > > > > > > WDYT? > > > > > > Gilles > > > > > > - > > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > > For additional commands, e-mail: dev-h...@commons.apache.org > > > > > > > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > >
Re: [Geometry] Towards a release?
I just added a number of new issues to JIRA. The ones that I would consider required for a 1.0 release are: -GEOMETRY-67 - OutlineExtractor -GEOMETRY-68 - Raycast/Linecast API -GEOMETRY-69 - BSPTreeVisitor stop visit -GEOMETRY-72 - Boundary API -GEOMETRY-77 - BoundsXD classes -GEOMETRY-73 - Create User Guide -Matt From: Gilles Sadowski Sent: Tuesday, December 3, 2019 11:08 AM To: Commons Developers List Subject: [Geometry] Towards a release? 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
Re: [Numbers] Towards a release?
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 can initiate if you have had quite enough of that sort of thing. 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 > > [1] > https://issues.apache.org/jira/issues/?jql=project%20%3D%20NUMBERS%20AND%20fixVersion%20%3D%201.0%20AND%20statusCategory%20%3D%20new > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > >
Re: [Statistics] New component for (standard) distributions?
Hi. Le mar. 3 déc. 2019 à 18:23, Eric Barnhill a écrit : > > I agree, distributions seems stable and well supported. > > You are proposing releasing it outside of numbers? Code is currently in module "commons-statistics-distribution", within the [Statistics] component (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 Gilles Sadowski wrote: > > > 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 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 of > > the port... > > > > WDYT? > > > > Gilles > > > > - > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > For additional commands, e-mail: dev-h...@commons.apache.org > > > > - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [Geometry] Exceptions hierarchy
I suppose I could get on board with removing the GeometryException base class
and only using JDK exceptions in the public API. I think the best exceptions in
that case would be IllegalArgumentException and IllegalStateException,
depending on the specific case.
-Matt
From: Gilles Sadowski
Sent: Tuesday, December 3, 2019 11:42 AM
To: Commons Developers List
Subject: Re: [Geometry] Exceptions hierarchy
Hello.
2019-12-03 17:13 UTC+01:00, Matt Juntunen :
> Hello,
>
> I don't feel like ArithmeticException quite captures all of the possible
> geometry exception states. For example, it seems odd to me to throw an
> ArithmeticException when a plane cannot be constructed due to a given set of
> points being collinear [1].
In that method, argument "pts" (the list of points) is for all
purpose, a caller's mistake (requesting a plane from collinear
points), hence the result of the call should actually be that a
"IllegalArgumentException" is thrown.
I'd suggest that the "fromPoints" be refactored into
---CUT---
public static boolean isCollinear(Collection pts,
DoublePrecisionContext prec)
---CUT---
and
---CUT---
public static Plane fromPoints(Collection pts,
DoublePrecisionContext prec) {
// ...
if (isCollinear(pts, prec)) {
throw new IllegalArgumentException("Collinear points");
}
// ...
}
---CUT---
> That idea feels beyond the concept of
> "arithmetic".
IMHO, we should aim for the leanest API. In the above case, nothing
is added by throwing a custom type.
> However, I do think that the GeometryValueException subclass
> is not useful and should be removed.
+1
> On a more general note, the rule I've been following recently is to throw
> JDK exceptions like IllegalArgumentException for programming-level errors
> (eg, passing an array of the wrong length to a method) 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 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
> Sent: Thursday, November 28, 2019 8:54 PM
> To: Commons Developers List
> Subject: [Geometry] Exceptions hierarchy
>
> Hello.
>
> Is there any value added by "GeometryException" over the standard
> "ArithmeticException"?
> If not, I'd rather have the public API advertize the latter.
>
> We could have an *internal* utility class that instantiates exceptions:
> ---CUT---
> public class ExceptionFactory {
> public ArithmeticException illegalNorm(double norm) {
> return new ArithmeticException("Illegal norm: " + norm);
> }
> }
> ---CUT---
>
> Regards,
> Gilles
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
Re: [Statistics] New component for (standard) distributions?
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 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 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 of > the port... > > WDYT? > > Gilles > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > >
Re: [Numbers] Towards a release?
On 03/12/2019 15:41, Gilles Sadowski wrote: Hello. What do you think of releasing "Commons Numbers"? Please have a look at the list of pending issues.[1] I did not finish work on Complex. I have some more tests to push from a local dev branch that increase the C99 compliance. I have not yet written some standard coverage tests of the C99 reference methods. I shall get back to working on this and at least push what I have done. Alex Gilles [1] https://issues.apache.org/jira/issues/?jql=project%20%3D%20NUMBERS%20AND%20fixVersion%20%3D%201.0%20AND%20statusCategory%20%3D%20new - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [Geometry] Coveralls stuck
On 03/12/2019 14:59, Gilles Sadowski wrote:
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
The travis build [1] has this error:
[ERROR] Failed to execute goal
org.eluder.coveralls:coveralls-maven-plugin:4.3.0:report (default-cli)
on project commons-geometry-parent: Processing of input or output data
failed: Unable to parse timestamp "2019-11-30 03:33:56+": For input
string: "2019-11-30 03:33:56+" -> [Help 1]
The config is the same as commons-rng for the travis profile. However
rng uses coveralls 3.1 (for JDK 6 support). Geometry uses the latest
version 4.3 so perhaps the properties for the timestamp are ignored in
3.1 and copying the config is incorrect.
This is the config in the travis profile:
org.eluder.coveralls
coveralls-maven-plugin
${commons.coveralls.timestampFormat}
The property from parent:
EpochMillis
Does not match the input string for the timestamp. This is set here:
{0,date,-MM-dd
HH:mm:ssZ}
This configures the buildnumber-maven-plugin [2] to create a timestamp
in that format and write it to the named property, by default this is
'timestamp'.
Coveralls uses the 'timestamp' property to get the timestamp.
I had a look locally by setting the property true in
the coveralls profile.
When I run:
mvn -X jacoco:report coveralls:report -P travis
For RNG I get no configuration for the timestampFormat output by
coveralls v3.1.
For Geometry the timestampFormat configuration is:
[DEBUG] (f) timestampFormat = EpochMillis
So copying the RNG config is wrong as v3.1 did not have the property.
So either:
1. drop the configuration of and
leave it to the default (which is EpochMillis)
2. update the coveralls config to drop the
configuration and it will revert to the default of -MM-dd'T'HH:mm:ss'Z'
I am going to try option 1.
[1] https://travis-ci.org/apache/commons-geometry/jobs/618828175
[2]
https://www.mojohaus.org/buildnumber-maven-plugin/create-timestamp-mojo.html
Regards,
Gilles
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
Re: [Geometry] Exceptions hierarchy
Hello.
2019-12-03 17:13 UTC+01:00, Matt Juntunen :
> Hello,
>
> I don't feel like ArithmeticException quite captures all of the possible
> geometry exception states. For example, it seems odd to me to throw an
> ArithmeticException when a plane cannot be constructed due to a given set of
> points being collinear [1].
In that method, argument "pts" (the list of points) is for all
purpose, a caller's mistake (requesting a plane from collinear
points), hence the result of the call should actually be that a
"IllegalArgumentException" is thrown.
I'd suggest that the "fromPoints" be refactored into
---CUT---
public static boolean isCollinear(Collection pts,
DoublePrecisionContext prec)
---CUT---
and
---CUT---
public static Plane fromPoints(Collection pts,
DoublePrecisionContext prec) {
// ...
if (isCollinear(pts, prec)) {
throw new IllegalArgumentException("Collinear points");
}
// ...
}
---CUT---
> That idea feels beyond the concept of
> "arithmetic".
IMHO, we should aim for the leanest API. In the above case, nothing
is added by throwing a custom type.
> However, I do think that the GeometryValueException subclass
> is not useful and should be removed.
+1
> On a more general note, the rule I've been following recently is to throw
> JDK exceptions like IllegalArgumentException for programming-level errors
> (eg, passing an array of the wrong length to a method) 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 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
> Sent: Thursday, November 28, 2019 8:54 PM
> To: Commons Developers List
> Subject: [Geometry] Exceptions hierarchy
>
> Hello.
>
> Is there any value added by "GeometryException" over the standard
> "ArithmeticException"?
> If not, I'd rather have the public API advertize the latter.
>
> We could have an *internal* utility class that instantiates exceptions:
> ---CUT---
> public class ExceptionFactory {
> public ArithmeticException illegalNorm(double norm) {
> return new ArithmeticException("Illegal norm: " + norm);
> }
> }
> ---CUT---
>
> Regards,
> Gilles
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
[Geometry] Towards a release?
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
Re: [Geometry] Exceptions hierarchy
Hello,
I don't feel like ArithmeticException quite captures all of the possible
geometry exception states. For example, it seems odd to me to throw an
ArithmeticException when a plane cannot be constructed due to a given set of
points being collinear [1]. That idea feels beyond the concept of "arithmetic".
However, I do think that the GeometryValueException subclass is not useful and
should be removed.
On a more general note, the rule I've been following recently is to throw JDK
exceptions like IllegalArgumentException for programming-level errors (eg,
passing an array of the wrong length to a method) and GeometryException or an
appropriate subclass for errors related to geometric operations.
-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
Sent: Thursday, November 28, 2019 8:54 PM
To: Commons Developers List
Subject: [Geometry] Exceptions hierarchy
Hello.
Is there any value added by "GeometryException" over the standard
"ArithmeticException"?
If not, I'd rather have the public API advertize the latter.
We could have an *internal* utility class that instantiates exceptions:
---CUT---
public class ExceptionFactory {
public ArithmeticException illegalNorm(double norm) {
return new ArithmeticException("Illegal norm: " + norm);
}
}
---CUT---
Regards,
Gilles
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
[Statistics] New component for (standard) distributions?
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 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 of the port... WDYT? Gilles - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
[Numbers] Towards a release?
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 - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
[Geometry] Coveralls stuck
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 - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
