commons-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Romeo Palijan (JIRA)" <j...@apache.org>
Subject [jira] Issue Comment Edited: (MATH-296) LoessInterpolator.smooth() not working correctly
Date Wed, 30 Sep 2009 22:17:23 GMT

    [ https://issues.apache.org/jira/browse/MATH-296?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12761022#action_12761022
] 

Romeo Palijan edited comment on MATH-296 at 9/30/09 3:16 PM:
-------------------------------------------------------------

Sorry, maybe I was a little unclear in my explanation. 
Actually there is data, there are just no weights in the approximation window. Lets say we
have 300 point and the first 100 are weighted 0, the others are weighted 1, they are still
valid data points. Being weighted 0 does not mean the data point can be deleted, it just means
it does not affect his neighbours in terms of normalization (that is how the concept of normalization
weights was explained to me)
What happens currently is the first ones become NaN and their neighbours become NaN to the
point that *all* points become NaN. This shouldn't happen.
But do not misunderstand me, I am just assuming that the reason is because of the bandwidth
as my dataset has this structure, I am not really sure about it. 
I have done some debugging on the code but there are really a lot of loops so I could not
pinpoint when and why exactly this is starting to happen as it is not right from the beginning.

      was (Author: romeop):
    Sorry, maybe I was a little unclear in my explanation. 
Actually there is data, there are just no weights in the approximation window. Lets say we
have 300 point and the first 100 are weighted 0, the others are weighted 1, they are still
valid data points. 
What happens currently is the first ones become NaN and their neighbours become NaN to the
point that *all* points become NaN. This shouldn't happen.
But do not misunderstand me, I am just assuming that the reason is because of the bandwidth
as my dataset has this structure, I am not really sure about it. 
I have done some debugging on the code but there are really a lot of loops so I could not
pinpoint when and why exactly this is starting to happen as it is not right from the beginning.
  
> LoessInterpolator.smooth() not working correctly
> ------------------------------------------------
>
>                 Key: MATH-296
>                 URL: https://issues.apache.org/jira/browse/MATH-296
>             Project: Commons Math
>          Issue Type: Bug
>    Affects Versions: 2.0
>         Environment: Java 1.6 on Vista
>            Reporter: Romeo Palijan
>             Fix For: 2.1
>
>         Attachments: math-296-test.patch, math-296.patch
>
>
> I have been comparing LoessInterpolator.smooth output with the loessFit output from R
(R-project.org, probably the most widely used loess implementation) and have had strangely
different numbers. I have created a small set to test the difference and something seems to
be wrong with the smooth method but I do no know what and I do not understand the code.
> *Example 1*
> |x-input: |1.5| 3.0| 6| 8| 12|13| 22| 24|28|31|
> |y-input: |3.1|6.1|3.1|2.1|1.4|5.1|5.1|6.1|7.1|7.2|
> |Output LoessInterpolator.smooth():|NaN|NaN|NaN|NaN|NaN|NaN|NaN|NaN|NaN|NaN|
> |Output from loessFit() from R: |3.191178027520974|3.0407201231474037|2.7089538903778636|2.7450823274490297|4.388011000549519|4.60078952381848|5.2988217587114805|5.867536388457898|6.7797794777879705|7.444888598397342|
> *Example 2 (same x-values, y-values just floored)*
> |x-input: |1.5| 3.0| 6| 8| 12|13| 22| 24|28|31|
> |y-input: |3|6|3|2|1|5|5|6|7|7|
> |Output LoessInterpolator.smooth(): |3|6|3|2|0.9999999999999005|5.0000000000001705|5|5.999999999999972|7|6.999999999999967|
> |Output from loessFit() from R: |3.091423927353068|2.9411521572524237|2.60967950675505|2.7421759322272248|4.382996912300442|4.646774316632562|5.225153658563424|5.768301917477015|6.637079139313073|7.270482144410326|
> As you see the output is practically the replicated y-input.
> At this point this funtionality is critical for us but I could not find any other suitable
java-implementation. Help. Maybe this strange behaviour gives someone a clue?

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


Mime
View raw message