Timeline for Extracting the function from InterpolatingFunction object
Current License: CC BY-SA 3.0
15 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Oct 13, 2017 at 11:49 | comment | added | Michael E2 |
@LLlAMnYP The method above does work on unequally spaced points, but not if the spacing varies wildly. It appears that InterpolatingFunction automatically splits data at points that are too close (I can get it to match if there aren't too many too-close points in a row). Or maybe it adapts the order locally. I don't know the criterion used. It is perhaps if the slope is too great in some relative sense. The result of InterpolatingFunction seems worse than the piecewise one in the example I got from your (random) code. Interesting -- didn't know it did such complicated things.
|
|
| Oct 13, 2017 at 7:34 | comment | added | LLlAMnYP |
I have fake data of the form data = Transpose[{#, Sin[#/30] + RandomReal[.1, 35]}] &@ Sort[RandomReal[100, 35]] in my answer under the link. Your fixed answer now works on {x,y} tuples out of the box, but that was the easy part, InterpolatingPolynomial doesn't seem to reproduce the result of Interpolation for arbitrarily spaced points (not that I'm complaining :-).
|
|
| Oct 12, 2017 at 23:35 | history | edited | Michael E2 | CC BY-SA 3.0 |
Simplified code
|
| Oct 12, 2017 at 15:39 | history | edited | Michael E2 | CC BY-SA 3.0 |
Improved code
|
| Oct 12, 2017 at 15:39 | comment | added | Michael E2 |
@LLlAMnYP There is no example in the linked dupe, but, yes, the old code assumed the abscissae were successive integers. Fixed now, I think. Let me know if it doesn't work for you. It won't work on all InterpolatingFunction methods, I think, just this type.
|
|
| Oct 12, 2017 at 13:44 | comment | added | LLlAMnYP | Is the success of this method reliant on data points being equidistant? I tried adapting it in the linked dupe, but clearly get invalid results. | |
| Sep 19, 2014 at 13:51 | vote | accept | Seleren | ||
| Sep 18, 2014 at 11:36 | comment | added | Michael E2 | @AlexeyPopkov Good point. I usually do consider relative error, but I was not thinking clearly and copied the code from the documentation. | |
| Sep 18, 2014 at 11:32 | comment | added | Alexey Popkov |
Thanks, it is clear now. I would add that plotting relative error would be more correct and it clearly shows that the relative error is of expected magnitude of lesser than 10^-15: Plot[(f[x] - pwf)/pwf, {x, 1, 28}, PlotRange -> All].
|
|
| Sep 18, 2014 at 11:16 | comment | added | Michael E2 | @AlexeyPopkov Thanks. See the update for the error explanation. (I copied the wrong code by mistake. It should work now.) | |
| Sep 18, 2014 at 11:14 | history | edited | Michael E2 | CC BY-SA 3.0 |
Fixed typo
|
| Sep 18, 2014 at 11:09 | history | edited | Michael E2 | CC BY-SA 3.0 |
Fixed typo
|
| Sep 18, 2014 at 11:02 | history | edited | Michael E2 | CC BY-SA 3.0 |
Responded to comment
|
| Sep 18, 2014 at 6:36 | comment | added | Alexey Popkov |
(+1) The data in your answer should be defined as simple 1D list in order your code to work properly. How do you explain relatively large differences (1*10^-12) between your implementation and the built-in?
|
|
| Sep 18, 2014 at 2:07 | history | answered | Michael E2 | CC BY-SA 3.0 |