----- "Phil Steitz" <phil.ste...@gmail.com> a écrit : > Luc Maisonobe wrote: > > Le 24/07/2010 04:41, Bill Barker a écrit : > >> > >> -------------------------------------------------- > >> From: "Phil Steitz" <phil.ste...@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. > > > > I would really much like to have a new version out this year, I > need > > some changes for Orekit, and especially a new implementation of ODE > with > > Jacobians (see discussion in MATH-380). > > > > So if going to 3.0 delays a new version, I would be against it. > > I understand. Can you have a look at the issues marked 2.1 and see > if in your opinion any can be moved to 3.0? Then we can cut a 2.2 > branch in which we unwind any incompatible changes from trunk and > then allow ourselves more flexibility to fix API problems in trunk > for 3.0. The downside of this approach is that we will have to > apply patches to both branches for a while. I am OK with this and > will help with the backporting and getting 2.2 out if others are > amenable. Does this sound OK?
It seems good to me. I have changed target fix version for several JIRA issues, postponing some to 3.0 and setting a few ones to 2.2 (mainly the ones I need ...). There are 4 unscheduled issues. I guess MATH-353 should be postponed to 3.0 (or added to wishlist). O don't know the status of MATH-370 yet (it may even be complete). MATH-361 should probably be closed and specific issues opened for some exceptions. MATH-394 should probably be fixed (by Gilles ?) for 2.2. Luc > > Phil > > > > > Luc > > > >>> 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-unsubscr...@commons.apache.org > >>>> For additional commands, e-mail: dev-h...@commons.apache.org > >>>> > >>> > >>> > --------------------------------------------------------------------- > >>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > >>> For additional commands, e-mail: dev-h...@commons.apache.org > >>> > >> > --------------------------------------------------------------------- > >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > >> For additional commands, e-mail: dev-h...@commons.apache.org > >> > >> > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > For additional commands, e-mail: dev-h...@commons.apache.org > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
