Details

    • Type: New Feature New Feature
    • Status: Resolved
    • Priority: Minor Minor
    • Resolution: Incomplete
    • Affects Version/s: None
    • Fix Version/s: None
    • Labels:

      Description

      Implementation of the numerical first derivative, as described in:

      Accurate computation of F'(x) and F'(x) F''(x)
      C. J. F. Ridders
      Adv. Eng. Software, 1982, Vol 4, No. 2
      

        Activity

        Gilles made changes -
        Status Open [ 1 ] Resolved [ 5 ]
        Fix Version/s 3.1 [ 12317576 ]
        Resolution Incomplete [ 4 ]
        Hide
        Gilles added a comment -

        The provided code was buggy.

        Since the proposed API is not satisfying, and this does not seem to be high priority, it's better to revisit this once the basic interfaces have been set up.

        Show
        Gilles added a comment - The provided code was buggy. Since the proposed API is not satisfying, and this does not seem to be high priority, it's better to revisit this once the basic interfaces have been set up.
        Gilles made changes -
        Attachment RiddersFirstDerivative.java [ 12507685 ]
        Gilles made changes -
        Fix Version/s 3.1 [ 12317576 ]
        Fix Version/s 3.0 [ 12314824 ]
        Hide
        Gilles added a comment -

        Postponed.

        Show
        Gilles added a comment - Postponed.
        Hide
        Luc Maisonobe added a comment -

        OK, so can we postpone this to 3.1 ?

        Show
        Luc Maisonobe added a comment - OK, so can we postpone this to 3.1 ?
        Hide
        Gilles added a comment -

        The additional input like tolerances can be specified in the Ridders constructor, [...]

        This sentence makes me think that we don't understand each other: the tolerance currently is passed in the constructor. It is the method that computes the derivative (which takes additional parameters and returns a double in "RiddersFirstDerivative", while in "nabla" I think that the equivalent method would return a "function" object).

        Anyways, this should not be a blocking issue, while at the same time, we should probably not jump too quickly to a conclusion concerning the API (here and there). So probably better to leave this for later.

        Show
        Gilles added a comment - The additional input like tolerances can be specified in the Ridders constructor, [...] This sentence makes me think that we don't understand each other: the tolerance currently is passed in the constructor. It is the method that computes the derivative (which takes additional parameters and returns a double in "RiddersFirstDerivative", while in "nabla" I think that the equivalent method would return a "function" object). Anyways, this should not be a blocking issue, while at the same time, we should probably not jump too quickly to a conclusion concerning the API (here and there). So probably better to leave this for later.
        Hide
        Luc Maisonobe added a comment -

        OK then, I'll take care of this issue and will import Nabla interfaces in Math, trying to merge the two interfaces.

        I don't think thee are so much differences. The additional input like tolerances can be specified in the Ridders constructor, just like absolute and relative accuracy are set up in solvers. We could also merge the various Nabla finite differences schemes into one class and use a constructor parameter to choose the number of points in the finite differences. The max evaluations in the would not be used in finite differences.

        Here is what I intend to do:

        • replace Nabla UnivariateDifferentiable by Math UnivariateFunction
        • adapt Nabla UnivariateDerivative to the change above
        • keep Nabla DifferentialPair as is
        • adapt UnivariateDifferentiator to have an additional max evaluation parameter, in the Solvers spirit
        Show
        Luc Maisonobe added a comment - OK then, I'll take care of this issue and will import Nabla interfaces in Math, trying to merge the two interfaces. I don't think thee are so much differences. The additional input like tolerances can be specified in the Ridders constructor, just like absolute and relative accuracy are set up in solvers. We could also merge the various Nabla finite differences schemes into one class and use a constructor parameter to choose the number of points in the finite differences. The max evaluations in the would not be used in finite differences. Here is what I intend to do: replace Nabla UnivariateDifferentiable by Math UnivariateFunction adapt Nabla UnivariateDerivative to the change above keep Nabla DifferentialPair as is adapt UnivariateDifferentiator to have an additional max evaluation parameter, in the Solvers spirit
        Hide
        Gilles added a comment -

        We could wait, but I don't understand why we should.
        The code is there, and could already be useful as is. Moreover, what you propose regarding the convergence with "nabla" is far from clear to me.
        IIUC, "nabla" computes the derivative of a function, without any additional input. The Ridders algorithm however is an approximating procedure where you must specify a tolerance, an initial "delta" and a maximum number of function evaluations (just like for the solvers and optimizers algorithms).
        For CM design consistency's sake (and ease of use), this algorithm must be introduced in a form that relates to the existing codes in CM, not in a form that one expects will conform to a future requirement from another library.

        Later, we can always create adapters that will bridge the CM API to the "nabla" API (e.g. possibly passing the additional parameters needed by the "derivative" method of "RiddersFirstDerivative" in the constructor of the adapter class).

        Show
        Gilles added a comment - We could wait, but I don't understand why we should. The code is there, and could already be useful as is. Moreover, what you propose regarding the convergence with "nabla" is far from clear to me. IIUC, "nabla" computes the derivative of a function, without any additional input . The Ridders algorithm however is an approximating procedure where you must specify a tolerance, an initial "delta" and a maximum number of function evaluations (just like for the solvers and optimizers algorithms). For CM design consistency's sake (and ease of use), this algorithm must be introduced in a form that relates to the existing codes in CM, not in a form that one expects will conform to a future requirement from another library. Later, we can always create adapters that will bridge the CM API to the "nabla" API (e.g. possibly passing the additional parameters needed by the "derivative" method of "RiddersFirstDerivative" in the constructor of the adapter class).
        Hide
        Luc Maisonobe added a comment -

        I think we can wait to 3.1, as this would be mainly a new package.

        Show
        Luc Maisonobe added a comment - I think we can wait to 3.1, as this would be mainly a new package.
        Hide
        Phil Steitz added a comment -

        +1 to moving the [nabla] numerics code into [math] and standardizing on the [nabla] API (which will become the [math] API that [nabla] will depend on). If the API is not to everyone's liking, we can change it. The relevant classes are in o.a.c.nabla.numerical and o.a.c.nabla.core in the [nabla] sandbox svn, per Luc's links above.

        Might be best to postpone this until post-3.0, as the package additions could be done in 3.1 without breaks; but I would personally be OK with a lift and load from [nabla] (along with the proposed Ridder's impl) for 3.0 if someone is willing to do the work.

        Show
        Phil Steitz added a comment - +1 to moving the [nabla] numerics code into [math] and standardizing on the [nabla] API (which will become the [math] API that [nabla] will depend on). If the API is not to everyone's liking, we can change it. The relevant classes are in o.a.c.nabla.numerical and o.a.c.nabla.core in the [nabla] sandbox svn, per Luc's links above. Might be best to postpone this until post-3.0, as the package additions could be done in 3.1 without breaks; but I would personally be OK with a lift and load from [nabla] (along with the proposed Ridder's impl) for 3.0 if someone is willing to do the work.
        Hide
        Gilles added a comment -

        The proposed code was modelled against the structure of solvers and optimizers classes (method "derivative" is the counterpart of "solve" and "optimize", respectively).
        What you propose seems to depart from this, but I cannot really judge because I don't know anything about "nabla".

        It may be the right way in the longer term... However, given the resources devoted to "nabla", I don't think that it is wise to force Commons Math to fit the current design of "nabla". I see well that "nabla" and CM could converge at the time of CM version 4.0.
        But for v3.x it could be fine to provide the low-level bits .

        But it can also be that I completely missed your point. If so, could you please post the code that would help me figure out what you propose?

        Show
        Gilles added a comment - The proposed code was modelled against the structure of solvers and optimizers classes (method "derivative" is the counterpart of "solve" and "optimize", respectively). What you propose seems to depart from this, but I cannot really judge because I don't know anything about "nabla". It may be the right way in the longer term... However, given the resources devoted to "nabla", I don't think that it is wise to force Commons Math to fit the current design of "nabla". I see well that "nabla" and CM could converge at the time of CM version 4.0. But for v3.x it could be fine to provide the low-level bits . But it can also be that I completely missed your point. If so, could you please post the code that would help me figure out what you propose?
        Hide
        Luc Maisonobe added a comment -

        If we want to implement derivatives, I would rather set up a top level interface and several implementations, including this one. We could for example import the definitions from Nabla core package (http://svn.apache.org/viewvc/commons/sandbox/nabla/trunk/src/main/java/org/apache/commons/nabla/core/) and the implementations of Nabla numerical package (http://svn.apache.org/viewvc/commons/sandbox/nabla/trunk/src/main/java/org/apache/commons/nabla/numerical/). Of course, once imported these packages would be removed from Nabla itself and replaced by a dependency to Math.

        Show
        Luc Maisonobe added a comment - If we want to implement derivatives, I would rather set up a top level interface and several implementations, including this one. We could for example import the definitions from Nabla core package ( http://svn.apache.org/viewvc/commons/sandbox/nabla/trunk/src/main/java/org/apache/commons/nabla/core/ ) and the implementations of Nabla numerical package ( http://svn.apache.org/viewvc/commons/sandbox/nabla/trunk/src/main/java/org/apache/commons/nabla/numerical/ ). Of course, once imported these packages would be removed from Nabla itself and replaced by a dependency to Math.
        Gilles made changes -
        Field Original Value New Value
        Attachment RiddersFirstDerivative.java [ 12507685 ]
        Hide
        Gilles added a comment -

        Attached proposed implementation. OK to add?

        Show
        Gilles added a comment - Attached proposed implementation. OK to add?
        Gilles created issue -

          People

          • Assignee:
            Gilles
            Reporter:
            Gilles
          • Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development