You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@commons.apache.org by "Gilles (JIRA)" <ji...@apache.org> on 2010/07/20 11:15:49 UTC
[jira] Created: (MATH-389) New superclass for
"AbstractScalarDifferentiableOptimizer"
New superclass for "AbstractScalarDifferentiableOptimizer"
----------------------------------------------------------
Key: MATH-389
URL: https://issues.apache.org/jira/browse/MATH-389
Project: Commons Math
Issue Type: Improvement
Reporter: Gilles
Assignee: Gilles
Priority: Trivial
Fix For: 2.2
In package {{optimization.general}}, I propose to create a new class: "AbstractScalarOptimizer". It would contain all code currently in "AbstractScalarDifferentiableOptimizer" that is not related to derivatives. "AbstractScalarDifferentiableOptimizer" would then extend that class to add the derivative-related code.
This new layer in the hierarchy will be the base class for algorithms that do not use derivatives.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: [math] starting work on 3.0
Posted by Gilles Sadowski <gi...@harfang.homelinux.org>.
> >> 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.
+1 for a version 3.0 this year!
Gilles
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [math] starting work on 3.0 (was Re: clirr for MATH-389)
Posted by Phil Steitz <ph...@gmail.com>.
Luc Maisonobe wrote:
> Le 24/07/2010 04:41, Bill Barker a écrit :
>>
>> --------------------------------------------------
>> From: "Phil Steitz" <ph...@gmail.com>
>> Sent: Friday, July 23, 2010 5:42 PM
>> To: "Commons Developers List" <de...@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?
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
[math] starting work on 3.0 (was Re: clirr for MATH-389)
Posted by Luc Maisonobe <Lu...@free.fr>.
Le 24/07/2010 04:41, Bill Barker a écrit :
>
>
> --------------------------------------------------
> From: "Phil Steitz" <ph...@gmail.com>
> Sent: Friday, July 23, 2010 5:42 PM
> To: "Commons Developers List" <de...@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.
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
Re: clirr for MATH-389
Posted by Bill Barker <bi...@verizon.net>.
--------------------------------------------------
From: "Phil Steitz" <ph...@gmail.com>
Sent: Friday, July 23, 2010 5:42 PM
To: "Commons Developers List" <de...@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
Re: clirr for MATH-389
Posted by Phil Steitz <ph...@gmail.com>.
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.
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
Re: clirr for MATH-389
Posted by Gilles Sadowski <gi...@harfang.homelinux.org>.
> >>> 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.
> > [...]
> >
> > 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
Re: clirr for MATH-389
Posted by Luc Maisonobe <Lu...@free.fr>.
Le 22/07/2010 23:35, Gilles Sadowski a écrit :
>>>> No, it was intentional so users can explicitly refer to it when building
>>>> the instance.
>>>
>>> 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.
> 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 ?
>
>>>>> 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 tried to see whether similar changes where present between 2.0 an 2.1 but
>>>>> "mvn install" doesn't work on the source tree located at:
>>>>> http://svn.apache.org/repos/asf/commons/proper/math/tags/MATH_2_0
>>>>> [I've attached the console output.]
>>>>
>>>> It seems you have some network outage now, because the file is really
>>>> there and accessible. Try it several times or check your proxy setting.
>>>
>>> There is no proxy. I run the same command ("mvn install") inside three
>>> directories:
>>> MATH_2_0
>>> MATH_2_1
>>> trunk
>>> In the first it fails, in the last two it works.
>>
>> I don't understand what happens.
>
>
> 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.
Luc
>
> 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
Re: clirr for MATH-389
Posted by Gilles Sadowski <gi...@harfang.homelinux.org>.
> >> No, it was intentional so users can explicitly refer to it when building
> >> the instance.
> >
> > 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?
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...]
> >>> 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?
> >>> I tried to see whether similar changes where present between 2.0 an 2.1 but
> >>> "mvn install" doesn't work on the source tree located at:
> >>> http://svn.apache.org/repos/asf/commons/proper/math/tags/MATH_2_0
> >>> [I've attached the console output.]
> >>
> >> It seems you have some network outage now, because the file is really
> >> there and accessible. Try it several times or check your proxy setting.
> >
> > There is no proxy. I run the same command ("mvn install") inside three
> > directories:
> > MATH_2_0
> > MATH_2_1
> > trunk
> > In the first it fails, in the last two it works.
>
> I don't understand what happens.
Maybe that the "MATH_2_0" branch contains outdated things...
Does it work on your machine?
Gilles
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: clirr for MATH-389
Posted by Luc Maisonobe <Lu...@free.fr>.
Le 22/07/2010 17:08, Gilles Sadowski a écrit :
>>> Concerning the items related to this issue:
>>>
>>> 3rd item: The method is declared in a superclass.
>>> 4th item: The constant is defined in a superclass. It is still "public" but
>>> I think that it's a mistake and should be made "private" instead.
>>
>> No, it was intentional so users can explicitly refer to it when building
>> the instance.
>
> 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.
> So, OK to change to "private"?
No, at least from my point of view.
>
>>> 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.
>
>>> 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. Did I miss something ?
>
>>> I tried to see whether similar changes where present between 2.0 an 2.1 but
>>> "mvn install" doesn't work on the source tree located at:
>>> http://svn.apache.org/repos/asf/commons/proper/math/tags/MATH_2_0
>>> [I've attached the console output.]
>>
>> It seems you have some network outage now, because the file is really
>> there and accessible. Try it several times or check your proxy setting.
>
> There is no proxy. I run the same command ("mvn install") inside three
> directories:
> MATH_2_0
> MATH_2_1
> trunk
> In the first it fails, in the last two it works.
I don't understand what happens.
Luc
>
>
> 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
Re: clirr for MATH-389
Posted by Gilles Sadowski <gi...@harfang.homelinux.org>.
> > Concerning the items related to this issue:
> >
> > 3rd item: The method is declared in a superclass.
> > 4th item: The constant is defined in a superclass. It is still "public" but
> > I think that it's a mistake and should be made "private" instead.
>
> No, it was intentional so users can explicitly refer to it when building
> the instance.
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()".
So, OK to change to "private"?
> > 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?
> > 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 :-)
> > I tried to see whether similar changes where present between 2.0 an 2.1 but
> > "mvn install" doesn't work on the source tree located at:
> > http://svn.apache.org/repos/asf/commons/proper/math/tags/MATH_2_0
> > [I've attached the console output.]
>
> It seems you have some network outage now, because the file is really
> there and accessible. Try it several times or check your proxy setting.
There is no proxy. I run the same command ("mvn install") inside three
directories:
MATH_2_0
MATH_2_1
trunk
In the first it fails, in the last two it works.
Gilles
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: clirr for MATH-389
Posted by sebb <se...@gmail.com>.
On 22 July 2010 13:11, Luc Maisonobe <Lu...@free.fr> wrote:
> Le 22/07/2010 12:46, Gilles Sadowski a écrit :
>> Hi.
>>
>>> Luc Maisonobe commented on MATH-389:
>>> ------------------------------------
>>>
>>> At first sight, it seems good to me.
>>> You can check there are incomatibilities by performing the changes locally and run "clirr" (for example by running "mvn site") and check the clirr report.
>>
>> Here is the report on stdout:
>> ---CUT---
>> [INFO] Comparing to version: 2.1
>> [ERROR] org.apache.commons.math.MessagesResources_fr: Class org.apache.commons.math.MessagesResources_fr removed
>> [ERROR] org.apache.commons.math.analysis.interpolation.SmoothingBicubicSplineInterpolator: Return type of method 'public org.apache.commons.math.analysis.BivariateRealFunction interpolate(double[], double[], double[][])' has been changed to org.apache.commons.math.analysis.interpolation.BicubicSplineInterpolatingFunction
>> [ERROR] org.apache.commons.math.optimization.DifferentiableMultivariateRealOptimizer: Method 'public org.apache.commons.math.optimization.RealPointValuePair optimize(org.apache.commons.math.analysis.DifferentiableMultivariateRealFunction, org.apache.commons.math.optimization.GoalType, double[])' has been removed
>> [ERROR] org.apache.commons.math.optimization.general.AbstractScalarDifferentiableOptimizer: Field DEFAULT_MAX_ITERATIONS has been removed, but it was previously a constant
>> [ERROR] org.apache.commons.math.optimization.general.AbstractScalarDifferentiableOptimizer: Removed field checker
>> [ERROR] org.apache.commons.math.optimization.general.AbstractScalarDifferentiableOptimizer: Removed field goal
>> [ERROR] org.apache.commons.math.optimization.general.AbstractScalarDifferentiableOptimizer: Removed field point
>> ---CUT---
>>
>> Concerning the items related to this issue:
>>
>> 3rd item: The method is declared in a superclass.
>> 4th item: The constant is defined in a superclass. It is still "public" but
>> I think that it's a mistake and should be made "private" instead.
>
> No, it was intentional so users can explicitly refer to it when building
> the instance.
>
>> 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".
>>
>> 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.
>
>
>>
>> I tried to see whether similar changes where present between 2.0 an 2.1 but
>> "mvn install" doesn't work on the source tree located at:
>> http://svn.apache.org/repos/asf/commons/proper/math/tags/MATH_2_0
>> [I've attached the console output.]
>
> It seems you have some network outage now, because the file is really
> there and accessible. Try it several times or check your proxy setting.
And make sure you are using a recent version of Maven, e.g. 2.2.1.
I've seen problems with 2.1.0 not being allowed to download files.
> Luc
>
>>
>>
>> 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
Re: clirr for MATH-389
Posted by Luc Maisonobe <Lu...@free.fr>.
Le 22/07/2010 12:46, Gilles Sadowski a écrit :
> Hi.
>
>> Luc Maisonobe commented on MATH-389:
>> ------------------------------------
>>
>> At first sight, it seems good to me.
>> You can check there are incomatibilities by performing the changes locally and run "clirr" (for example by running "mvn site") and check the clirr report.
>
> Here is the report on stdout:
> ---CUT---
> [INFO] Comparing to version: 2.1
> [ERROR] org.apache.commons.math.MessagesResources_fr: Class org.apache.commons.math.MessagesResources_fr removed
> [ERROR] org.apache.commons.math.analysis.interpolation.SmoothingBicubicSplineInterpolator: Return type of method 'public org.apache.commons.math.analysis.BivariateRealFunction interpolate(double[], double[], double[][])' has been changed to org.apache.commons.math.analysis.interpolation.BicubicSplineInterpolatingFunction
> [ERROR] org.apache.commons.math.optimization.DifferentiableMultivariateRealOptimizer: Method 'public org.apache.commons.math.optimization.RealPointValuePair optimize(org.apache.commons.math.analysis.DifferentiableMultivariateRealFunction, org.apache.commons.math.optimization.GoalType, double[])' has been removed
> [ERROR] org.apache.commons.math.optimization.general.AbstractScalarDifferentiableOptimizer: Field DEFAULT_MAX_ITERATIONS has been removed, but it was previously a constant
> [ERROR] org.apache.commons.math.optimization.general.AbstractScalarDifferentiableOptimizer: Removed field checker
> [ERROR] org.apache.commons.math.optimization.general.AbstractScalarDifferentiableOptimizer: Removed field goal
> [ERROR] org.apache.commons.math.optimization.general.AbstractScalarDifferentiableOptimizer: Removed field point
> ---CUT---
>
> Concerning the items related to this issue:
>
> 3rd item: The method is declared in a superclass.
> 4th item: The constant is defined in a superclass. It is still "public" but
> I think that it's a mistake and should be made "private" instead.
No, it was intentional so users can explicitly refer to it when building
the instance.
> 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".
>
> 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.
>
> I tried to see whether similar changes where present between 2.0 an 2.1 but
> "mvn install" doesn't work on the source tree located at:
> http://svn.apache.org/repos/asf/commons/proper/math/tags/MATH_2_0
> [I've attached the console output.]
It seems you have some network outage now, because the file is really
there and accessible. Try it several times or check your proxy setting.
Luc
>
>
> 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
clirr for MATH-389
Posted by Gilles Sadowski <gi...@harfang.homelinux.org>.
Hi.
> Luc Maisonobe commented on MATH-389:
> ------------------------------------
>
> At first sight, it seems good to me.
> You can check there are incomatibilities by performing the changes locally and run "clirr" (for example by running "mvn site") and check the clirr report.
Here is the report on stdout:
---CUT---
[INFO] Comparing to version: 2.1
[ERROR] org.apache.commons.math.MessagesResources_fr: Class org.apache.commons.math.MessagesResources_fr removed
[ERROR] org.apache.commons.math.analysis.interpolation.SmoothingBicubicSplineInterpolator: Return type of method 'public org.apache.commons.math.analysis.BivariateRealFunction interpolate(double[], double[], double[][])' has been changed to org.apache.commons.math.analysis.interpolation.BicubicSplineInterpolatingFunction
[ERROR] org.apache.commons.math.optimization.DifferentiableMultivariateRealOptimizer: Method 'public org.apache.commons.math.optimization.RealPointValuePair optimize(org.apache.commons.math.analysis.DifferentiableMultivariateRealFunction, org.apache.commons.math.optimization.GoalType, double[])' has been removed
[ERROR] org.apache.commons.math.optimization.general.AbstractScalarDifferentiableOptimizer: Field DEFAULT_MAX_ITERATIONS has been removed, but it was previously a constant
[ERROR] org.apache.commons.math.optimization.general.AbstractScalarDifferentiableOptimizer: Removed field checker
[ERROR] org.apache.commons.math.optimization.general.AbstractScalarDifferentiableOptimizer: Removed field goal
[ERROR] org.apache.commons.math.optimization.general.AbstractScalarDifferentiableOptimizer: Removed field point
---CUT---
Concerning the items related to this issue:
3rd item: The method is declared in a superclass.
4th item: The constant is defined in a superclass. It is still "public" but
I think that it's a mistake and should be made "private" instead.
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".
So, what does that mean with respect to committing the changes into the
trunk?
I tried to see whether similar changes where present between 2.0 an 2.1 but
"mvn install" doesn't work on the source tree located at:
http://svn.apache.org/repos/asf/commons/proper/math/tags/MATH_2_0
[I've attached the console output.]
Gilles
Re: [jira] Commented: (MATH-389) New superclass for
"AbstractScalarDifferentiableOptimizer"
Posted by Gilles Sadowski <gi...@harfang.homelinux.org>.
> > $ svn co http://svn.apache.org/viewvc/commons/proper/math/tags/MATH_2_1/
> >
> > And got this error:
> >
> > svn: Repository moved permanently to '/viewvc/commons/proper/math/tags/MATH_2_1/'; please relocate
>
> Not surprising - that is the web interface.
>
> You need
>
> $ svn co http://svn.apache.org/repos/asf/commons/proper/math/tags/MATH_2_1/
Thanks for the correction.
Maybe a suggestion for improvement: Provide a link pointing to the URL of
the repository from the project's page. From the link there (named "Source
Repository") you only get to the "viewvc" page. [In a browser, you also get
a "web" interface from the correct link to use in the "svn co" command. To
me it is surprising; and the cryptic message from svn isn't clear about what
the problem is and what could be the solution... Well, even their
(subversion) FAQ web page doesn't indicate the right formulation of the
error message!]
Regards,
Gilles
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [jira] Commented: (MATH-389) New superclass for
"AbstractScalarDifferentiableOptimizer"
Posted by sebb <se...@gmail.com>.
Changed to dev@
On 21 July 2010 08:50, Gilles Sadowski <gi...@harfang.homelinux.org> wrote:
>> >>> I ran "mvn site" but could not find the report. What is the file name?
>> >>
>> >> clirr-report.html
>> >>
>> >> It should be in top directory. It is generated by clirr-maven-plugin.
>> >> You can also try "mvn clirr:check" or "mvn clirr:clirr", see
>> >> <http://mojo.codehaus.org/clirr-maven-plugin/usage.html>
>> >
>> > Excerpt from the build output:
>> >
>> > [INFO] Unable to find a previous version of the project in the repository
>>
>> Perhaps you should make an "mvn install" of the previous version (i.e.
>> 2.1) in your local repository.
>
> Does that mean that I must check out the 2.1 tag?
> If so, I did the following
>
> $ svn co http://svn.apache.org/viewvc/commons/proper/math/tags/MATH_2_1/
>
> And got this error:
>
> svn: Repository moved permanently to '/viewvc/commons/proper/math/tags/MATH_2_1/'; please relocate
Not surprising - that is the web interface.
You need
$ svn co http://svn.apache.org/repos/asf/commons/proper/math/tags/MATH_2_1/
>
> Gilles
>
> P.S. I found the following possible explanation on the Subversion FAQ page:
> ---CUT---
> I can see my repository in a web browser, but 'svn checkout' gives me an
> error about "301 Moved Permanently". What's wrong?
>
> It means your httpd.conf is misconfigured. Usually this error happens when
> you've defined the Subversion virtual "location" to exist within two
> different scopes at the same time.
>
> For example, if you've exported a repository as <Location /www/foo>, but
> you've also set your DocumentRoot to be /www, then you're in trouble. When
> the request comes in for /www/foo/bar, apache doesn't know whether to find a
> real file named /foo/bar within your DocumentRoot, or whether to ask
> mod_dav_svn to fetch a file /bar from the /www/foo repository. Usually the
> former case wins, and hence the "Moved Permanently" error.
>
> The solution is to make sure your repository <Location> does not overlap or
> live within any areas already exported as normal web shares.
>
> It's also possible that you have an object in the web root which has the
> same name as your repository URL. For example, imagine your web server's
> document root is /var/www and your Subversion repository is located at
> /home/svn/repo. You then configure Apache to serve the repository at
> http://localhost/myrepo. If you then create the directory /var/www/myrepo/
> this will cause a 301 error to occur.
> ---CUT---
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [jira] Commented: (MATH-389) New superclass for
"AbstractScalarDifferentiableOptimizer"
Posted by Gilles Sadowski <gi...@harfang.homelinux.org>.
> >>> I ran "mvn site" but could not find the report. What is the file name?
> >>
> >> clirr-report.html
> >>
> >> It should be in top directory. It is generated by clirr-maven-plugin.
> >> You can also try "mvn clirr:check" or "mvn clirr:clirr", see
> >> <http://mojo.codehaus.org/clirr-maven-plugin/usage.html>
> >
> > Excerpt from the build output:
> >
> > [INFO] Unable to find a previous version of the project in the repository
>
> Perhaps you should make an "mvn install" of the previous version (i.e.
> 2.1) in your local repository.
Does that mean that I must check out the 2.1 tag?
If so, I did the following
$ svn co http://svn.apache.org/viewvc/commons/proper/math/tags/MATH_2_1/
And got this error:
svn: Repository moved permanently to '/viewvc/commons/proper/math/tags/MATH_2_1/'; please relocate
Gilles
P.S. I found the following possible explanation on the Subversion FAQ page:
---CUT---
I can see my repository in a web browser, but 'svn checkout' gives me an
error about "301 Moved Permanently". What's wrong?
It means your httpd.conf is misconfigured. Usually this error happens when
you've defined the Subversion virtual "location" to exist within two
different scopes at the same time.
For example, if you've exported a repository as <Location /www/foo>, but
you've also set your DocumentRoot to be /www, then you're in trouble. When
the request comes in for /www/foo/bar, apache doesn't know whether to find a
real file named /foo/bar within your DocumentRoot, or whether to ask
mod_dav_svn to fetch a file /bar from the /www/foo repository. Usually the
former case wins, and hence the "Moved Permanently" error.
The solution is to make sure your repository <Location> does not overlap or
live within any areas already exported as normal web shares.
It's also possible that you have an object in the web root which has the
same name as your repository URL. For example, imagine your web server's
document root is /var/www and your Subversion repository is located at
/home/svn/repo. You then configure Apache to serve the repository at
http://localhost/myrepo. If you then create the directory /var/www/myrepo/
this will cause a 301 error to occur.
---CUT---
Re: [jira] Commented: (MATH-389) New superclass for "AbstractScalarDifferentiableOptimizer"
Posted by Luc Maisonobe <Lu...@free.fr>.
Le 20/07/2010 23:13, Gilles Sadowski a écrit :
>
>>> I ran "mvn site" but could not find the report. What is the file name?
>>
>> clirr-report.html
>>
>> It should be in top directory. It is generated by clirr-maven-plugin.
>> You can also try "mvn clirr:check" or "mvn clirr:clirr", see
>> <http://mojo.codehaus.org/clirr-maven-plugin/usage.html>
>
> Excerpt from the build output:
>
> [INFO] Unable to find a previous version of the project in the repository
Perhaps you should make an "mvn install" of the previous version (i.e.
2.1) in your local repository.
Luc
> [INFO] Not generating Clirr report as there is no previous version of the library to compare against
>
>
> Gilles
Re: [jira] Commented: (MATH-389) New superclass for
"AbstractScalarDifferentiableOptimizer"
Posted by Gilles Sadowski <gi...@harfang.homelinux.org>.
> > I ran "mvn site" but could not find the report. What is the file name?
>
> clirr-report.html
>
> It should be in top directory. It is generated by clirr-maven-plugin.
> You can also try "mvn clirr:check" or "mvn clirr:clirr", see
> <http://mojo.codehaus.org/clirr-maven-plugin/usage.html>
Excerpt from the build output:
[INFO] Unable to find a previous version of the project in the repository
[INFO] Not generating Clirr report as there is no previous version of the library to compare against
Gilles
Re: [jira] Commented: (MATH-389) New superclass for "AbstractScalarDifferentiableOptimizer"
Posted by Luc Maisonobe <Lu...@free.fr>.
Le 20/07/2010 20:31, Gilles Sadowski a écrit :
>
>> At first sight, it seems good to me.
>> You can check there are incomatibilities by performing the changes locally and run "clirr" (for example by running "mvn site") and check the clirr report.
>
> I ran "mvn site" but could not find the report. What is the file name?
clirr-report.html
It should be in top directory. It is generated by clirr-maven-plugin.
You can also try "mvn clirr:check" or "mvn clirr:clirr", see
<http://mojo.codehaus.org/clirr-maven-plugin/usage.html>
Luc
>
>
> Gilles
Re: [jira] Commented: (MATH-389) New superclass for
"AbstractScalarDifferentiableOptimizer"
Posted by Gilles Sadowski <gi...@harfang.homelinux.org>.
> At first sight, it seems good to me.
> You can check there are incomatibilities by performing the changes locally and run "clirr" (for example by running "mvn site") and check the clirr report.
I ran "mvn site" but could not find the report. What is the file name?
Gilles
[jira] Resolved: (MATH-389) New superclass for
"AbstractScalarDifferentiableOptimizer"
Posted by "Gilles (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/MATH-389?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Gilles resolved MATH-389.
-------------------------
Resolution: Fixed
A refactoring along the lines proposed has been performed in r967288.
> New superclass for "AbstractScalarDifferentiableOptimizer"
> ----------------------------------------------------------
>
> Key: MATH-389
> URL: https://issues.apache.org/jira/browse/MATH-389
> Project: Commons Math
> Issue Type: Improvement
> Reporter: Gilles
> Assignee: Gilles
> Priority: Trivial
> Fix For: 2.2
>
>
> In package {{optimization.general}}, I propose to create a new class: "AbstractScalarOptimizer". It would contain all code currently in "AbstractScalarDifferentiableOptimizer" that is not related to derivatives. "AbstractScalarDifferentiableOptimizer" would then extend that class to add the derivative-related code.
> This new layer in the hierarchy will be the base class for algorithms that do not use derivatives.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (MATH-389) New superclass for
"AbstractScalarDifferentiableOptimizer"
Posted by "Gilles (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/MATH-389?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12890341#action_12890341 ]
Gilles commented on MATH-389:
-----------------------------
In fact, if we combine both ideas (base class and generics), I think that there is no compatibility risk:
New base generic interface:
{code:title=BaseMultivariateRealOptimizer.java|borderStyle=solid}
interface BaseMultivariateRealOptimizer<T extends MultivariateRealFunction> {
// ... All common methods
RealPointValuePair optimize(T func, GoalType goal, double[] start);
}
{code}
And trivially modified (but backward compatible) "MultivariateRealOptimizer" interface:
{code:title=MultivariateRealOptimizer.java|borderStyle=solid}
interface MultivariateRealOptimizer
extends BaseMultivariateRealOptimizer<MultivariateRealFunction> {}
{code}
> New superclass for "AbstractScalarDifferentiableOptimizer"
> ----------------------------------------------------------
>
> Key: MATH-389
> URL: https://issues.apache.org/jira/browse/MATH-389
> Project: Commons Math
> Issue Type: Improvement
> Reporter: Gilles
> Assignee: Gilles
> Priority: Trivial
> Fix For: 2.2
>
>
> In package {{optimization.general}}, I propose to create a new class: "AbstractScalarOptimizer". It would contain all code currently in "AbstractScalarDifferentiableOptimizer" that is not related to derivatives. "AbstractScalarDifferentiableOptimizer" would then extend that class to add the derivative-related code.
> This new layer in the hierarchy will be the base class for algorithms that do not use derivatives.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (MATH-389) New superclass for
"AbstractScalarDifferentiableOptimizer"
Posted by "Gilles (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/MATH-389?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12890338#action_12890338 ]
Gilles commented on MATH-389:
-----------------------------
There is a lot of duplication between "DifferentiableMultivariateRealOptimizer" and "MultivariateRealOptimizer" interfaces.
We could have a new "BaseMultivariateRealOptimizer" interface that will contain all the declarations common to both of the current interfaces? Each of those will then contain their {{optimize}} method declaration, plus any other specific ones (such as those related to "gradient" in "DifferentiableMultivariateRealOptimizer").
An alternative (perhaps more elegant but maybe not backward-compatible) would be to have
{code:title=MultivariateRealOptimizer.java|borderStyle=solid}
interface MultivariateRealOptimizer<T extends MultivariateRealFunction> {
// ... All common methods
RealPointValuePair optimize(T func, GoalType goal, double[] start);
}
{code}
{code:title=DifferentiableMultivariateRealOptimizer.java|borderStyle=solid}
interface DifferentiableMultivariateRealOptimizer
extends MultivariateRealOptimizer<DifferentiableMultivariateRealFunction> {
// ... All methods referring to "gradient".
}
{code}
What do you think?
> New superclass for "AbstractScalarDifferentiableOptimizer"
> ----------------------------------------------------------
>
> Key: MATH-389
> URL: https://issues.apache.org/jira/browse/MATH-389
> Project: Commons Math
> Issue Type: Improvement
> Reporter: Gilles
> Assignee: Gilles
> Priority: Trivial
> Fix For: 2.2
>
>
> In package {{optimization.general}}, I propose to create a new class: "AbstractScalarOptimizer". It would contain all code currently in "AbstractScalarDifferentiableOptimizer" that is not related to derivatives. "AbstractScalarDifferentiableOptimizer" would then extend that class to add the derivative-related code.
> This new layer in the hierarchy will be the base class for algorithms that do not use derivatives.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (MATH-389) New superclass for
"AbstractScalarDifferentiableOptimizer"
Posted by "Luc Maisonobe (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/MATH-389?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12890356#action_12890356 ]
Luc Maisonobe commented on MATH-389:
------------------------------------
At first sight, it seems good to me.
You can check there are incomatibilities by performing the changes locally and run "clirr" (for example by running "mvn site") and check the clirr report.
> New superclass for "AbstractScalarDifferentiableOptimizer"
> ----------------------------------------------------------
>
> Key: MATH-389
> URL: https://issues.apache.org/jira/browse/MATH-389
> Project: Commons Math
> Issue Type: Improvement
> Reporter: Gilles
> Assignee: Gilles
> Priority: Trivial
> Fix For: 2.2
>
>
> In package {{optimization.general}}, I propose to create a new class: "AbstractScalarOptimizer". It would contain all code currently in "AbstractScalarDifferentiableOptimizer" that is not related to derivatives. "AbstractScalarDifferentiableOptimizer" would then extend that class to add the derivative-related code.
> This new layer in the hierarchy will be the base class for algorithms that do not use derivatives.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.