commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From luc.maison...@free.fr
Subject Re: [math] starting work on 3.0 (was Re: clirr for MATH-389)
Date Mon, 26 Jul 2010 12:16:15 GMT

----- "Phil Steitz" <phil.steitz@gmail.com> a écrit :

> Luc Maisonobe wrote:
> > Le 24/07/2010 04:41, Bill Barker a écrit :
> >>
> >> --------------------------------------------------
> >> 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.
> > 
> > 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-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
> > 
> 
> 
> ---------------------------------------------------------------------
> 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