commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Luc Maisonobe <Luc.Maison...@free.fr>
Subject Re: [math] many warnings RegressionResults and MillerUpdatingRegression
Date Wed, 20 Jul 2011 19:02:01 GMT
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<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
>>
>>
>


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


Mime
View raw message