You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Luc Maisonobe <lu...@spaceroots.org> on 2013/03/04 13:24:33 UTC
[math] releasing 3.2?
Hi all,
I would like to release version 3.2 of [math] soon.
Any thoughts about it?
Luc
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [math] releasing 3.2?
Posted by Phil Steitz <ph...@gmail.com>.
On 3/27/13 8:13 AM, Thomas Neidhart wrote:
> On Wed, Mar 27, 2013 at 4:09 PM, Phil Steitz <ph...@gmail.com> wrote:
>
>> On 3/27/13 12:03 AM, Thomas Neidhart wrote:
>>> On 03/26/2013 11:03 PM, Phil Steitz wrote:
>>>> On 3/25/13 8:52 AM, Luc Maisonobe wrote:
>>>>> Hi all,
>>>>>
>>>>> Le 23/03/2013 16:30, Thomas Neidhart a écrit :
>>>>>> On 03/04/2013 01:57 PM, Gilles wrote:
>>>>>>> Hello.
>>>>>>>
>>>>>>>> I would like to release version 3.2 of [math] soon.
>>>>>>>> Any thoughts about it?
>>>>>>> How soon?
>>>>>>> There are many unresolved issues targetting 3.2.
>>>>>>> There is at least one bug with no fix target (MATH-936).
>>>>>>> There is at least one contribution requiring some feedback
>> (MATH-917).
>>>>>> I have added a first patch and would love to get some feedback.
>>>>> It seems we are really close to releasing now. I guess MATH-817 will be
>>>>> resolved soon. What seems to be achievable in a short time frame would
>> be:
>>>>> - wrapping up MATH-917 as Thomas proposed,
>>>>> - finishing MATH-437 (Kolmogorov-Smirnov), and perhaps also
>>>>> MATH-228 at the same time
>>>> See comment just added to MATH-437. I am working on it, but not
>>>> ready to commit to API, so say bump this to 3.3/4.0.
>>>>
>>>> One thing I did not mention in the MATH-437 comment. While I think
>>>> we should not do it in the K-S case, because the dist itself has
>>>> little value and much numeric instability, the approximation tricks
>>>> in your patch are interesting and might merit inclusion in
>>>> AbstractRealDistribution (which actually is where the impls belong).
>>> Hi Phil,
>>>
>>> can you maybe also take a look at MATH-981? I have already provided a
>>> patch, but would like to hear your opinion on this as it is more a
>>> work-around for the moment.
>> Hmmm. Can't find 981 and no permutation looks that interesting ;)
>>
> sorry, its MATH-891
Geez. I can't even do permutations this AM :)
See comments on the ticket.
Phil
>
> Thomas
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [math] releasing 3.2?
Posted by Thomas Neidhart <th...@gmail.com>.
On Wed, Mar 27, 2013 at 4:09 PM, Phil Steitz <ph...@gmail.com> wrote:
> On 3/27/13 12:03 AM, Thomas Neidhart wrote:
> > On 03/26/2013 11:03 PM, Phil Steitz wrote:
> >> On 3/25/13 8:52 AM, Luc Maisonobe wrote:
> >>> Hi all,
> >>>
> >>> Le 23/03/2013 16:30, Thomas Neidhart a écrit :
> >>>> On 03/04/2013 01:57 PM, Gilles wrote:
> >>>>> Hello.
> >>>>>
> >>>>>> I would like to release version 3.2 of [math] soon.
> >>>>>> Any thoughts about it?
> >>>>> How soon?
> >>>>> There are many unresolved issues targetting 3.2.
> >>>>> There is at least one bug with no fix target (MATH-936).
> >>>>> There is at least one contribution requiring some feedback
> (MATH-917).
> >>>> I have added a first patch and would love to get some feedback.
> >>> It seems we are really close to releasing now. I guess MATH-817 will be
> >>> resolved soon. What seems to be achievable in a short time frame would
> be:
> >>>
> >>> - wrapping up MATH-917 as Thomas proposed,
> >>> - finishing MATH-437 (Kolmogorov-Smirnov), and perhaps also
> >>> MATH-228 at the same time
> >> See comment just added to MATH-437. I am working on it, but not
> >> ready to commit to API, so say bump this to 3.3/4.0.
> >>
> >> One thing I did not mention in the MATH-437 comment. While I think
> >> we should not do it in the K-S case, because the dist itself has
> >> little value and much numeric instability, the approximation tricks
> >> in your patch are interesting and might merit inclusion in
> >> AbstractRealDistribution (which actually is where the impls belong).
> > Hi Phil,
> >
> > can you maybe also take a look at MATH-981? I have already provided a
> > patch, but would like to hear your opinion on this as it is more a
> > work-around for the moment.
>
> Hmmm. Can't find 981 and no permutation looks that interesting ;)
>
sorry, its MATH-891
Thomas
Re: [math] releasing 3.2?
Posted by Phil Steitz <ph...@gmail.com>.
On 3/27/13 12:03 AM, Thomas Neidhart wrote:
> On 03/26/2013 11:03 PM, Phil Steitz wrote:
>> On 3/25/13 8:52 AM, Luc Maisonobe wrote:
>>> Hi all,
>>>
>>> Le 23/03/2013 16:30, Thomas Neidhart a écrit :
>>>> On 03/04/2013 01:57 PM, Gilles wrote:
>>>>> Hello.
>>>>>
>>>>>> I would like to release version 3.2 of [math] soon.
>>>>>> Any thoughts about it?
>>>>> How soon?
>>>>> There are many unresolved issues targetting 3.2.
>>>>> There is at least one bug with no fix target (MATH-936).
>>>>> There is at least one contribution requiring some feedback (MATH-917).
>>>> I have added a first patch and would love to get some feedback.
>>> It seems we are really close to releasing now. I guess MATH-817 will be
>>> resolved soon. What seems to be achievable in a short time frame would be:
>>>
>>> - wrapping up MATH-917 as Thomas proposed,
>>> - finishing MATH-437 (Kolmogorov-Smirnov), and perhaps also
>>> MATH-228 at the same time
>> See comment just added to MATH-437. I am working on it, but not
>> ready to commit to API, so say bump this to 3.3/4.0.
>>
>> One thing I did not mention in the MATH-437 comment. While I think
>> we should not do it in the K-S case, because the dist itself has
>> little value and much numeric instability, the approximation tricks
>> in your patch are interesting and might merit inclusion in
>> AbstractRealDistribution (which actually is where the impls belong).
> Hi Phil,
>
> can you maybe also take a look at MATH-981? I have already provided a
> patch, but would like to hear your opinion on this as it is more a
> work-around for the moment.
Hmmm. Can't find 981 and no permutation looks that interesting ;)
Phil
>
> Thanks,
>
> Thomas
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [math] releasing 3.2?
Posted by Thomas Neidhart <th...@gmail.com>.
On 03/26/2013 11:03 PM, Phil Steitz wrote:
> On 3/25/13 8:52 AM, Luc Maisonobe wrote:
>> Hi all,
>>
>> Le 23/03/2013 16:30, Thomas Neidhart a écrit :
>>> On 03/04/2013 01:57 PM, Gilles wrote:
>>>> Hello.
>>>>
>>>>> I would like to release version 3.2 of [math] soon.
>>>>> Any thoughts about it?
>>>> How soon?
>>>> There are many unresolved issues targetting 3.2.
>>>> There is at least one bug with no fix target (MATH-936).
>>>
>>>> There is at least one contribution requiring some feedback (MATH-917).
>>> I have added a first patch and would love to get some feedback.
>> It seems we are really close to releasing now. I guess MATH-817 will be
>> resolved soon. What seems to be achievable in a short time frame would be:
>>
>> - wrapping up MATH-917 as Thomas proposed,
>> - finishing MATH-437 (Kolmogorov-Smirnov), and perhaps also
>> MATH-228 at the same time
> See comment just added to MATH-437. I am working on it, but not
> ready to commit to API, so say bump this to 3.3/4.0.
>
> One thing I did not mention in the MATH-437 comment. While I think
> we should not do it in the K-S case, because the dist itself has
> little value and much numeric instability, the approximation tricks
> in your patch are interesting and might merit inclusion in
> AbstractRealDistribution (which actually is where the impls belong).
Hi Phil,
can you maybe also take a look at MATH-981? I have already provided a
patch, but would like to hear your opinion on this as it is more a
work-around for the moment.
Thanks,
Thomas
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [math] releasing 3.2?
Posted by Phil Steitz <ph...@gmail.com>.
On 3/25/13 8:52 AM, Luc Maisonobe wrote:
> Hi all,
>
> Le 23/03/2013 16:30, Thomas Neidhart a écrit :
>> On 03/04/2013 01:57 PM, Gilles wrote:
>>> Hello.
>>>
>>>> I would like to release version 3.2 of [math] soon.
>>>> Any thoughts about it?
>>> How soon?
>>> There are many unresolved issues targetting 3.2.
>>> There is at least one bug with no fix target (MATH-936).
>>
>>> There is at least one contribution requiring some feedback (MATH-917).
>> I have added a first patch and would love to get some feedback.
> It seems we are really close to releasing now. I guess MATH-817 will be
> resolved soon. What seems to be achievable in a short time frame would be:
>
> - wrapping up MATH-917 as Thomas proposed,
> - finishing MATH-437 (Kolmogorov-Smirnov), and perhaps also
> MATH-228 at the same time
See comment just added to MATH-437. I am working on it, but not
ready to commit to API, so say bump this to 3.3/4.0.
One thing I did not mention in the MATH-437 comment. While I think
we should not do it in the K-S case, because the dist itself has
little value and much numeric instability, the approximation tricks
in your patch are interesting and might merit inclusion in
AbstractRealDistribution (which actually is where the impls belong).
Phil
> - removing cobertura from parent
>
> I would propose to postpone MATH-873, MATH-923 and MATH-874 to 4.0.
>
> What do you think?
>
> Luc
>
>> Thomas
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [Math] MATH-917 (Was: [math] releasing 3.2?)
Posted by Thomas Neidhart <th...@gmail.com>.
On 03/26/2013 08:07 PM, Thomas Neidhart wrote:
> On 03/26/2013 01:38 PM, Gilles wrote:
>>>> [...]
>>>>>
>>>>>> There is at least one contribution requiring some feedback (MATH-917).
>>>>>
>>>>> I have added a first patch and would love to get some feedback.
>>>>
>>>> It seems we are really close to releasing now. I guess MATH-817 will be
>>>> resolved soon. What seems to be achievable in a short time frame
>>>> would be:
>>>>
>>>> - wrapping up MATH-917 as Thomas proposed,
>>>> - finishing MATH-437 (Kolmogorov-Smirnov), and perhaps also
>>>> MATH-228 at the same time
>>>> - removing cobertura from parent
>>>>
>>>> I would propose to postpone MATH-873, MATH-923 and MATH-874 to 4.0.
>>>>
>>>> What do you think?
>>>
>>> Looks good. I will finish my work on MATH-917 till Wednesday the latest.
>>
>> I wonder whether "Clusterable" should be (the generic type seems
>> superfluous):
>
> you are right, I did remove the generic type already in my local
> environment.
>
>> public interface Clusterable {
>> double[] getClusteringData();
>> }
>>
>> And the "distance" interface simplified to:
>>
>> public interface Distance {
>> double compute(double[] a, double[] b);
>> }
>>
>> The concept being more general than just for clustering, the interface and
>> its implementations probably belong elsewhere, e.g. in "o.a.c.m.util" (or
>> perhaps even better as static inner classes of "MathArrays").
>
> I thought about this too, but the downside would be that any Clusterable
> must have a double[] internally. Having dimension() and component(int)
> methods is more flexible imho, but both approaches have their benefits.
>
>> "AbstractClusterer" should be immutable (i.e. no distance setter).
>>
>> If using interfaces, the "getDistanceMeasure" method should probably appear
>> in one of them. Maybe:
>>
>> public interface Clusterer<T extends Clusterable> {
>> List<? extends Cluster<T>> cluster(Collection<T> points);
>> Distance getDistance();
>> }
>>
>> However, in line with what we've been doing the last 3 or 4 years,
>> "Clusterer" could just be an abstract class.
>
> I was musing about making the Clusterer implementations immutable, or to
> create setters for their necessary parameters, e.g. the k parameter for
> k-means.
>
> Otherwise you have to create a new object each time you want to change
> something, would this be acceptable?
>
> Another thing that I changed locally: the KMeans clusterer currently
> supports multi-evaluation with a separate method. This could be moved to
> a separate class MultiKMeansPlusPlusClusterer, which allows to use it
> with the same Clusterer interface.
I have updated the patch, and also taken your suggestions into account.
Right now the Clusterable interface is untouched, but the
DistanceMeasure interface now accepts double[] as input.
The AbstractClusterer provides a convenience method to calculate the
distance of two Clusterable instances by converting them first to arrays
and then calling DistanceMeasure#compute.
I think it is a good compromise, but it would also be easy to change the
Clusterable interface to just return a double[].
Thomas
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [Math] MATH-917 (Was: [math] releasing 3.2?)
Posted by Thomas Neidhart <th...@gmail.com>.
On 03/26/2013 01:38 PM, Gilles wrote:
>>> [...]
>>>>
>>>>> There is at least one contribution requiring some feedback (MATH-917).
>>>>
>>>> I have added a first patch and would love to get some feedback.
>>>
>>> It seems we are really close to releasing now. I guess MATH-817 will be
>>> resolved soon. What seems to be achievable in a short time frame
>>> would be:
>>>
>>> - wrapping up MATH-917 as Thomas proposed,
>>> - finishing MATH-437 (Kolmogorov-Smirnov), and perhaps also
>>> MATH-228 at the same time
>>> - removing cobertura from parent
>>>
>>> I would propose to postpone MATH-873, MATH-923 and MATH-874 to 4.0.
>>>
>>> What do you think?
>>
>> Looks good. I will finish my work on MATH-917 till Wednesday the latest.
>
> I wonder whether "Clusterable" should be (the generic type seems
> superfluous):
you are right, I did remove the generic type already in my local
environment.
> public interface Clusterable {
> double[] getClusteringData();
> }
>
> And the "distance" interface simplified to:
>
> public interface Distance {
> double compute(double[] a, double[] b);
> }
>
> The concept being more general than just for clustering, the interface and
> its implementations probably belong elsewhere, e.g. in "o.a.c.m.util" (or
> perhaps even better as static inner classes of "MathArrays").
I thought about this too, but the downside would be that any Clusterable
must have a double[] internally. Having dimension() and component(int)
methods is more flexible imho, but both approaches have their benefits.
> "AbstractClusterer" should be immutable (i.e. no distance setter).
>
> If using interfaces, the "getDistanceMeasure" method should probably appear
> in one of them. Maybe:
>
> public interface Clusterer<T extends Clusterable> {
> List<? extends Cluster<T>> cluster(Collection<T> points);
> Distance getDistance();
> }
>
> However, in line with what we've been doing the last 3 or 4 years,
> "Clusterer" could just be an abstract class.
I was musing about making the Clusterer implementations immutable, or to
create setters for their necessary parameters, e.g. the k parameter for
k-means.
Otherwise you have to create a new object each time you want to change
something, would this be acceptable?
Another thing that I changed locally: the KMeans clusterer currently
supports multi-evaluation with a separate method. This could be moved to
a separate class MultiKMeansPlusPlusClusterer, which allows to use it
with the same Clusterer interface.
Thomas
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
[Math] MATH-917 (Was: [math] releasing 3.2?)
Posted by Gilles <gi...@harfang.homelinux.org>.
>> [...]
>>>
>>>> There is at least one contribution requiring some feedback
>>>> (MATH-917).
>>>
>>> I have added a first patch and would love to get some feedback.
>>
>> It seems we are really close to releasing now. I guess MATH-817 will
>> be
>> resolved soon. What seems to be achievable in a short time frame
>> would be:
>>
>> - wrapping up MATH-917 as Thomas proposed,
>> - finishing MATH-437 (Kolmogorov-Smirnov), and perhaps also
>> MATH-228 at the same time
>> - removing cobertura from parent
>>
>> I would propose to postpone MATH-873, MATH-923 and MATH-874 to 4.0.
>>
>> What do you think?
>
> Looks good. I will finish my work on MATH-917 till Wednesday the
> latest.
I wonder whether "Clusterable" should be (the generic type seems
superfluous):
public interface Clusterable {
double[] getClusteringData();
}
And the "distance" interface simplified to:
public interface Distance {
double compute(double[] a, double[] b);
}
The concept being more general than just for clustering, the interface
and
its implementations probably belong elsewhere, e.g. in "o.a.c.m.util"
(or
perhaps even better as static inner classes of "MathArrays").
"AbstractClusterer" should be immutable (i.e. no distance setter).
If using interfaces, the "getDistanceMeasure" method should probably
appear
in one of them. Maybe:
public interface Clusterer<T extends Clusterable> {
List<? extends Cluster<T>> cluster(Collection<T> points);
Distance getDistance();
}
However, in line with what we've been doing the last 3 or 4 years,
"Clusterer" could just be an abstract class.
Regards,
Gilles
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [math] releasing 3.2?
Posted by Thomas Neidhart <th...@gmail.com>.
On 03/25/2013 04:52 PM, Luc Maisonobe wrote:
> Hi all,
>
> Le 23/03/2013 16:30, Thomas Neidhart a écrit :
>> On 03/04/2013 01:57 PM, Gilles wrote:
>>> Hello.
>>>
>>>>
>>>> I would like to release version 3.2 of [math] soon.
>>>> Any thoughts about it?
>>>
>>> How soon?
>>> There are many unresolved issues targetting 3.2.
>>> There is at least one bug with no fix target (MATH-936).
>>
>>
>>> There is at least one contribution requiring some feedback (MATH-917).
>>
>> I have added a first patch and would love to get some feedback.
>
> It seems we are really close to releasing now. I guess MATH-817 will be
> resolved soon. What seems to be achievable in a short time frame would be:
>
> - wrapping up MATH-917 as Thomas proposed,
> - finishing MATH-437 (Kolmogorov-Smirnov), and perhaps also
> MATH-228 at the same time
> - removing cobertura from parent
>
> I would propose to postpone MATH-873, MATH-923 and MATH-874 to 4.0.
>
> What do you think?
Looks good. I will finish my work on MATH-917 till Wednesday the latest.
Thomas
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [math] releasing 3.2?
Posted by Luc Maisonobe <Lu...@free.fr>.
Hi all,
Le 23/03/2013 16:30, Thomas Neidhart a écrit :
> On 03/04/2013 01:57 PM, Gilles wrote:
>> Hello.
>>
>>>
>>> I would like to release version 3.2 of [math] soon.
>>> Any thoughts about it?
>>
>> How soon?
>> There are many unresolved issues targetting 3.2.
>> There is at least one bug with no fix target (MATH-936).
>
>
>> There is at least one contribution requiring some feedback (MATH-917).
>
> I have added a first patch and would love to get some feedback.
It seems we are really close to releasing now. I guess MATH-817 will be
resolved soon. What seems to be achievable in a short time frame would be:
- wrapping up MATH-917 as Thomas proposed,
- finishing MATH-437 (Kolmogorov-Smirnov), and perhaps also
MATH-228 at the same time
- removing cobertura from parent
I would propose to postpone MATH-873, MATH-923 and MATH-874 to 4.0.
What do you think?
Luc
>
> Thomas
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [math] releasing 3.2?
Posted by Thomas Neidhart <th...@gmail.com>.
On 03/04/2013 01:57 PM, Gilles wrote:
> Hello.
>
>>
>> I would like to release version 3.2 of [math] soon.
>> Any thoughts about it?
>
> How soon?
> There are many unresolved issues targetting 3.2.
> There is at least one bug with no fix target (MATH-936).
> There is at least one contribution requiring some feedback (MATH-917).
I have added a first patch and would love to get some feedback.
Thomas
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [math] releasing 3.2?
Posted by Thomas Neidhart <th...@gmail.com>.
On Mon, Mar 4, 2013 at 1:57 PM, Gilles <gi...@harfang.homelinux.org> wrote:
> Hello.
>
>
>
>> I would like to release version 3.2 of [math] soon.
>> Any thoughts about it?
>>
>
> How soon?
> There are many unresolved issues targetting 3.2.
> There is at least one bug with no fix target (MATH-936).
>
I did look into this one already.
The actual bug is quite simple to fix:
* if 0.0 is returned by the RandomGenerator, return the lower bound
The bigger problem is that the applied scaling is not robust:
double scaled = r * upper + (1.0 - r) * lower + r;
so for large values of lower/upper, as in the bug example this will lead to
wrong results.
Thomas
Re: [math] releasing 3.2?
Posted by Thomas Neidhart <th...@gmail.com>.
On Mon, Mar 4, 2013 at 3:04 PM, Luc Maisonobe <lu...@spaceroots.org> wrote:
> Le 04/03/2013 13:57, Gilles a écrit :
> > Hello.
>
> Hi Gilles,
>
> >
> >>
> >> I would like to release version 3.2 of [math] soon.
> >> Any thoughts about it?
> >
> > How soon?
>
> Say next week for example.
>
> > There are many unresolved issues targetting 3.2.
> > There is at least one bug with no fix target (MATH-936).
>
> I'll look at this one.
>
> > There is at least one contribution requiring some feedback (MATH-917).
>
> You are right. I agree with the suggestion you made in your first
> comment to separate Distance from Point. Thomas proposal to have a
> dedicated interface seems good to me.
>
> I have no opinion about the global package layout (inside stat or not).
> If we change package, then this should be done at 4.0.
>
> >
> > Releasing would be fine anyway, but maybe name it "3.1.2"?
>
> That would be fine with me.
>
> Luc
>
Hi,
I think MATH-917 can wait till 4.0, I will also need to think more about it.
For anything else, I will try to help, especially for the things that have
changed since we moved to svnpubsub.
Thomas
Re: [math] releasing 3.2?
Posted by Luc Maisonobe <lu...@spaceroots.org>.
Le 04/03/2013 13:57, Gilles a écrit :
> Hello.
Hi Gilles,
>
>>
>> I would like to release version 3.2 of [math] soon.
>> Any thoughts about it?
>
> How soon?
Say next week for example.
> There are many unresolved issues targetting 3.2.
> There is at least one bug with no fix target (MATH-936).
I'll look at this one.
> There is at least one contribution requiring some feedback (MATH-917).
You are right. I agree with the suggestion you made in your first
comment to separate Distance from Point. Thomas proposal to have a
dedicated interface seems good to me.
I have no opinion about the global package layout (inside stat or not).
If we change package, then this should be done at 4.0.
>
> Releasing would be fine anyway, but maybe name it "3.1.2"?
That would be fine with me.
Luc
>
>
> Regards,
> Gilles
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [math] releasing 3.2?
Posted by Gilles <gi...@harfang.homelinux.org>.
Hello.
>
> I would like to release version 3.2 of [math] soon.
> Any thoughts about it?
How soon?
There are many unresolved issues targetting 3.2.
There is at least one bug with no fix target (MATH-936).
There is at least one contribution requiring some feedback (MATH-917).
Releasing would be fine anyway, but maybe name it "3.1.2"?
Regards,
Gilles
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [math] releasing 3.2?
Posted by Thomas Neidhart <th...@gmail.com>.
On 03/04/2013 01:24 PM, Luc Maisonobe wrote:
> Hi all,
>
> I would like to release version 3.2 of [math] soon.
> Any thoughts about it?
Maybe somebody wants to take a look at MATH-891.
I created a patch but was unsure about it due to the dynamic cast.
Thomas
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [math] releasing 3.2?
Posted by sebb <se...@gmail.com>.
On 11 March 2013 08:33, Luc Maisonobe <Lu...@free.fr> wrote:
> Le 11/03/2013 08:51, Luc Maisonobe a écrit :
>> Le 11/03/2013 00:47, sebb a écrit :
>>> On 10 March 2013 16:35, Luc Maisonobe <Lu...@free.fr> wrote:
>>>> Le 10/03/2013 15:28, Thomas Neidhart a écrit :
>>>>> On 03/04/2013 01:24 PM, Luc Maisonobe wrote:
>>>>>> Hi all,
>>>>>>
>>>>>> I would like to release version 3.2 of [math] soon.
>>>>>> Any thoughts about it?
>>>>>
>>>>> There are 3 Clirr errors:
>>>>>
>>>>> Error Return type of method 'public int log10()' has been changed to
>>>>> org.apache.commons.math3.dfp.Dfp
>>>>
>>>> I know about this one, it was introduced with r1449529. I have explained
>>>> it here: <http://markmail.org/message/2ytqu4qmtkkp5v4z>.
>>>>
>>>> I would in fact consider this change is merely fixing a bug: the log10
>>>> function returned an int when all other mathematical functions properly
>>>> returned a Dfp. The change was two-fold: the log10 method returning an
>>>> int was renamed intLog10, and a proper log10 method was added.
>>>>
>>>> I really don't think anybody will be affected by this change, as the
>>>> class itself is probably very seldom used, and most importantly because
>>>> despite this weird return type, nobody noticed it and complained about it.
>>>>
>>>> So I would consider this incompatible change should be accepted, even in
>>>> a minor release.
>>>>
>>>
>>> Sorry, I disagree.
>>>
>>> As far as I can tell, Math 3.1 only included
>>>
>>> public int log10()
>>> public int log10K()
>>
>> Dfp also had sqrt, reciprocal, and nextAfter with Dfp return types (as
>> well as a static copysign with a lower case s and two arguments, not the
>> classical non-static with upper case S and one argument). The other
>> functions like cos, sin etc also already existed but as static methods
>> in DfpMath.
>>
>>>
>>> so it's not entirely surprising that no-one complained about the return type.
>>>
>>> If it is still decided to ignore the incompatibilty, please document
>>> this clearly in the release notes, and ensure log10K() Javadoc states
>>> why it has a different return type from all the others.
>>
>> Yes, I'll do that.
>
> Maybe I found a way to remove this incompatibility.
>
> If we remove completely the declaration of log10(), which must return an
> instance of T, in the parameterized interface RealFieldElement<T>, then
> all implementations may have a different log10 method. This would allow
> Dfp to keep its strange return type, at least for the 3.x series, while
> DerivativeStructure and Decimal64 can return the proper type.
>
> Then in 4.0, when we can add incompatible changes, we can add the
> declaration back, change Dfp and have all implementations becoming
> consistent with respect to this method return type.
>
> For additional smooth transition for Dfp, we can already add the new
> intLog10 method, and deprecate log10 declaring it will change its return
> type as of 4.0.
>
> The only drawback of this hack is that log10 would not be available in
> parameterized classes, but only in classes where we already know what T
> is, and for which we can directly point to the class implementation and
> not the interface specification.
>
> I'll commit this in a few minutes so the CLIRR report will be ... clear.
> Let me know if this does not feel right.
Again, this needs to be very clearly documented, in the release notes
as as well as relevant Javadoc please.
> Luc
>
>>
>> Luc
>>
>>>
>>>>>
>>>>> Error Method 'protected org.apache.commons.math3.FieldElement[][]
>>>>> buildArray(org.apache.commons.math3.Field, int, int)' has been removed
>>>>>
>>>>> Error Method 'protected org.apache.commons.math3.FieldElement[]
>>>>> buildArray(org.apache.commons.math3.Field, int)' has been removed
>>>>> org.apache.commons.math3.linear.AbstractFieldMatrix
>>>>
>>>> I missed these ones. The methods have been moved to MathArrays. I'll fix
>>>> this by putting them back (deprecated) in AbstractFieldMatrix and set
>>>> them up in order to call the methods from MathArrays.
>>>>
>>>> best regards,
>>>> Luc
>>>>
>>>>>
>>>>> Thomas
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>
>>>>>
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [math] releasing 3.2?
Posted by Luc Maisonobe <Lu...@free.fr>.
Le 11/03/2013 08:51, Luc Maisonobe a écrit :
> Le 11/03/2013 00:47, sebb a écrit :
>> On 10 March 2013 16:35, Luc Maisonobe <Lu...@free.fr> wrote:
>>> Le 10/03/2013 15:28, Thomas Neidhart a écrit :
>>>> On 03/04/2013 01:24 PM, Luc Maisonobe wrote:
>>>>> Hi all,
>>>>>
>>>>> I would like to release version 3.2 of [math] soon.
>>>>> Any thoughts about it?
>>>>
>>>> There are 3 Clirr errors:
>>>>
>>>> Error Return type of method 'public int log10()' has been changed to
>>>> org.apache.commons.math3.dfp.Dfp
>>>
>>> I know about this one, it was introduced with r1449529. I have explained
>>> it here: <http://markmail.org/message/2ytqu4qmtkkp5v4z>.
>>>
>>> I would in fact consider this change is merely fixing a bug: the log10
>>> function returned an int when all other mathematical functions properly
>>> returned a Dfp. The change was two-fold: the log10 method returning an
>>> int was renamed intLog10, and a proper log10 method was added.
>>>
>>> I really don't think anybody will be affected by this change, as the
>>> class itself is probably very seldom used, and most importantly because
>>> despite this weird return type, nobody noticed it and complained about it.
>>>
>>> So I would consider this incompatible change should be accepted, even in
>>> a minor release.
>>>
>>
>> Sorry, I disagree.
>>
>> As far as I can tell, Math 3.1 only included
>>
>> public int log10()
>> public int log10K()
>
> Dfp also had sqrt, reciprocal, and nextAfter with Dfp return types (as
> well as a static copysign with a lower case s and two arguments, not the
> classical non-static with upper case S and one argument). The other
> functions like cos, sin etc also already existed but as static methods
> in DfpMath.
>
>>
>> so it's not entirely surprising that no-one complained about the return type.
>>
>> If it is still decided to ignore the incompatibilty, please document
>> this clearly in the release notes, and ensure log10K() Javadoc states
>> why it has a different return type from all the others.
>
> Yes, I'll do that.
Maybe I found a way to remove this incompatibility.
If we remove completely the declaration of log10(), which must return an
instance of T, in the parameterized interface RealFieldElement<T>, then
all implementations may have a different log10 method. This would allow
Dfp to keep its strange return type, at least for the 3.x series, while
DerivativeStructure and Decimal64 can return the proper type.
Then in 4.0, when we can add incompatible changes, we can add the
declaration back, change Dfp and have all implementations becoming
consistent with respect to this method return type.
For additional smooth transition for Dfp, we can already add the new
intLog10 method, and deprecate log10 declaring it will change its return
type as of 4.0.
The only drawback of this hack is that log10 would not be available in
parameterized classes, but only in classes where we already know what T
is, and for which we can directly point to the class implementation and
not the interface specification.
I'll commit this in a few minutes so the CLIRR report will be ... clear.
Let me know if this does not feel right.
Luc
>
> Luc
>
>>
>>>>
>>>> Error Method 'protected org.apache.commons.math3.FieldElement[][]
>>>> buildArray(org.apache.commons.math3.Field, int, int)' has been removed
>>>>
>>>> Error Method 'protected org.apache.commons.math3.FieldElement[]
>>>> buildArray(org.apache.commons.math3.Field, int)' has been removed
>>>> org.apache.commons.math3.linear.AbstractFieldMatrix
>>>
>>> I missed these ones. The methods have been moved to MathArrays. I'll fix
>>> this by putting them back (deprecated) in AbstractFieldMatrix and set
>>> them up in order to call the methods from MathArrays.
>>>
>>> best regards,
>>> Luc
>>>
>>>>
>>>> Thomas
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>
>>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [math] releasing 3.2?
Posted by Luc Maisonobe <Lu...@free.fr>.
Le 11/03/2013 00:47, sebb a écrit :
> On 10 March 2013 16:35, Luc Maisonobe <Lu...@free.fr> wrote:
>> Le 10/03/2013 15:28, Thomas Neidhart a écrit :
>>> On 03/04/2013 01:24 PM, Luc Maisonobe wrote:
>>>> Hi all,
>>>>
>>>> I would like to release version 3.2 of [math] soon.
>>>> Any thoughts about it?
>>>
>>> There are 3 Clirr errors:
>>>
>>> Error Return type of method 'public int log10()' has been changed to
>>> org.apache.commons.math3.dfp.Dfp
>>
>> I know about this one, it was introduced with r1449529. I have explained
>> it here: <http://markmail.org/message/2ytqu4qmtkkp5v4z>.
>>
>> I would in fact consider this change is merely fixing a bug: the log10
>> function returned an int when all other mathematical functions properly
>> returned a Dfp. The change was two-fold: the log10 method returning an
>> int was renamed intLog10, and a proper log10 method was added.
>>
>> I really don't think anybody will be affected by this change, as the
>> class itself is probably very seldom used, and most importantly because
>> despite this weird return type, nobody noticed it and complained about it.
>>
>> So I would consider this incompatible change should be accepted, even in
>> a minor release.
>>
>
> Sorry, I disagree.
>
> As far as I can tell, Math 3.1 only included
>
> public int log10()
> public int log10K()
Dfp also had sqrt, reciprocal, and nextAfter with Dfp return types (as
well as a static copysign with a lower case s and two arguments, not the
classical non-static with upper case S and one argument). The other
functions like cos, sin etc also already existed but as static methods
in DfpMath.
>
> so it's not entirely surprising that no-one complained about the return type.
>
> If it is still decided to ignore the incompatibilty, please document
> this clearly in the release notes, and ensure log10K() Javadoc states
> why it has a different return type from all the others.
Yes, I'll do that.
Luc
>
>>>
>>> Error Method 'protected org.apache.commons.math3.FieldElement[][]
>>> buildArray(org.apache.commons.math3.Field, int, int)' has been removed
>>>
>>> Error Method 'protected org.apache.commons.math3.FieldElement[]
>>> buildArray(org.apache.commons.math3.Field, int)' has been removed
>>> org.apache.commons.math3.linear.AbstractFieldMatrix
>>
>> I missed these ones. The methods have been moved to MathArrays. I'll fix
>> this by putting them back (deprecated) in AbstractFieldMatrix and set
>> them up in order to call the methods from MathArrays.
>>
>> best regards,
>> Luc
>>
>>>
>>> Thomas
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [math] releasing 3.2?
Posted by sebb <se...@gmail.com>.
On 10 March 2013 16:35, Luc Maisonobe <Lu...@free.fr> wrote:
> Le 10/03/2013 15:28, Thomas Neidhart a écrit :
>> On 03/04/2013 01:24 PM, Luc Maisonobe wrote:
>>> Hi all,
>>>
>>> I would like to release version 3.2 of [math] soon.
>>> Any thoughts about it?
>>
>> There are 3 Clirr errors:
>>
>> Error Return type of method 'public int log10()' has been changed to
>> org.apache.commons.math3.dfp.Dfp
>
> I know about this one, it was introduced with r1449529. I have explained
> it here: <http://markmail.org/message/2ytqu4qmtkkp5v4z>.
>
> I would in fact consider this change is merely fixing a bug: the log10
> function returned an int when all other mathematical functions properly
> returned a Dfp. The change was two-fold: the log10 method returning an
> int was renamed intLog10, and a proper log10 method was added.
>
> I really don't think anybody will be affected by this change, as the
> class itself is probably very seldom used, and most importantly because
> despite this weird return type, nobody noticed it and complained about it.
>
> So I would consider this incompatible change should be accepted, even in
> a minor release.
>
Sorry, I disagree.
As far as I can tell, Math 3.1 only included
public int log10()
public int log10K()
so it's not entirely surprising that no-one complained about the return type.
If it is still decided to ignore the incompatibilty, please document
this clearly in the release notes, and ensure log10K() Javadoc states
why it has a different return type from all the others.
>>
>> Error Method 'protected org.apache.commons.math3.FieldElement[][]
>> buildArray(org.apache.commons.math3.Field, int, int)' has been removed
>>
>> Error Method 'protected org.apache.commons.math3.FieldElement[]
>> buildArray(org.apache.commons.math3.Field, int)' has been removed
>> org.apache.commons.math3.linear.AbstractFieldMatrix
>
> I missed these ones. The methods have been moved to MathArrays. I'll fix
> this by putting them back (deprecated) in AbstractFieldMatrix and set
> them up in order to call the methods from MathArrays.
>
> best regards,
> Luc
>
>>
>> Thomas
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [math] releasing 3.2?
Posted by Luc Maisonobe <Lu...@free.fr>.
Hi Thomas,
Le 10/03/2013 17:44, Thomas Neidhart a écrit :
> On 03/10/2013 05:35 PM, Luc Maisonobe wrote:
>> Le 10/03/2013 15:28, Thomas Neidhart a écrit :
>>> On 03/04/2013 01:24 PM, Luc Maisonobe wrote:
>>>> Hi all,
>>>>
>>>> I would like to release version 3.2 of [math] soon.
>>>> Any thoughts about it?
>>>
>>> There are 3 Clirr errors:
>>>
>>> Error Return type of method 'public int log10()' has been changed to
>>> org.apache.commons.math3.dfp.Dfp
>>
>> I know about this one, it was introduced with r1449529. I have explained
>> it here: <http://markmail.org/message/2ytqu4qmtkkp5v4z>.
>>
>> I would in fact consider this change is merely fixing a bug: the log10
>> function returned an int when all other mathematical functions properly
>> returned a Dfp. The change was two-fold: the log10 method returning an
>> int was renamed intLog10, and a proper log10 method was added.
>>
>> I really don't think anybody will be affected by this change, as the
>> class itself is probably very seldom used, and most importantly because
>> despite this weird return type, nobody noticed it and complained about it.
>>
>> So I would consider this incompatible change should be accepted, even in
>> a minor release.
>
> Ok I understand, I just read the description for 3.2 in the
> changes-report and it states:
>
> This is a minor release: It combines bug fixes and new features. Changes
> to existing features were made in a backwards-compatible way such as to
> allow drop-in replacement of the v3.1[.1] JAR file.
>
> So I guess we will have to update this and mention it in the release-notes.
Yes, of course.
>
> btw. the Dfp.log10k also returns an int and not a Dfp as the other
> methods, is this intended?
Yes, this is due to the fact Dfp really uses base 10000 internally.
Luc
>
> Thomas
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [math] releasing 3.2?
Posted by Thomas Neidhart <th...@gmail.com>.
On 03/10/2013 05:35 PM, Luc Maisonobe wrote:
> Le 10/03/2013 15:28, Thomas Neidhart a écrit :
>> On 03/04/2013 01:24 PM, Luc Maisonobe wrote:
>>> Hi all,
>>>
>>> I would like to release version 3.2 of [math] soon.
>>> Any thoughts about it?
>>
>> There are 3 Clirr errors:
>>
>> Error Return type of method 'public int log10()' has been changed to
>> org.apache.commons.math3.dfp.Dfp
>
> I know about this one, it was introduced with r1449529. I have explained
> it here: <http://markmail.org/message/2ytqu4qmtkkp5v4z>.
>
> I would in fact consider this change is merely fixing a bug: the log10
> function returned an int when all other mathematical functions properly
> returned a Dfp. The change was two-fold: the log10 method returning an
> int was renamed intLog10, and a proper log10 method was added.
>
> I really don't think anybody will be affected by this change, as the
> class itself is probably very seldom used, and most importantly because
> despite this weird return type, nobody noticed it and complained about it.
>
> So I would consider this incompatible change should be accepted, even in
> a minor release.
Ok I understand, I just read the description for 3.2 in the
changes-report and it states:
This is a minor release: It combines bug fixes and new features. Changes
to existing features were made in a backwards-compatible way such as to
allow drop-in replacement of the v3.1[.1] JAR file.
So I guess we will have to update this and mention it in the release-notes.
btw. the Dfp.log10k also returns an int and not a Dfp as the other
methods, is this intended?
Thomas
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [math] releasing 3.2?
Posted by Luc Maisonobe <Lu...@free.fr>.
Le 10/03/2013 15:28, Thomas Neidhart a écrit :
> On 03/04/2013 01:24 PM, Luc Maisonobe wrote:
>> Hi all,
>>
>> I would like to release version 3.2 of [math] soon.
>> Any thoughts about it?
>
> There are 3 Clirr errors:
>
> Error Return type of method 'public int log10()' has been changed to
> org.apache.commons.math3.dfp.Dfp
I know about this one, it was introduced with r1449529. I have explained
it here: <http://markmail.org/message/2ytqu4qmtkkp5v4z>.
I would in fact consider this change is merely fixing a bug: the log10
function returned an int when all other mathematical functions properly
returned a Dfp. The change was two-fold: the log10 method returning an
int was renamed intLog10, and a proper log10 method was added.
I really don't think anybody will be affected by this change, as the
class itself is probably very seldom used, and most importantly because
despite this weird return type, nobody noticed it and complained about it.
So I would consider this incompatible change should be accepted, even in
a minor release.
>
> Error Method 'protected org.apache.commons.math3.FieldElement[][]
> buildArray(org.apache.commons.math3.Field, int, int)' has been removed
>
> Error Method 'protected org.apache.commons.math3.FieldElement[]
> buildArray(org.apache.commons.math3.Field, int)' has been removed
> org.apache.commons.math3.linear.AbstractFieldMatrix
I missed these ones. The methods have been moved to MathArrays. I'll fix
this by putting them back (deprecated) in AbstractFieldMatrix and set
them up in order to call the methods from MathArrays.
best regards,
Luc
>
> Thomas
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [math] releasing 3.2?
Posted by Gary Gregory <ga...@gmail.com>.
That means 4.0 and all that entails (Maven coords and package change) or
fix the Clirr errors.
Gary
On Sun, Mar 10, 2013 at 10:28 AM, Thomas Neidhart <thomas.neidhart@gmail.com
> wrote:
> On 03/04/2013 01:24 PM, Luc Maisonobe wrote:
> > Hi all,
> >
> > I would like to release version 3.2 of [math] soon.
> > Any thoughts about it?
>
> There are 3 Clirr errors:
>
> Error Return type of method 'public int log10()' has been changed to
> org.apache.commons.math3.dfp.Dfp
>
> Error Method 'protected org.apache.commons.math3.FieldElement[][]
> buildArray(org.apache.commons.math3.Field, int, int)' has been removed
>
> Error Method 'protected org.apache.commons.math3.FieldElement[]
> buildArray(org.apache.commons.math3.Field, int)' has been removed
> org.apache.commons.math3.linear.AbstractFieldMatrix
>
> Thomas
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
--
E-Mail: garydgregory@gmail.com | ggregory@apache.org
JUnit in Action, 2nd Ed: <http://goog_1249600977>http://bit.ly/ECvg0
Spring Batch in Action: <http://s.apache.org/HOq>http://bit.ly/bqpbCK
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory
Re: [math] releasing 3.2?
Posted by Thomas Neidhart <th...@gmail.com>.
On 03/04/2013 01:24 PM, Luc Maisonobe wrote:
> Hi all,
>
> I would like to release version 3.2 of [math] soon.
> Any thoughts about it?
There are 3 Clirr errors:
Error Return type of method 'public int log10()' has been changed to
org.apache.commons.math3.dfp.Dfp
Error Method 'protected org.apache.commons.math3.FieldElement[][]
buildArray(org.apache.commons.math3.Field, int, int)' has been removed
Error Method 'protected org.apache.commons.math3.FieldElement[]
buildArray(org.apache.commons.math3.Field, int)' has been removed
org.apache.commons.math3.linear.AbstractFieldMatrix
Thomas
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [math] releasing 3.2?
Posted by Phil Steitz <ph...@gmail.com>.
On 3/10/13 10:56 AM, Luc Maisonobe wrote:
> Hi Phil,
>
> Le 10/03/2013 18:28, Phil Steitz a écrit :
>> On 3/4/13 4:24 AM, Luc Maisonobe wrote:
>>> Hi all,
>>>
>>> I would like to release version 3.2 of [math] soon.
>>> Any thoughts about it?
>>>
>>> Luc
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>
>>>
>> I am sorry I have been very busy recently. I have a half-finished
>> comment on ExtendedFieldElement additions. The gist of it is do we
>> need all of the added stuff actually in the interface. At first, I
>> thought this was just adding exponential field and partial algebraic
>> closure, which makes "ExtendedFieldElement" an OK name. But all of
>> the added methods really make it more like "RealFieldElement" or
>> somesuch.
> I agree. We could rename it RealFieldElement if you prefer.
+1
>
>> The real question is do we really want to add all of the
>> methods in the interface. Since we are about to cut a release, we
>> should take a careful look at this. Sorry to take so long to review.
> Yes, I really need all this stuff. The fact is I use all trigonometric
> functions in FieldRotation (and to a lesser extend in FieldVector), plus
> a few others like sqrt and so on. Once I have all these functions, it
> seemed more consistent to also add the remaining ones (and in fact I
> will also need the hyperbolic functions later on).
>
> These methods are the ones that urge me to cut a release.
OK
Phil
>
> best regards,
> Luc
>
>> Phil
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [math] releasing 3.2?
Posted by Luc Maisonobe <Lu...@free.fr>.
Hi Phil,
Le 10/03/2013 18:28, Phil Steitz a écrit :
> On 3/4/13 4:24 AM, Luc Maisonobe wrote:
>> Hi all,
>>
>> I would like to release version 3.2 of [math] soon.
>> Any thoughts about it?
>>
>> Luc
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
> I am sorry I have been very busy recently. I have a half-finished
> comment on ExtendedFieldElement additions. The gist of it is do we
> need all of the added stuff actually in the interface. At first, I
> thought this was just adding exponential field and partial algebraic
> closure, which makes "ExtendedFieldElement" an OK name. But all of
> the added methods really make it more like "RealFieldElement" or
> somesuch.
I agree. We could rename it RealFieldElement if you prefer.
> The real question is do we really want to add all of the
> methods in the interface. Since we are about to cut a release, we
> should take a careful look at this. Sorry to take so long to review.
Yes, I really need all this stuff. The fact is I use all trigonometric
functions in FieldRotation (and to a lesser extend in FieldVector), plus
a few others like sqrt and so on. Once I have all these functions, it
seemed more consistent to also add the remaining ones (and in fact I
will also need the hyperbolic functions later on).
These methods are the ones that urge me to cut a release.
best regards,
Luc
>
> Phil
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [math] releasing 3.2?
Posted by Phil Steitz <ph...@gmail.com>.
On 3/4/13 4:24 AM, Luc Maisonobe wrote:
> Hi all,
>
> I would like to release version 3.2 of [math] soon.
> Any thoughts about it?
>
> Luc
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
I am sorry I have been very busy recently. I have a half-finished
comment on ExtendedFieldElement additions. The gist of it is do we
need all of the added stuff actually in the interface. At first, I
thought this was just adding exponential field and partial algebraic
closure, which makes "ExtendedFieldElement" an OK name. But all of
the added methods really make it more like "RealFieldElement" or
somesuch. The real question is do we really want to add all of the
methods in the interface. Since we are about to cut a release, we
should take a careful look at this. Sorry to take so long to review.
Phil
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [math] releasing 3.2?
Posted by Phil Steitz <ph...@gmail.com>.
On 3/10/13 12:20 PM, Luc Maisonobe wrote:
> Le 10/03/2013 19:47, Phil Steitz a écrit :
>> On 3/10/13 11:30 AM, Phil Steitz wrote:
>>> On 3/4/13 4:24 AM, Luc Maisonobe wrote:
>>>> Hi all,
>>>>
>>>> I would like to release version 3.2 of [math] soon.
>>>> Any thoughts about it?
>>>>
>>>> Luc
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>
>>>>
>>> Once again, sorry to be late on reviewing stuff. I think
>>> "DiscreteDistribution" added in MATH-942 is misnamed. It should be
>>> called "FiniteDistribution" as the standard definition (linked in
>>> the javadoc) applies to distributions such as Poisson and others
>>> (some of which we already have) that have infinitely many values.
>>> The javadoc should be clarified to indicate clearly what the class
>>> actually is. I am +1 for adding the class, as it is useful to be
>>> able to construct pmfs from parallel arrays; but the name should be
>>> changed. Also, I would drop "DiscreteEmpiricalDistribution" as it
>>> basically duplicates EmpiricalDistribution.
>> Sorry - the last sentence is not correct. What I should have said
>> is that EmpiricalDistribution should support this functionality. I
>> had actually started implementing this, but not proposed / committed
>> it yet. You can force this in EmpiricalDistribution now using
>> singleton bins, but it should be supported directly there.
>>
>>> I will make the
>>> necessary changes if others are OK with them.
> Sure. You are much more fluent with this stuff than me. I'll let you
> take care of this.
I am working on this. Hope to finish tonight or tomorrow. I am
also improving the javadoc, unit tests and exceptions. Finally, I
think the names should actually be "EnumeratedXxxDistribution" since
in fact we have other finite distributions and what is special about
these is that the pmf is enumerated.
One interesting thing about the implementations is that the
enumerations don't actually have to be functions - i.e. repeats are
allowed and in the case of EnumeratedDistribution, nulls can be
provided and are treated as equal. So for example, <"dog", 0.2>,
<"pig", 0.1>, <null, 0.1>, <"dog", 0.1>, <null, 0.5> provided to the
constructor results in a pmf that puts 0.1 on "pig", 0.3 on "dog"
and 0.6 on null. I have clarified the javadoc to make this
explicit. I think this is fine as long as it is documented.
Phil
>
> Luc
>
>> Including enhancement to EmpiricalDistribution, most likely > 3.2
>>> Phil
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [math] releasing 3.2?
Posted by Luc Maisonobe <Lu...@free.fr>.
Le 10/03/2013 19:47, Phil Steitz a écrit :
> On 3/10/13 11:30 AM, Phil Steitz wrote:
>> On 3/4/13 4:24 AM, Luc Maisonobe wrote:
>>> Hi all,
>>>
>>> I would like to release version 3.2 of [math] soon.
>>> Any thoughts about it?
>>>
>>> Luc
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>
>>>
>> Once again, sorry to be late on reviewing stuff. I think
>> "DiscreteDistribution" added in MATH-942 is misnamed. It should be
>> called "FiniteDistribution" as the standard definition (linked in
>> the javadoc) applies to distributions such as Poisson and others
>> (some of which we already have) that have infinitely many values.
>> The javadoc should be clarified to indicate clearly what the class
>> actually is. I am +1 for adding the class, as it is useful to be
>> able to construct pmfs from parallel arrays; but the name should be
>> changed. Also, I would drop "DiscreteEmpiricalDistribution" as it
>> basically duplicates EmpiricalDistribution.
>
> Sorry - the last sentence is not correct. What I should have said
> is that EmpiricalDistribution should support this functionality. I
> had actually started implementing this, but not proposed / committed
> it yet. You can force this in EmpiricalDistribution now using
> singleton bins, but it should be supported directly there.
>
>> I will make the
>> necessary changes if others are OK with them.
Sure. You are much more fluent with this stuff than me. I'll let you
take care of this.
Luc
>
> Including enhancement to EmpiricalDistribution, most likely > 3.2
>>
>> Phil
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [math] releasing 3.2?
Posted by Phil Steitz <ph...@gmail.com>.
On 3/10/13 11:30 AM, Phil Steitz wrote:
> On 3/4/13 4:24 AM, Luc Maisonobe wrote:
>> Hi all,
>>
>> I would like to release version 3.2 of [math] soon.
>> Any thoughts about it?
>>
>> Luc
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
> Once again, sorry to be late on reviewing stuff. I think
> "DiscreteDistribution" added in MATH-942 is misnamed. It should be
> called "FiniteDistribution" as the standard definition (linked in
> the javadoc) applies to distributions such as Poisson and others
> (some of which we already have) that have infinitely many values.
> The javadoc should be clarified to indicate clearly what the class
> actually is. I am +1 for adding the class, as it is useful to be
> able to construct pmfs from parallel arrays; but the name should be
> changed. Also, I would drop "DiscreteEmpiricalDistribution" as it
> basically duplicates EmpiricalDistribution.
Sorry - the last sentence is not correct. What I should have said
is that EmpiricalDistribution should support this functionality. I
had actually started implementing this, but not proposed / committed
it yet. You can force this in EmpiricalDistribution now using
singleton bins, but it should be supported directly there.
> I will make the
> necessary changes if others are OK with them.
Including enhancement to EmpiricalDistribution, most likely > 3.2
>
> Phil
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [math] releasing 3.2?
Posted by Phil Steitz <ph...@gmail.com>.
On 3/4/13 4:24 AM, Luc Maisonobe wrote:
> Hi all,
>
> I would like to release version 3.2 of [math] soon.
> Any thoughts about it?
>
> Luc
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
Once again, sorry to be late on reviewing stuff. I think
"DiscreteDistribution" added in MATH-942 is misnamed. It should be
called "FiniteDistribution" as the standard definition (linked in
the javadoc) applies to distributions such as Poisson and others
(some of which we already have) that have infinitely many values.
The javadoc should be clarified to indicate clearly what the class
actually is. I am +1 for adding the class, as it is useful to be
able to construct pmfs from parallel arrays; but the name should be
changed. Also, I would drop "DiscreteEmpiricalDistribution" as it
basically duplicates EmpiricalDistribution. I will make the
necessary changes if others are OK with them.
Phil
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org