commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Phil Steitz <>
Subject Re: clirr for MATH-389
Date Sat, 24 Jul 2010 00:42:48 GMT
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
>>>>> 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
>>>>> 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
>>>>> 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
>>>>> 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:

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.


>>> [...]
>>> 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:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message