[ https://issues.apache.org/jira/browse/MATH296?page=com.atlassian.jira.plugin.system.issuetabpanels:alltabpanel
]
Luc Maisonobe updated MATH296:

Attachment: math296test.patch
The math296test.patch is a set of two test cases that reproduce the problem.
Running the first test shows that at the end of iteration 0, the weights for points at indices
4 and 5 are set to 0. At iteration 1, when computing point i=4, the bandwidth is such that
ileft=3 and iright=4. For k=3, we get w=0 because dist=4 and denom=1/4. For k=4 and k=5, we
get w=0 because robustness[k]=0. So all w are 0, sumWeights=0 and since it is used in some
divisions, NaN appears.
I think their should be some protection against this case somewhere. I'll ask the author of
the original contribution about this.
> LoessInterpolator.smooth() not working correctly
> 
>
> Key: MATH296
> URL: https://issues.apache.org/jira/browse/MATH296
> Project: Commons Math
> Issue Type: Bug
> Affects Versions: 2.0
> Environment: Java 1.6 on Vista
> Reporter: Romeo Palijan
> Attachments: math296test.patch
>
>
> I have been comparing LoessInterpolator.smooth output with the loessFit output from R
(Rproject.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*
> xinput: 1.5 3.0 6 8 1213 22 242831
> yinput: 3.16.13.12.11.45.15.16.17.17.2
> Output LoessInterpolator.smooth():NaNNaNNaNNaNNaNNaNNaNNaNNaNNaN
> Output from loessFit() from R: 3.1911780275209743.04072012314740372.70895389037786362.74508232744902974.3880110005495194.600789523818485.29882175871148055.8675363884578986.77977947778797057.444888598397342
> *Example 2 (same xvalues, yvalues just floored)*
> xinput: 1.5 3.0 6 8 1213 22 242831
> yinput: 3632155677
> Output LoessInterpolator.smooth(): 36320.99999999999990055.000000000000170555.99999999999997276.999999999999967
> Output from loessFit() from R: 3.0914239273530682.94115215725242372.609679506755052.74217593222722484.3829969123004424.6467743166325625.2251536585634245.7683019174770156.6370791393130737.270482144410326
> As you see the output is practically the replicated yinput.
> At this point this funtionality is critical for us but I could not find any other suitable
javaimplementation. 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.
