This should be the only outstanding error. I have attached updated patches for the MillerRegression and RegressionResults.
On Wed, Jul 20, 2011 at 2:02 PM, Luc Maisonobe <[email protected]>wrote: > Le 20/07/2011 20:45, Greg Sterijevski a écrit : > > 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? >> > > We already have this kind of behaviour. > If a reference is really what we want (and it seems to be the case here), > then we: > 1) document it in the javadoc with something along the line of: > "a referenced to the array is stored in the instance, so changes > in the array <em>will</em> change the instance" > 2) we had an exclusion rule for findbugs for the specific method of > the specific class in the findbugs-exclude-filter.xml file > > You can find similar examples for the methods in othe vector and matrices > in the linear algebra package. > > Luc > > > >> Thanks, >> >> -Greg >> >> On Wed, Jul 20, 2011 at 1:14 PM, Phil Steitz<[email protected]> >> 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 >>>> <[email protected]>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<[email protected] >>>>> >>>> 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<[email protected]> >>>>>> > >>>>>> >>>>> 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<[email protected]> >>>>>>> For additional commands, e-mail: [email protected] >>>>>>> >>>>>>> ------------------------------**------------------------------** >>>>>> --------- >>>>>> To unsubscribe, e-mail: >>>>>> dev-unsubscribe@commons.**apache.org<[email protected]> >>>>>> For additional commands, e-mail: [email protected] >>>>>> >>>>>> >>>>>> >>> >>> ------------------------------**------------------------------** >>> --------- >>> To unsubscribe, e-mail: >>> dev-unsubscribe@commons.**apache.org<[email protected]> >>> For additional commands, e-mail: [email protected] >>> >>> >>> >> > > ------------------------------**------------------------------**--------- > To unsubscribe, e-mail: > dev-unsubscribe@commons.**apache.org<[email protected]> > For additional commands, e-mail: [email protected] > >
