Mailing-List: contact dev-help@commons.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Commons Developers List" <dev@commons.apache.org>
Received-SPF: pass (athena.apache.org: domain of gsterijevski@gmail.com
 designates 209.85.220.171 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <4E271B13.1000509@gmail.com>
References: <4E26C41C.30104@free.fr>
	<3A5A4B8C-CBBC-46B0-A298-081161EE7FA5@gmail.com>
	<CACMPRi07zd9w_Tz15Cei5xVCoRjCvc9bX9+s_Xedj8ZS953uaA@mail.gmail.com>
	<CACMPRi0kiwmEtrfCcbiAe9k3xvwPw4jjYdd9dOs0HN6bNy6T6g@mail.gmail.com>
	<4E271B13.1000509@gmail.com>
Date: Wed, 20 Jul 2011 13:45:49 -0500
Message-ID: 
 <CACMPRi23o1++LgE7H9azCgP5vnBRCbRgfZCxbOJ9EuUyPWp08g@mail.gmail.com>
Subject: Re: [math] many warnings RegressionResults and
 MillerUpdatingRegression
From: Greg Sterijevski <gsterijevski@gmail.com>
To: Commons Developers List <dev@commons.apache.org>
Content-Type: multipart/alternative; boundary=bcaec501604323bcd904a884a4ea

--bcaec501604323bcd904a884a4ea
Content-Type: text/plain; charset=ISO-8859-1

The errors concern the copy of the reference I am making. In the constructor
of the RegressionResults object there is the boolean flag "copyData".This
governs whether the user wants to store a copy of the data or just a copy of
the references. What I had hoped to do is avoid copying potentially large
arrays. In most cases, the user should never be between the regression
internals and the RegressionResults object.

That being said, I recognize that a user might want to instantiate
RegressionResults with data from somewhere else (eg not from a regression
source). Then the error report is absolutely correct. The mutable array
could have its values changed...

I am reticent about calling clone because, with primitive arrays, it is a
copy. We could just make the behavior of the constructor to always copy the
data. That would mean changing the signature of the method (copyData would
be dropped). Can anyone think of better way to do this?

Thanks,

-Greg

On Wed, Jul 20, 2011 at 1:14 PM, Phil Steitz <phil.steitz@gmail.com> wrote:

> On 7/20/11 9:56 AM, Greg Sterijevski wrote:
> > Having discovered the check-results.xml file, I will work through them
> > all... (the ones I contributed). -Greg
>
> Thanks, Greg!
>
> The easiest way to check everything is to run "mvn site" from the
> root of the full checkout and then look at the reports in the
> locally generated website.  The reports (both checkstyle and
> findbugs) are under "project reports".
>
> Phil
> >
> > On Wed, Jul 20, 2011 at 10:27 AM, Greg Sterijevski
> > <gsterijevski@gmail.com>wrote:
> >
> >> Yes, sorry about the mess I created. I will go back and add the javadoc.
> >>
> >> -Greg
> >>
> >>
> >> On Wed, Jul 20, 2011 at 8:58 AM, Phil Steitz <phil.steitz@gmail.com
> >wrote:
> >>
> >>> Ack.  All of the warnings are either missing javadoc or exception
> string
> >>> warnings.  I was holding off fixing the latter until we had a couple of
> >>> impls to compare so we could see the full range of errors we were
> likely to
> >>> see.  I can probably do that now, though.  Will add to the thread on
> >>> regression API refactoring and get something at least functional into
> the
> >>> code.  As for the javadoc, thanks for volunteering, Greg :)
> >>>
> >>>
> >>>
> >>> On Jul 20, 2011, at 5:03 AM, Luc Maisonobe <Luc.Maisonobe@free.fr>
> wrote:
> >>>
> >>>> Hello all,
> >>>>
> >>>> Is seems there are many checkstyle and findbugs warnings in the
> >>> RegressionResults and MillerUpdatingRegression classes. They are mainly
> >>> missing javadoc, but also hard-coded exception messages and storing
> array
> >>> references in classes.
> >>>> Greg, I think you provided the patch, could you have a look at this ?
> >>>>
> >>>> Luc
> >>>>
> >>>> ---------------------------------------------------------------------
> >>>> 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
>
>

--bcaec501604323bcd904a884a4ea--