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 2011/04/22 17:16:36 UTC

[jira] [Created] (MATH-562) "UnivariateRealPeriodicInterpolator"

"UnivariateRealPeriodicInterpolator"
------------------------------------

                 Key: MATH-562
                 URL: https://issues.apache.org/jira/browse/MATH-562
             Project: Commons Math
          Issue Type: New Feature
            Reporter: Gilles
            Assignee: Gilles
            Priority: Minor
             Fix For: 3.0


It would be an interpolator implementation that assumes that the data to be interpolated is periodic. Thus values that are outside of the range can be passed to the interpolation function:
They will be wrapped into the initial range before being passed to the class that actually computes the interpolation.
The constructor prototype would be:
{code}
/**
 * Builds an interpolator.
 *
 * @param interpolator Interpolator.
 * @param period Period.
 * @param offset Offset.
 * @param extend Number of points to be appended at the beginning and
 * end of the sample arrays in order to avoid interpolation failure at
 * the (periodic) boundaries of the orginal interval. The value is the
 * number of sample points which the original {@code interpolator} needs
 * on each side of the interpolation point.
 */
public UnivariateRealPeriodicInterpolator(UnivariateRealInterpolator interpolator,
                                          double period,
                                          double offset,
                                          int extend) {
    // ...
}
{code}
Would it be useful to have that in CM?


--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (MATH-562) "UnivariateRealPeriodicInterpolator"

Posted by "Gilles (JIRA)" <ji...@apache.org>.
    [ https://issues.apache.org/jira/browse/MATH-562?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13025766#comment-13025766 ] 

Gilles commented on MATH-562:
-----------------------------

I've removed the "offset" parameter.

Shall I commit the code? You can then maybe figure out a unit test that shows the possible problems.


> "UnivariateRealPeriodicInterpolator"
> ------------------------------------
>
>                 Key: MATH-562
>                 URL: https://issues.apache.org/jira/browse/MATH-562
>             Project: Commons Math
>          Issue Type: New Feature
>            Reporter: Gilles
>            Assignee: Gilles
>            Priority: Minor
>             Fix For: 3.0
>
>
> It would be an interpolator implementation that assumes that the data to be interpolated is periodic. Thus values that are outside of the range can be passed to the interpolation function:
> They will be wrapped into the initial range before being passed to the class that actually computes the interpolation.
> The constructor prototype would be:
> {code}
> /**
>  * Builds an interpolator.
>  *
>  * @param interpolator Interpolator.
>  * @param period Period.
>  * @param offset Offset.
>  * @param extend Number of points to be appended at the beginning and
>  * end of the sample arrays in order to avoid interpolation failure at
>  * the (periodic) boundaries of the orginal interval. The value is the
>  * number of sample points which the original {@code interpolator} needs
>  * on each side of the interpolation point.
>  */
> public UnivariateRealPeriodicInterpolator(UnivariateRealInterpolator interpolator,
>                                           double period,
>                                           double offset,
>                                           int extend) {
>     // ...
> }
> {code}
> Would it be useful to have that in CM?

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (MATH-562) "UnivariateRealPeriodicInterpolator"

Posted by "Phil Steitz (JIRA)" <ji...@apache.org>.
    [ https://issues.apache.org/jira/browse/MATH-562?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13024947#comment-13024947 ] 

Phil Steitz commented on MATH-562:
----------------------------------

Sorry for the slow response and lack of understanding.  I still don't quite get the "offset."  What exactly does this mean? Isn't every point a potential period start point?  Maybe this is a root?  

What I meant by "fitness" was some kind of reasonability test to ensure that the data conform to the assumption of periodicity.  Not necessary, but I can imagine scenarios where piecing together a periodic interpolator from a set of sample points would result in strange and/or not well-defined behavior.  I could be misunderstanding the setup, but isn't there a risk that values for points near "cut points" are not well-defined?  What I mean by a "cut point" is a point near the end of the sample, say between the period sample point and the "extra" point added after the end.  There will be an interpolated value for that point based on the "base" interpolator.  The periodic interpolator will return a value for that point based on translation / extrapolation (assuming I am understanding the setup).  If the underlying function really is periodic, we have the right period and the base interpolator works perfectly, then these values will be the same.  If not, they could be different.  How badly different they can be is what I was referring to as "fitness."

In any case, I think this could be a useful addition and as long as we document exactly what it does, I am +1 to add.

> "UnivariateRealPeriodicInterpolator"
> ------------------------------------
>
>                 Key: MATH-562
>                 URL: https://issues.apache.org/jira/browse/MATH-562
>             Project: Commons Math
>          Issue Type: New Feature
>            Reporter: Gilles
>            Assignee: Gilles
>            Priority: Minor
>             Fix For: 3.0
>
>
> It would be an interpolator implementation that assumes that the data to be interpolated is periodic. Thus values that are outside of the range can be passed to the interpolation function:
> They will be wrapped into the initial range before being passed to the class that actually computes the interpolation.
> The constructor prototype would be:
> {code}
> /**
>  * Builds an interpolator.
>  *
>  * @param interpolator Interpolator.
>  * @param period Period.
>  * @param offset Offset.
>  * @param extend Number of points to be appended at the beginning and
>  * end of the sample arrays in order to avoid interpolation failure at
>  * the (periodic) boundaries of the orginal interval. The value is the
>  * number of sample points which the original {@code interpolator} needs
>  * on each side of the interpolation point.
>  */
> public UnivariateRealPeriodicInterpolator(UnivariateRealInterpolator interpolator,
>                                           double period,
>                                           double offset,
>                                           int extend) {
>     // ...
> }
> {code}
> Would it be useful to have that in CM?

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (MATH-562) "UnivariateRealPeriodicInterpolator"

Posted by "Gilles (JIRA)" <ji...@apache.org>.
    [ https://issues.apache.org/jira/browse/MATH-562?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13023431#comment-13023431 ] 

Gilles commented on MATH-562:
-----------------------------

{quote}
Is the idea that the data are assumed to be coming from a periodic function with known period?
{quote}
Yes.

{quote}
Is there any constraint on the number of periods that the sample data is supposed to represent, or are we assuming that it represents just one period with some points extending before and after?
{quote}
No, it is just assumed that the underlying time series is periodic with the given period.
However, there might be a problem if more than one period is covered by the sample data: If there are 2 samples exactly one period apart, they will be mapped to the same point and the interpolator will throw an exception because "xval" is not strictly increasing...

{quote}
[...] the application is to extend the domain of the interpolating function outside of the domain determined by the data?
{quote}
Yes.

{quote}
Don't you maybe need two parameters for "extend" (number before beginning of function period and number after) [...]
{quote}
Why? The "extend" points are there only to avoid that the interpolating algorithm fails because it would lack the required number of points when trying to interpolate at the ends of the interval: For example, the linear interpolation needs one point before and one point after the interpolated point but the latter won't exist when x > xval[xval.length - 1]. Hence, we replace "xval" with an _extended_ "xvalP" such that
{code}
  xvalP[xvalP.length - 1] = xval[0] + period
{code}

{quote}
Don't you [...] maybe even [need] two "offset" parameters (distance between beginning of the period and the first "interior" domain value and between last "interior" domain value and end of the period)?
{quote}
I'm not sure that we mean the same thing with that "offset". I only meant it as the "zero-point" of the periodic signal.

I didn't get the "fitness" idea. Maybe that you target something more powerful than what I had in mind.


> "UnivariateRealPeriodicInterpolator"
> ------------------------------------
>
>                 Key: MATH-562
>                 URL: https://issues.apache.org/jira/browse/MATH-562
>             Project: Commons Math
>          Issue Type: New Feature
>            Reporter: Gilles
>            Assignee: Gilles
>            Priority: Minor
>             Fix For: 3.0
>
>
> It would be an interpolator implementation that assumes that the data to be interpolated is periodic. Thus values that are outside of the range can be passed to the interpolation function:
> They will be wrapped into the initial range before being passed to the class that actually computes the interpolation.
> The constructor prototype would be:
> {code}
> /**
>  * Builds an interpolator.
>  *
>  * @param interpolator Interpolator.
>  * @param period Period.
>  * @param offset Offset.
>  * @param extend Number of points to be appended at the beginning and
>  * end of the sample arrays in order to avoid interpolation failure at
>  * the (periodic) boundaries of the orginal interval. The value is the
>  * number of sample points which the original {@code interpolator} needs
>  * on each side of the interpolation point.
>  */
> public UnivariateRealPeriodicInterpolator(UnivariateRealInterpolator interpolator,
>                                           double period,
>                                           double offset,
>                                           int extend) {
>     // ...
> }
> {code}
> Would it be useful to have that in CM?

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Resolved] (MATH-562) "UnivariateRealPeriodicInterpolator"

Posted by "Gilles (JIRA)" <ji...@apache.org>.
     [ https://issues.apache.org/jira/browse/MATH-562?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Gilles resolved MATH-562.
-------------------------

    Resolution: Fixed

Initial code committed in revision 1097426.


> "UnivariateRealPeriodicInterpolator"
> ------------------------------------
>
>                 Key: MATH-562
>                 URL: https://issues.apache.org/jira/browse/MATH-562
>             Project: Commons Math
>          Issue Type: New Feature
>            Reporter: Gilles
>            Assignee: Gilles
>            Priority: Minor
>             Fix For: 3.0
>
>
> It would be an interpolator implementation that assumes that the data to be interpolated is periodic. Thus values that are outside of the range can be passed to the interpolation function:
> They will be wrapped into the initial range before being passed to the class that actually computes the interpolation.
> The constructor prototype would be:
> {code}
> /**
>  * Builds an interpolator.
>  *
>  * @param interpolator Interpolator.
>  * @param period Period.
>  * @param offset Offset.
>  * @param extend Number of points to be appended at the beginning and
>  * end of the sample arrays in order to avoid interpolation failure at
>  * the (periodic) boundaries of the orginal interval. The value is the
>  * number of sample points which the original {@code interpolator} needs
>  * on each side of the interpolation point.
>  */
> public UnivariateRealPeriodicInterpolator(UnivariateRealInterpolator interpolator,
>                                           double period,
>                                           double offset,
>                                           int extend) {
>     // ...
> }
> {code}
> Would it be useful to have that in CM?

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (MATH-562) "UnivariateRealPeriodicInterpolator"

Posted by "Luc Maisonobe (JIRA)" <ji...@apache.org>.
    [ https://issues.apache.org/jira/browse/MATH-562?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13023264#comment-13023264 ] 

Luc Maisonobe commented on MATH-562:
------------------------------------

Why not ?

> "UnivariateRealPeriodicInterpolator"
> ------------------------------------
>
>                 Key: MATH-562
>                 URL: https://issues.apache.org/jira/browse/MATH-562
>             Project: Commons Math
>          Issue Type: New Feature
>            Reporter: Gilles
>            Assignee: Gilles
>            Priority: Minor
>             Fix For: 3.0
>
>
> It would be an interpolator implementation that assumes that the data to be interpolated is periodic. Thus values that are outside of the range can be passed to the interpolation function:
> They will be wrapped into the initial range before being passed to the class that actually computes the interpolation.
> The constructor prototype would be:
> {code}
> /**
>  * Builds an interpolator.
>  *
>  * @param interpolator Interpolator.
>  * @param period Period.
>  * @param offset Offset.
>  * @param extend Number of points to be appended at the beginning and
>  * end of the sample arrays in order to avoid interpolation failure at
>  * the (periodic) boundaries of the orginal interval. The value is the
>  * number of sample points which the original {@code interpolator} needs
>  * on each side of the interpolation point.
>  */
> public UnivariateRealPeriodicInterpolator(UnivariateRealInterpolator interpolator,
>                                           double period,
>                                           double offset,
>                                           int extend) {
>     // ...
> }
> {code}
> Would it be useful to have that in CM?

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (MATH-562) "UnivariateRealPeriodicInterpolator"

Posted by "Phil Steitz (JIRA)" <ji...@apache.org>.
    [ https://issues.apache.org/jira/browse/MATH-562?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13023337#comment-13023337 ] 

Phil Steitz commented on MATH-562:
----------------------------------

Indeed, why not?  I am not following exactly what is being proposed, though.  Is the idea that the data are assumed to be coming from a periodic function with known period?  Is there any constraint on the number of periods that the sample data is supposed to represent, or are we assuming that it represents just one period with some points extending before and after?  I guess the application is to extend the domain of the interpolating function outside of the domain determined by the data?  Don't you maybe need two parameters for "extend" (number before beginning of function period and number after) and maybe even two "offset" parameters (distance between beginning of the period and the first "interior" domain value and between last "interior" domain value and end of the period)?  Could well be I am misunderstanding the setup here.  Another thing that I don't quite get is it would seem some kind of fitness measure would be needed to ensure that the designation of the "interior" points is consistent with periodicity (i.e., behavior in a neighborhood of period start and end points is similar).

> "UnivariateRealPeriodicInterpolator"
> ------------------------------------
>
>                 Key: MATH-562
>                 URL: https://issues.apache.org/jira/browse/MATH-562
>             Project: Commons Math
>          Issue Type: New Feature
>            Reporter: Gilles
>            Assignee: Gilles
>            Priority: Minor
>             Fix For: 3.0
>
>
> It would be an interpolator implementation that assumes that the data to be interpolated is periodic. Thus values that are outside of the range can be passed to the interpolation function:
> They will be wrapped into the initial range before being passed to the class that actually computes the interpolation.
> The constructor prototype would be:
> {code}
> /**
>  * Builds an interpolator.
>  *
>  * @param interpolator Interpolator.
>  * @param period Period.
>  * @param offset Offset.
>  * @param extend Number of points to be appended at the beginning and
>  * end of the sample arrays in order to avoid interpolation failure at
>  * the (periodic) boundaries of the orginal interval. The value is the
>  * number of sample points which the original {@code interpolator} needs
>  * on each side of the interpolation point.
>  */
> public UnivariateRealPeriodicInterpolator(UnivariateRealInterpolator interpolator,
>                                           double period,
>                                           double offset,
>                                           int extend) {
>     // ...
> }
> {code}
> Would it be useful to have that in CM?

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira