Re: [configuration] review for PR 30

[Gary Gregory]

On Mon, Jul 1, 2019 at 6:46 PM Emmanuel Bourg  wrote:

> Le 01/07/2019 à 16:26, Gary Gregory a écrit :
>
> > May anyone that knows enough of the internals of [configuration] please
> > comment on https://github.com/apache/commons-configuration/pull/30
>
> I got a quick look, besides the setArrayProperty method that doesn't
> seem to have the right name (there is nothing specific to arrays in the
> implementation, it just sets the value as is) the PR looks good.
>

What would you call the method?

Gary


>
> Emmanuel Bourg
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

Re: [configuration] review for PR 30

[Emmanuel Bourg]

Le 01/07/2019 à 16:26, Gary Gregory a écrit :

> May anyone that knows enough of the internals of [configuration] please
> comment on https://github.com/apache/commons-configuration/pull/30

I got a quick look, besides the setArrayProperty method that doesn't
seem to have the right name (there is nothing specific to arrays in the
implementation, it just sets the value as is) the PR looks good.

Emmanuel Bourg

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [numbers-fraction] Documentation of fractions' reduction to lowest terms

[Gilles Sadowski]

Hello.

Le lun. 1 juil. 2019 à 20:23, Heinrich Bohne  a écrit :
>
> > Is there a case where *not* knowing whether the fraction is reduced or
> > not is detrimental?
>
> Hm, maybe you're right and specifying this (as well as where the sign is
> stored) in the public API is not that important, as long as the
> combination of returned numerator and denominator is valid. The only
> benefit would have been that the user would have the certainty that the
> returned values are already reduced to lowest terms, so that, in case
> this matters to the user, they don't need to reduce the values
> themselves. But whether this would outweigh the reduced flexibility of
> the API is something that probably cannot be answered without the
> ability to predict the future.
>
> However, what *is* crucial is specifying these things in the
> documentation of the private fields that hold the numerator and
> denominator, because a lot of the class' implementation relies on this.

Sure.
The code doc should indicate all current assumptions.
By not leaking them into the public API, we keep the flexibility until
usage requires to go one way or another.

> In fact, I noticed that BigFraction.hashCode() was broken before the
> resolution of NUMBERS-119 and NUMBERS-125, because, while
> BigFraction.equals(Object) reduced the numerators and denominators
> before comparing them, hashCode() didn't.
>
> Specifying the reduction to lowest terms of the fields numerator and
> denominator is even more important in Fraction than in BigFraction,
> because the magnitude of the values stored in these fields has an impact
> on whether arithmetic operations overflow or don't.

Agreed, but it's not clear to me that it must be part of the public API.

Gilles

>
> On 7/1/19 7:03 PM, Gilles Sadowski wrote:
> > Hello.
> >
> > Le lun. 1 juil. 2019 à 12:35, Heinrich Bohne  a 
> > écrit :
> >>> Couldn't it entail a loss of opportunity to allow "non-reduced" fractions
> >>> for efficiency reason?
> >> Yes, it would, but I can't envision a scenario where this would be
> >> detrimental. Of course, I may be missing something.
> > Is there a case where *not* knowing whether the fraction is reduced or
> > not is detrimental?
> >
> >>> But I don't follow; if it's an implementation detail, it should not appear
> >>> anywhere in the doc, and users should not rely on it.
> >> What I meant is that it would be an implementation detail how the
> >> numerator and denominator are stored. What the methods getNumerator()
> >> and getDenominator() return should, of course, be specified
> >> appropriately (for example, something like "returns the numerator of
> >> this fraction's representation in lowest terms").
> >>
> >> It just occurred to me that the question of where something should be
> >> documented can also be applied to the sign being held by the numerator
> >> rather than the denominator in case of negative fractions (which, if I'm
> >> not mistaken, is currently only specified in
> >> Fraction.getReducedFraction(int, int), a method that is targeted for
> >> deletion in https://issues.apache.org/jira/browse/NUMBERS-125 ).
> > Good catch.
> > It's a similar issue: Is knowing where the sign is stored useful to users or
> > can it be considered an implementation detail (leaving more freedom to
> > change it)?
> > Wouldn't a method "isNegative()" be a better alternative?
> >
> > Regards,
> > Gilles
> >
> >
> >>
> >> On 7/1/19 9:32 AM, Gilles Sadowski wrote:
> >>> Hi.
> >>>
> >>> Le lun. 1 juil. 2019 à 03:52, Heinrich Bohne  a 
> >>> écrit :
>  I've recently been wondering about the following:
> 
>  With the resolution of NUMBERS-119
>  (https://issues.apache.org/jira/browse/NUMBERS-119), all constructors in
>  Fraction and BigFraction reduce the created fraction to lowest terms (in
>  the constructor Fraction(double, double, int, int), this is not obvious,
>  but because the convergents of a simple continued fraction are
>  automatically reduced to lowest terms when calculated with the recursive
>  formula used in the constructor, the fraction returned thereof is also
>  reduced to lowest terms).
> 
>  This rises the following question: Would it not be better if this
>  reduction to lowest terms were made part of the contract of the two
>  fields storing the numerator and denominator (i.e. included in their
>  documentation), and, as a consequence, of the corresponding public
>  accessor methods?
> >>> Couldn't it entail a loss of opportunity to allow "non-reduced" fractions
> >>> for efficiency reason?
> >>>
>  Then the fact that the fraction is reduced to lowest
>  terms when created from a constructor or a public factory method would
>  become an implementation detail irrelevant to the caller of the
>  method/constructor, which could also prevent confusion, seeing as the
>  numerator-denominator factory methods are the only ones that explicitly
>  state that the fraction is reduced

Re: [GSoC][Commons][Statistics][Descriptive] Should Standard Deviation extend Variance & Variance extend Moment class?

[Gilles Sadowski]

Le lun. 1 juil. 2019 à 22:47, Alex Herbert  a écrit :
>
> Re-sent to list.
>
> > On 1 Jul 2019, at 18:49, Gilles Sadowski  wrote:
> >
> > Le lun. 1 juil. 2019 à 19:10, Alex Herbert  > > a écrit :
> >>
> >> On 01/07/2019 08:59, Gilles Sadowski wrote:
> >>> Hello.
> >>>
> >>> Le lun. 1 juil. 2019 à 00:50, Virendra singh Rajpurohit
> >>>  a écrit :
>  Hi everyone,
>  I've been working on descriptive module of "Commons-Statistics". My
>  question is should I extend
> >>> I'll give hints as if the question mark was after the word "extend".
> >>>
> >>> For starter, please read this:
> >>> 
> >>> https://books.google.fr/books?id=ka2VUBqHiWkC&pg=PA81&lpg=PA81&dq=java+inheritance+bloch&source=bl&ots=y_IgRku_OX&sig=ACfU3U3VMmrHT2ILGJQluunGLJcEOMICBA&hl=fr&sa=X&ved=2ahUKEwicsvv6nJPjAhVwx4UKHdU6BFUQ6AEwBXoECAkQAQ#v=onepage&q=java%20inheritance%20bloch&f=false
> >>> (and the whole book is advice to follow).
> >>>
> >>> Then, there might be some useful information here:
> >>> 
> >>> https://stackoverflow.com/questions/218744/good-reasons-to-prohibit-inheritance-in-java
> >>>
> >>> Regards,
> >>> Gilles
> >>
> >> This issue arises because the algorithms for the mean and the variance
> >> share computation and the standard deviation is derived from the variance.
> >>
> >> They can be combined using inheritance. The reference above indicates
> >> that this is poor practice unless you specifically design for it.
> >> Splitting them all apart as separate classes will result in code
> >> duplication. This is also considered poor practice without a good
> >> reason. However there is one good reason in this case (as I will show
> >> later).
> >
> > Avoiding duplication is a corollary of inheritance, but not the condition
> > for using it.
> > There must an "is-a" relationship.
> >
> >> The solution in Commons Math was to have a package-private set of moment
> >> classes that have an inheritance hierarchy. The public facing classes
> >> can then wrap these internal classes and avoid inheritance. However in
> >> Commons math some of the public constructors depended on package private
> >> moment classes, and one moment class was public. So the API was flawed.
> >> This is the subject of an issue which discusses removing the moment
> >> classes and avoiding inheritance [1]. The outcome of this discussion
> >> (from 2016) is not in the Jira ticket.
> >>
> >> There is also the question of whether the third and fourth central
> >> moments should be ported from Commons Math with the associated Skewness
> >> and Kurtosis statistics. It should be noted that at the limit of this
> >> hierarchy the fourth central moment has the data to compute Mean,
> >> Variance+Standard Deviation, Skewness and Kurtosis.
> >>
> >> Although it is possible to compute many statistics from a moment I would
> >> say it can be assumed if the user has selected a specific statistic
> >> class then they are only interested in 1 statistic. Construction of a
> >> flexible SummaryStatistics class to provide multiple statistics should
> >> be part of the design and so objects to compute different moments and
> >> the ability to use them to compute different statistics should be part
> >> of the design. This can be addressed separately but should be kept in mind.
> >>
> >> If inheritance is eliminated at the jump from 1st to 2nd moment it will
> >> result in a small amount of code duplication.:
> >>
> >> Moment1 = 4 lines
> >> Moment2 = 1 extra line (5 total)
> >> Moment3 = 4 extra lines (9 total)
> >> Moment4 = 4 extra lines (13 total)
> >>
> >> However all protected variables used in the hierarchy can be local to
> >> the method and the code (although duplicated) may be easier to follow.
> >>
> >> If the requirements of a moment are specified in an interface it can be
> >> seen that the hierarchy is simple:
> >>
> >> interface FirstMoment {
> >> long getN();
> >> double getM1();
> >> void accept(double d);
> >> void combine(FirstMoment m1);
> >> }
> >>
> >> interface SecondMoment extends FirstMoment {
> >> double getM2();
> >> void combine(SecondMoment m2);
> >> }
> >>
> >> interface ThirdMoment extends SecondMoment {
> >> double getM3();
> >> void combine(ThirdMoment m3);
> >> }
> >
> > "is-a" condition is not met.
>
> Do you mean that ThirdMoment “is-a” SecondMoment is not true? While this is 
> correct the way the algorithm is implemented means that a ThirdMoment does 
> have all the data for the lower order moments.
>
> >
> > Another direction to explore:
> >
> > interface Moment {
> >long getN();
> >double getValue();
> >void accept(double);
> >void combine(Moment m);
> > }
>
> And  is an enum?

It's not what I had in mind, but I didn't pursue it because I thought
that testing different approaches was Virendra's task...
As you point out much below, first step is to lay out the minimally
supported API.

Gilles

> I do not see how this helps this:
>
> ThirdMoment 

Re: [GSoC][Commons][Statistics][Descriptive] Should Standard Deviation extend Variance & Variance extend Moment class?

[Alex Herbert]

Re-sent to list.

> On 1 Jul 2019, at 18:49, Gilles Sadowski  wrote:
> 
> Le lun. 1 juil. 2019 à 19:10, Alex Herbert  > a écrit :
>> 
>> On 01/07/2019 08:59, Gilles Sadowski wrote:
>>> Hello.
>>> 
>>> Le lun. 1 juil. 2019 à 00:50, Virendra singh Rajpurohit
>>>  a écrit :
 Hi everyone,
 I've been working on descriptive module of "Commons-Statistics". My
 question is should I extend
>>> I'll give hints as if the question mark was after the word "extend".
>>> 
>>> For starter, please read this:
>>> 
>>> https://books.google.fr/books?id=ka2VUBqHiWkC&pg=PA81&lpg=PA81&dq=java+inheritance+bloch&source=bl&ots=y_IgRku_OX&sig=ACfU3U3VMmrHT2ILGJQluunGLJcEOMICBA&hl=fr&sa=X&ved=2ahUKEwicsvv6nJPjAhVwx4UKHdU6BFUQ6AEwBXoECAkQAQ#v=onepage&q=java%20inheritance%20bloch&f=false
>>> (and the whole book is advice to follow).
>>> 
>>> Then, there might be some useful information here:
>>> 
>>> https://stackoverflow.com/questions/218744/good-reasons-to-prohibit-inheritance-in-java
>>> 
>>> Regards,
>>> Gilles
>> 
>> This issue arises because the algorithms for the mean and the variance
>> share computation and the standard deviation is derived from the variance.
>> 
>> They can be combined using inheritance. The reference above indicates
>> that this is poor practice unless you specifically design for it.
>> Splitting them all apart as separate classes will result in code
>> duplication. This is also considered poor practice without a good
>> reason. However there is one good reason in this case (as I will show
>> later).
> 
> Avoiding duplication is a corollary of inheritance, but not the condition
> for using it.
> There must an "is-a" relationship.
> 
>> The solution in Commons Math was to have a package-private set of moment
>> classes that have an inheritance hierarchy. The public facing classes
>> can then wrap these internal classes and avoid inheritance. However in
>> Commons math some of the public constructors depended on package private
>> moment classes, and one moment class was public. So the API was flawed.
>> This is the subject of an issue which discusses removing the moment
>> classes and avoiding inheritance [1]. The outcome of this discussion
>> (from 2016) is not in the Jira ticket.
>> 
>> There is also the question of whether the third and fourth central
>> moments should be ported from Commons Math with the associated Skewness
>> and Kurtosis statistics. It should be noted that at the limit of this
>> hierarchy the fourth central moment has the data to compute Mean,
>> Variance+Standard Deviation, Skewness and Kurtosis.
>> 
>> Although it is possible to compute many statistics from a moment I would
>> say it can be assumed if the user has selected a specific statistic
>> class then they are only interested in 1 statistic. Construction of a
>> flexible SummaryStatistics class to provide multiple statistics should
>> be part of the design and so objects to compute different moments and
>> the ability to use them to compute different statistics should be part
>> of the design. This can be addressed separately but should be kept in mind.
>> 
>> If inheritance is eliminated at the jump from 1st to 2nd moment it will
>> result in a small amount of code duplication.:
>> 
>> Moment1 = 4 lines
>> Moment2 = 1 extra line (5 total)
>> Moment3 = 4 extra lines (9 total)
>> Moment4 = 4 extra lines (13 total)
>> 
>> However all protected variables used in the hierarchy can be local to
>> the method and the code (although duplicated) may be easier to follow.
>> 
>> If the requirements of a moment are specified in an interface it can be
>> seen that the hierarchy is simple:
>> 
>> interface FirstMoment {
>> long getN();
>> double getM1();
>> void accept(double d);
>> void combine(FirstMoment m1);
>> }
>> 
>> interface SecondMoment extends FirstMoment {
>> double getM2();
>> void combine(SecondMoment m2);
>> }
>> 
>> interface ThirdMoment extends SecondMoment {
>> double getM3();
>> void combine(ThirdMoment m3);
>> }
> 
> "is-a" condition is not met.

Do you mean that ThirdMoment “is-a” SecondMoment is not true? While this is 
correct the way the algorithm is implemented means that a ThirdMoment does have 
all the data for the lower order moments.

> 
> Another direction to explore:
> 
> interface Moment {
>long getN();
>double getValue();
>void accept(double);
>void combine(Moment m);
> }

And  is an enum?

I do not see how this helps this:

ThirdMoment m3 = …
Variance var = new Variance(m3);

If ThirdMoment is to be used generically it needs a method to obtain the value 
for all moments from 3 to 1. The single ‘getValue()’ is not enough. It would 
require:

interface Moment {
   long getN();
   double getValue(M extends MomentOrder);
   void accept(double);
   void combine(Moment m);
}

Where M is <= T in the enum ranking. So basically it is an integer and you can 
restrict the combine method using self-types:

interface Mome

Re: [numbers-fraction] Documentation of fractions' reduction to lowest terms

[Heinrich Bohne]

Is there a case where *not* knowing whether the fraction is reduced or
not is detrimental?


Hm, maybe you're right and specifying this (as well as where the sign is
stored) in the public API is not that important, as long as the
combination of returned numerator and denominator is valid. The only
benefit would have been that the user would have the certainty that the
returned values are already reduced to lowest terms, so that, in case
this matters to the user, they don't need to reduce the values
themselves. But whether this would outweigh the reduced flexibility of
the API is something that probably cannot be answered without the
ability to predict the future.

However, what *is* crucial is specifying these things in the
documentation of the private fields that hold the numerator and
denominator, because a lot of the class' implementation relies on this.
In fact, I noticed that BigFraction.hashCode() was broken before the
resolution of NUMBERS-119 and NUMBERS-125, because, while
BigFraction.equals(Object) reduced the numerators and denominators
before comparing them, hashCode() didn't.

Specifying the reduction to lowest terms of the fields numerator and
denominator is even more important in Fraction than in BigFraction,
because the magnitude of the values stored in these fields has an impact
on whether arithmetic operations overflow or don't.

On 7/1/19 7:03 PM, Gilles Sadowski wrote:

Hello.

Le lun. 1 juil. 2019 à 12:35, Heinrich Bohne  a écrit :

Couldn't it entail a loss of opportunity to allow "non-reduced" fractions
for efficiency reason?

Yes, it would, but I can't envision a scenario where this would be
detrimental. Of course, I may be missing something.

Is there a case where *not* knowing whether the fraction is reduced or
not is detrimental?


But I don't follow; if it's an implementation detail, it should not appear
anywhere in the doc, and users should not rely on it.

What I meant is that it would be an implementation detail how the
numerator and denominator are stored. What the methods getNumerator()
and getDenominator() return should, of course, be specified
appropriately (for example, something like "returns the numerator of
this fraction's representation in lowest terms").

It just occurred to me that the question of where something should be
documented can also be applied to the sign being held by the numerator
rather than the denominator in case of negative fractions (which, if I'm
not mistaken, is currently only specified in
Fraction.getReducedFraction(int, int), a method that is targeted for
deletion in https://issues.apache.org/jira/browse/NUMBERS-125 ).

Good catch.
It's a similar issue: Is knowing where the sign is stored useful to users or
can it be considered an implementation detail (leaving more freedom to
change it)?
Wouldn't a method "isNegative()" be a better alternative?

Regards,
Gilles




On 7/1/19 9:32 AM, Gilles Sadowski wrote:

Hi.

Le lun. 1 juil. 2019 à 03:52, Heinrich Bohne  a écrit :

I've recently been wondering about the following:

With the resolution of NUMBERS-119
(https://issues.apache.org/jira/browse/NUMBERS-119), all constructors in
Fraction and BigFraction reduce the created fraction to lowest terms (in
the constructor Fraction(double, double, int, int), this is not obvious,
but because the convergents of a simple continued fraction are
automatically reduced to lowest terms when calculated with the recursive
formula used in the constructor, the fraction returned thereof is also
reduced to lowest terms).

This rises the following question: Would it not be better if this
reduction to lowest terms were made part of the contract of the two
fields storing the numerator and denominator (i.e. included in their
documentation), and, as a consequence, of the corresponding public
accessor methods?

Couldn't it entail a loss of opportunity to allow "non-reduced" fractions
for efficiency reason?


Then the fact that the fraction is reduced to lowest
terms when created from a constructor or a public factory method would
become an implementation detail irrelevant to the caller of the
method/constructor, which could also prevent confusion, seeing as the
numerator-denominator factory methods are the only ones that explicitly
state that the fraction is reduced to lowest terms, even though this is
true for all other factory methods as well.

The doc should be fixed.
But I don't follow; if it's an implementation detail, it should not appear
anywhere in the doc, and users should not rely on it.

Regards,
Gilles


Also, fractions returned from arithmetic operations are thereby also
implicitly specified as being reduced to lowest terms, rendering
mentions of this fact in these methods' documentation obsolete.

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org





-
To

Re: [numbers-fraction] Documentation of fractions' reduction to lowest terms

[Gilles Sadowski]

Hello.

Le lun. 1 juil. 2019 à 12:35, Heinrich Bohne  a écrit :
>
> > Couldn't it entail a loss of opportunity to allow "non-reduced" fractions
> > for efficiency reason?
>
> Yes, it would, but I can't envision a scenario where this would be
> detrimental. Of course, I may be missing something.

Is there a case where *not* knowing whether the fraction is reduced or
not is detrimental?

>
> > But I don't follow; if it's an implementation detail, it should not appear
> > anywhere in the doc, and users should not rely on it.
>
> What I meant is that it would be an implementation detail how the
> numerator and denominator are stored. What the methods getNumerator()
> and getDenominator() return should, of course, be specified
> appropriately (for example, something like "returns the numerator of
> this fraction's representation in lowest terms").
>
> It just occurred to me that the question of where something should be
> documented can also be applied to the sign being held by the numerator
> rather than the denominator in case of negative fractions (which, if I'm
> not mistaken, is currently only specified in
> Fraction.getReducedFraction(int, int), a method that is targeted for
> deletion in https://issues.apache.org/jira/browse/NUMBERS-125 ).

Good catch.
It's a similar issue: Is knowing where the sign is stored useful to users or
can it be considered an implementation detail (leaving more freedom to
change it)?
Wouldn't a method "isNegative()" be a better alternative?

Regards,
Gilles


>
>
> On 7/1/19 9:32 AM, Gilles Sadowski wrote:
> > Hi.
> >
> > Le lun. 1 juil. 2019 à 03:52, Heinrich Bohne  a 
> > écrit :
> >> I've recently been wondering about the following:
> >>
> >> With the resolution of NUMBERS-119
> >> (https://issues.apache.org/jira/browse/NUMBERS-119), all constructors in
> >> Fraction and BigFraction reduce the created fraction to lowest terms (in
> >> the constructor Fraction(double, double, int, int), this is not obvious,
> >> but because the convergents of a simple continued fraction are
> >> automatically reduced to lowest terms when calculated with the recursive
> >> formula used in the constructor, the fraction returned thereof is also
> >> reduced to lowest terms).
> >>
> >> This rises the following question: Would it not be better if this
> >> reduction to lowest terms were made part of the contract of the two
> >> fields storing the numerator and denominator (i.e. included in their
> >> documentation), and, as a consequence, of the corresponding public
> >> accessor methods?
> > Couldn't it entail a loss of opportunity to allow "non-reduced" fractions
> > for efficiency reason?
> >
> >> Then the fact that the fraction is reduced to lowest
> >> terms when created from a constructor or a public factory method would
> >> become an implementation detail irrelevant to the caller of the
> >> method/constructor, which could also prevent confusion, seeing as the
> >> numerator-denominator factory methods are the only ones that explicitly
> >> state that the fraction is reduced to lowest terms, even though this is
> >> true for all other factory methods as well.
> > The doc should be fixed.
> > But I don't follow; if it's an implementation detail, it should not appear
> > anywhere in the doc, and users should not rely on it.
> >
> > Regards,
> > Gilles
> >
> >> Also, fractions returned from arithmetic operations are thereby also
> >> implicitly specified as being reduced to lowest terms, rendering
> >> mentions of this fact in these methods' documentation obsolete.

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [VOTE] Release Apache Commons Text 1.7 based on RC1

[Rob Tompkins]

Reports good; specifically, japicmp good, rat good; signatures good; builds on 
java8 and java11 with “mvn clean test install site.”

+1

> On Jun 30, 2019, at 10:28 AM, Gary Gregory  wrote:
> 
> We have fixed quite a few bugs and added some significant enhancements
> since Apache Commons Text 1.6 was released, so I would like to release
> Apache Commons Text 1.7.
> 
> Apache Commons Text 1.7 RC1 is available for review here:
>https://dist.apache.org/repos/dist/dev/commons/text/1.7-RC1 (svn
> revision 34703)
> 
> The Git tag commons-text-1.7-RC1 commit for this RC is
> 3866d2626dc3767b003c7cfe163a388b10c80957 which you can browse here:
> 
> https://gitbox.apache.org/repos/asf?p=commons-text.git;a=commit;h=3866d2626dc3767b003c7cfe163a388b10c80957
> You may checkout this tag using:
>git clone https://gitbox.apache.org/repos/asf/commons-text.git --branch
> commons-text-1.7-RC1 commons-text-1.7-RC1
> 
> Maven artifacts are here:
> 
> https://repository.apache.org/content/repositories/orgapachecommons-1445/org/apache/commons/commons-text/1.7/
> 
> These are the artifacts and their hashes:
> 
> #Release SHA-512s
> #Sun Jun 30 10:15:20 EDT 2019
> commons-text-1.7-bin.tar.gz=b900c07380f986c916e8fba6bff561ddf5bd1362d8b7b4b4487a780cb78ba86fc3cf0b30fc6b07053fca26a893ada44134fc2d0ab31bee6394e44f411ad3cdb4
> commons-text-1.7-bin.tar.gz.asc=0b5d581f3c085ae428ef2c149c74127d9a1070f5ea2cdfe8394446cc6b2481ea712d07b3a65fb455bfbb991027138dc633b3845a083041b5b8f8d295080a3ab0
> commons-text-1.7-bin.zip=d97c7021c568b349a4ae09f5fcfae3a6ce592aec83b46f7c9c9777c945e3555a25e93ef39544eb4430ee00206aca2979e35542709d23461f0229c2df80744234
> commons-text-1.7-bin.zip.asc=a861e9786b00fec6c39ea6705e388c3b08225a8f5fc399c2f68d09b6d61b60fd16337731d71013e8eccb178b7d6c4c53bfdec5363139bf9bd42d7605b8b21c15
> commons-text-1.7-javadoc.jar=138588633e95974fadca17340ec771e1bea8a614e53ec37aaa9b86fc4a09ee3bfc2645f207ff2fa9c4c53c664ee767d14a6a683145d0165ff94f5e1d4b8d7a14
> commons-text-1.7-javadoc.jar.asc=7fc209412ced402547eade377a3e184572a503b11cdccde3c043023601f351f26235b56fd94ad00158e25c5e1a8d0055e7e8e88a5cb0d0448cddd2f0da054a73
> commons-text-1.7-sources.jar=380158e7aa99be61608dd53b7929e48cc4d4f4e898221033205d36b22f6d59046f67fceaa1df832ca3f6760515980a5df4b9c450ced43e4aa9ee26fab22baaa7
> commons-text-1.7-sources.jar.asc=1db512a3af2ad5c04617dcf896e611bee7a029ec51b9892bea02504fc283212b4d6d3c44af703d31a3802e5bf4f5fb537d455d50b070aa4e4b0ffe4902c381d5
> commons-text-1.7-src.tar.gz=5660e4566e55b42e3b6ca22cd50affa232f5477e9ac30bd244eea7cdedc7f588d633e54aeb52bdec77506a8cbab22124b8c2fd6a94901140df75a75751775106
> commons-text-1.7-src.tar.gz.asc=fa3486f6f0ed1521875a4a4e41028e10680149440fa1c9ea9960cc8cb3cca5ce3ceaad41336ac8bf62b100c187a7b9ed4608d84230f57a33e66ecc1fa9464a64
> commons-text-1.7-src.zip=e168f84b109a2d174e6c51ce3a94606e00a2ac1373a88486e9dca735133e3a1f3e906b580e59f1aa38d9dd2f31774dba9f5d1a0b402db3fd87d9aa36438d713b
> commons-text-1.7-src.zip.asc=81a06410fbb81055b8580b4b7a9d635b8f5ccc851419aa23346e87f67578d09b8cc16637713bb4595998086651b7256400af3b134db5bbbea8b6255b4afe8438
> commons-text-1.7-test-sources.jar=d2ead377bfc1f57efb4f885764b47e956b702063147c550dbc71789681654612aec69d0d585f5afac52a3b650e4c72189f68f6eef3b3e06427dc53ff0f58ff20
> commons-text-1.7-test-sources.jar.asc=1e9e481115338f1213ddacdaaebfbbc611c7cfe9816b0f432ea143fee2777e8a19b5bc987e1438a97b9b9a7afc1fe01188be7b055494c47bede93c1e366ee37a
> commons-text-1.7-tests.jar=b6109fee5d299cd0d0985938b65703b7b1941995d00eeb169d98de18c1eabbaff7feeb258bab819e5a6a4dc06a9647235b900b2bd2457296810e2fabf64b
> commons-text-1.7-tests.jar.asc=2f6297a03538e6b128e505aab34cce75790e9256c6545e964ee3918eac88dfb69d2fddaa845242022a55354b9a6911e207a190f8b81b7e6e6d19eeb986096511
> commons-text-1.7.jar.asc=566460a04edb42c34a7d5bda1b255804a61a134a08ae881af6a1b3476ca178da1bc27f2900776785a4a2af8fc7cec74935791e354e1b91885e356e3873172aa0
> commons-text-1.7.pom.asc=d481dd4360ca514b9279b5e38780f65b33555cc07c927f761e5ca1df1d6e013ffb0390245d6ac5046cef77be0102465a133f9c4663eb14f0316f987033bd0074
> 
> (no need for .asc hashes!)
> 
> I have tested this with 'mvn -V -Duser.name=%my_apache_id%
> -Dcommons.release-plugin.version=%commons.release-plugin.version%
> -Ddoclint=none -Prelease -Pjacoco -Ptest-deploy clean package site deploy'
> using:
> 
> Apache Maven 3.6.1 (d66c9c0b3152b2e69ee9bac180bb8fcc8e6af555;
> 2019-04-04T15:00:29-04:00)
> Maven home: C:\Java\apache-maven-3.6.1\bin\..
> Java version: 1.8.0_212, vendor: Oracle Corporation, runtime: C:\Program
> Files\Java\jdk1.8.0_212\jre
> Default locale: en_US, platform encoding: Cp1252
> OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows"
> 
> After the above, I ran 'mvn -V test' with:
> 
> Apache Maven 3.6.1 (d66c9c0b3152b2e69ee9bac180bb8fcc8e6af555;
> 2019-04-04T15:00:29-04:00)
> Maven home: C:\Java\apache-maven-3.6.1\bin\..
> Java version: 11.0.3, vendor: Oracle Corporation, runtime: C:\Program
> Files\Java\jdk-11.0.3
> Default locale: en_US, platfor

Re: [VOTE] Release Apache Commons Daemon 1.2.0 RC2

[Rob Tompkins]

+1, reports good, signatures good, agree with Gary on builds.

-Rob

> On Jun 28, 2019, at 10:20 AM, Mark Thomas  wrote:
> 
> It has been ~18 months since the last Commons Daemon release. After the
> recent flurry of activity and a couple of failed RCs, it is time for
> another release vote.
> 
> Notable changes since 1.1.0 include:
> - Improved JRE/JDK detection to support increased range of both JVM
>  versions and vendors.
> - Procrun. Minimum target platform for Windows binaries is now Windows 7
> - Procrun. Change the default service from LocalSystem to
>  'NT Authority\LocalService'
> 
> The full set of changes is in the changelog
> 
> 1.2.0 RC2 can be obtained from (r34680):
> https://dist.apache.org/repos/dist/dev/commons/daemon/
> 
> The git tag is:
> Tag: COMMONS_DAEMON_1_2_0_RC2
> URL:
> https://gitbox.apache.org/repos/asf?p=commons-daemon.git;a=commit;h=d88fd9100c1110fa51b7c7a08e3e7efd0e58227b
> Hash:  d88fd9100c1110fa51b7c7a08e3e7efd0e58227b
> 
> The Maven Staging repo is:
> https://repository.apache.org/content/repositories/orgapachecommons-1443/
> 
> The Windows binaries have been signed by the Symantec code signing service.
> 
> Files signed with my preferred key:
> http://people.apache.org/~markt/
> KEYS file is standard Apache Commons keys file:
> http://www.apache.org/dist/commons/KEYS
> 
> 
> [ ] Approved - go ahead and release Commons Daemon 1.2.0 RC2 as 1.2.0
> [ ] Broken   - do not release because...
> 
> -
> 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

[configuration] review for PR 30

[Gary Gregory]

Hi All:

May anyone that knows enough of the internals of [configuration] please
comment on https://github.com/apache/commons-configuration/pull/30

?

Gary

Re: [numbers-fraction] Documentation of fractions' reduction to lowest terms

[Heinrich Bohne]

Couldn't it entail a loss of opportunity to allow "non-reduced" fractions
for efficiency reason?


Yes, it would, but I can't envision a scenario where this would be
detrimental. Of course, I may be missing something.


But I don't follow; if it's an implementation detail, it should not appear
anywhere in the doc, and users should not rely on it.


What I meant is that it would be an implementation detail how the
numerator and denominator are stored. What the methods getNumerator()
and getDenominator() return should, of course, be specified
appropriately (for example, something like "returns the numerator of
this fraction's representation in lowest terms").

It just occurred to me that the question of where something should be
documented can also be applied to the sign being held by the numerator
rather than the denominator in case of negative fractions (which, if I'm
not mistaken, is currently only specified in
Fraction.getReducedFraction(int, int), a method that is targeted for
deletion in https://issues.apache.org/jira/browse/NUMBERS-125 ).


On 7/1/19 9:32 AM, Gilles Sadowski wrote:

Hi.

Le lun. 1 juil. 2019 à 03:52, Heinrich Bohne  a écrit :

I've recently been wondering about the following:

With the resolution of NUMBERS-119
(https://issues.apache.org/jira/browse/NUMBERS-119), all constructors in
Fraction and BigFraction reduce the created fraction to lowest terms (in
the constructor Fraction(double, double, int, int), this is not obvious,
but because the convergents of a simple continued fraction are
automatically reduced to lowest terms when calculated with the recursive
formula used in the constructor, the fraction returned thereof is also
reduced to lowest terms).

This rises the following question: Would it not be better if this
reduction to lowest terms were made part of the contract of the two
fields storing the numerator and denominator (i.e. included in their
documentation), and, as a consequence, of the corresponding public
accessor methods?

Couldn't it entail a loss of opportunity to allow "non-reduced" fractions
for efficiency reason?


Then the fact that the fraction is reduced to lowest
terms when created from a constructor or a public factory method would
become an implementation detail irrelevant to the caller of the
method/constructor, which could also prevent confusion, seeing as the
numerator-denominator factory methods are the only ones that explicitly
state that the fraction is reduced to lowest terms, even though this is
true for all other factory methods as well.

The doc should be fixed.
But I don't follow; if it's an implementation detail, it should not appear
anywhere in the doc, and users should not rely on it.

Regards,
Gilles


Also, fractions returned from arithmetic operations are thereby also
implicitly specified as being reduced to lowest terms, rendering
mentions of this fact in these methods' documentation obsolete.

-
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: [GSoC][Commons][Statistics][Descriptive] Should Standard Deviation extend Variance & Variance extend Moment class?

[Gilles Sadowski]

Hello.

Le lun. 1 juil. 2019 à 00:50, Virendra singh Rajpurohit
 a écrit :
>
> Hi everyone,
> I've been working on descriptive module of "Commons-Statistics". My
> question is should I extend

I'll give hints as if the question mark was after the word "extend".

For starter, please read this:

https://books.google.fr/books?id=ka2VUBqHiWkC&pg=PA81&lpg=PA81&dq=java+inheritance+bloch&source=bl&ots=y_IgRku_OX&sig=ACfU3U3VMmrHT2ILGJQluunGLJcEOMICBA&hl=fr&sa=X&ved=2ahUKEwicsvv6nJPjAhVwx4UKHdU6BFUQ6AEwBXoECAkQAQ#v=onepage&q=java%20inheritance%20bloch&f=false
(and the whole book is advice to follow).

Then, there might be some useful information here:

https://stackoverflow.com/questions/218744/good-reasons-to-prohibit-inheritance-in-java

Regards,
Gilles

> Variance class in StandardDeviaiton class?
> Also, should Moment classes be developed and inherited in Variance? As of
> now, I created only FirstMoment  & Variance class. If the answer for
> inheritance is NO, should we rename FirstMoment to Mean?
> Thanks
> --
> Warm Regards
> *Virendra Singh Rajpurohit*
> *University of Petroleum and Energy Studies,Dehradun*
> Linkedin:https://www.linkedin.com/in/virendra-singh-rajpurohit
>

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [numbers-fraction] Documentation of fractions' reduction to lowest terms

[Gilles Sadowski]

Hi.

Le lun. 1 juil. 2019 à 03:52, Heinrich Bohne  a écrit :
>
> I've recently been wondering about the following:
>
> With the resolution of NUMBERS-119
> (https://issues.apache.org/jira/browse/NUMBERS-119), all constructors in
> Fraction and BigFraction reduce the created fraction to lowest terms (in
> the constructor Fraction(double, double, int, int), this is not obvious,
> but because the convergents of a simple continued fraction are
> automatically reduced to lowest terms when calculated with the recursive
> formula used in the constructor, the fraction returned thereof is also
> reduced to lowest terms).
>
> This rises the following question: Would it not be better if this
> reduction to lowest terms were made part of the contract of the two
> fields storing the numerator and denominator (i.e. included in their
> documentation), and, as a consequence, of the corresponding public
> accessor methods?

Couldn't it entail a loss of opportunity to allow "non-reduced" fractions
for efficiency reason?

> Then the fact that the fraction is reduced to lowest
> terms when created from a constructor or a public factory method would
> become an implementation detail irrelevant to the caller of the
> method/constructor, which could also prevent confusion, seeing as the
> numerator-denominator factory methods are the only ones that explicitly
> state that the fraction is reduced to lowest terms, even though this is
> true for all other factory methods as well.

The doc should be fixed.
But I don't follow; if it's an implementation detail, it should not appear
anywhere in the doc, and users should not rely on it.

Regards,
Gilles

> Also, fractions returned from arithmetic operations are thereby also
> implicitly specified as being reduced to lowest terms, rendering
> mentions of this fact in these methods' documentation obsolete.

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org