commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bill Barker" <billwbar...@verizon.net>
Subject Re: clirr for MATH-389
Date Sat, 24 Jul 2010 02:41:50 GMT


--------------------------------------------------
From: "Phil Steitz" <phil.steitz@gmail.com>
Sent: Friday, July 23, 2010 5:42 PM
To: "Commons Developers List" <dev@commons.apache.org>
Subject: Re: clirr for MATH-389

> Gilles Sadowski wrote:
>>>>>> Intentional but still a mistake IMO ;-) as it's part of the interface
>>>>>> whereas the prime use is to allow to define a default constructor
so 
>>>>>> that
>>>>>> the user does *not* have to refer to the value.
>>>>>> When using the default constructor, the user can always obtain the

>>>>>> default
>>>>>> value with "getMaxIterations()".
>>>>> No, the user can get this value only once the instance has already 
>>>>> been
>>>>> built, not before calling the constructor.
>>>> Of course. I didn't say otherwise.
>>>> When does the user need to know this value before calling the 
>>>> constructor?
>>> Mainly displaying it in a graphical user interface, as an hint for the
>>> user to choose either this default or something else if he want to.
>>
>> Unless I'm mistaken, the meaning of "iteration" is algorithm-dependent, 
>> and
>> the "maximum" will depend on the problem and the requested accuracy, so 
>> how
>> could CM know what is a "good" default? As far as I can tell, the value
>> (100) was picked out of thin air. For the number of evaluations, the 
>> default
>> is MAX_VALUE (which makes more sense, in some sense ;-); and note that 
>> this
>> one is not defined as a public static variable!
>>
>> Certainly, the (graphical interface) program has more information (which
>> problem it is solving and which optimization algorithm it is going to 
>> call
>> to do so) to make the right default choice.
>>
>> In summary, this variable pollutes the CM API for no reason.
>>
>>>> How useful is a default value anyway?
>>>>
>>>>>>>> Last 3 items: The field still exists but in a superclass.
The 
>>>>>>>> problem would
>>>>>>>> have been prevented if those fields were "private" instead
of 
>>>>>>>> "protected".
>>>>>> I suggest that access to those fields is also changed to "private"

>>>>>> (this
>>>>>> breaks compatibility just the same) and I'll add accessors to be
used 
>>>>>> by
>>>>>> derived classes for accessing them. OK?
>>>>> I'm on the fence on this.
>>>> What can you do with a "protected" field that you can't with the object
>>>> returned by an accessor?
>>>> [I even think that we should go towards immutability for those 
>>>> fields...]
>>> Yes, of course, but when I say I'm on the fence it is rather because it
>>> introduces another incompatibility. How about deprecating them for now
>>> and changing them to private (and perhaps final) in 3.0 ?
>>
>> I've deprecated them.
>>
>>>>>>>> So, what does that mean with respect to committing the changes
into 
>>>>>>>> the
>>>>>>>> trunk?
>>>>>>> There does not seem to be any major problem, so you can commit
your 
>>>>>>> changes.
>>>>>> Wow, that's unexpected good news. It's a relief that backward 
>>>>>> compatibility
>>>>>> isn't that stringent a requirement :-)
>>>>> It is a stringent requirement. But it seemed to me that the changes 
>>>>> were
>>>>> not that important.
>>>> Fine then. I don't think they are but...
>>>>
>>>>> Did I miss something ?
>>>> ... How would I know? Is there a policy that "clirr" cannot report 
>>>> "ERROR"?
>>>> If not, then how do you decide what is important and what isn't?
>>> It is a matter of feeling and experience. It is highly subjective and
>>> this discussion is a perfect example of this. We can see you are ready
>>> to change almost anything anytime, Phil doesn't want some changes to be
>>> introduced at dot releases, and I am somewhere in between.
>>>
>>> We are a community, and it is important we exchange our views here.
>>
>> I've already suggested that we should try and assess the real impact of
>> the changes so that we can compare the drawbacks of each approach. I.e. 
>> how
>> many people/projects are out there that would really be annoyed by a
>> recompilation at each dot release.
>
> We should adhere to Commons standards. The standards are clear:
> http://commons.apache.org/releases/versioning.html
>
> Clirr ERRORs generally call out standards exceptions for a .x release.
>
> I have no problem using natural numbers more quickly. We have
> plenty! Why not just start working 3.0 in trunk.  We can create a
> 2.x branch so we can cut a 2.2 if some really bad bugs show up
> before we get 3.0 out.
>
> We all agree that the [math] API needs work. If we cut more frequent
> major releases, we can evolve the API.  Lets do that.
>

+1 on creating a 2.2 branch and concentrating [math] on 3.0.

>
> Phil
>
>
>>>> [...]
>>>>
>>>> Maybe that the "MATH_2_0" branch contains outdated things...
>>>> Does it work on your machine?
>>> I didn't try. However, I'm not sure clirr is useful on a major release
>>> as it is at these releases that we allow ourselves to introduce great
>>> changes.
>>
>> But I was interested in seeing if similarly incompatible changes were
>> introduced in 2.1 (hence I need to "mvn install" 2.0).
>>
>>
>> Gilles
>>
>> ---------------------------------------------------------------------
>> 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