commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Sterijevski <gsterijev...@gmail.com>
Subject Re: [math] many warnings RegressionResults and MillerUpdatingRegression
Date Thu, 21 Jul 2011 01:58:09 GMT
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 <Luc.Maisonobe@free.fr>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<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<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<dev-unsubscribe@commons.apache.org>
>>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>>>
>>>>>>>  ------------------------------**------------------------------**
>>>>>> ---------
>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.**apache.org<dev-unsubscribe@commons.apache.org>
>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>>
>>>>>>
>>>>>>
>>>
>>> ------------------------------**------------------------------**
>>> ---------
>>> To unsubscribe, e-mail: dev-unsubscribe@commons.**apache.org<dev-unsubscribe@commons.apache.org>
>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>
>>>
>>>
>>
>
> ------------------------------**------------------------------**---------
> To unsubscribe, e-mail: dev-unsubscribe@commons.**apache.org<dev-unsubscribe@commons.apache.org>
> For additional commands, e-mail: dev-help@commons.apache.org
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message