You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Ted Dunning <te...@gmail.com> on 2010/06/10 06:29:01 UTC
Re: [math] StatUtils handling of zero length arrays - MATH-373
I would count this as a bug fix rather than a compatibility break. (my vote
is non-binding, of course)
On Wed, Jun 9, 2010 at 7:08 PM, Bill Barker <bi...@verizon.net> wrote:
> Currently StatUtils.sum(double []) (as well as most other statistics that
> operate on arrays) returns NaN on a zero length array. As pointed out in
> the Jira issue, this is not the conventional treatment of a summation over
> the empty set (which would return zero) in the mathematical world. I would
> definitely want to change this in 3.0. But I'm on the fence for how much of
> an incompatible change this would be for 2.2.
>
> The change is simple, and I'm volunteering to do the work. I just wanted
> to ping the list for opinions on how much breakage we can allow in 2.2.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
Re: [math] StatUtils handling of zero length arrays - MATH-373
Posted by sebb <se...@gmail.com>.
On 10/06/2010, Ted Dunning <te...@gmail.com> wrote:
> I would count this as a bug fix rather than a compatibility break. (my vote
> is non-binding, of course)
>
I agree that the current behaviour is wrong.
Unfortunately, the current behaviour is documented in the Javadoc, so
it would be a compatibility break.
> On Wed, Jun 9, 2010 at 7:08 PM, Bill Barker <bi...@verizon.net> wrote:
>
> > Currently StatUtils.sum(double []) (as well as most other statistics that
> > operate on arrays) returns NaN on a zero length array. As pointed out in
> > the Jira issue, this is not the conventional treatment of a summation over
> > the empty set (which would return zero) in the mathematical world. I would
> > definitely want to change this in 3.0. But I'm on the fence for how much of
> > an incompatible change this would be for 2.2.
> >
> > The change is simple, and I'm volunteering to do the work. I just wanted
> > to ping the list for opinions on how much breakage we can allow in 2.2.
> >
> > ---------------------------------------------------------------------
> > 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