-
Notifications
You must be signed in to change notification settings - Fork 900
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add method with option to not allow extrapolation. #995
base: master
Are you sure you want to change the base?
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -130,6 +130,24 @@ public static LinearSpline Interpolate(IEnumerable<double> x, IEnumerable<double | |
/// <returns>Interpolated value x(t).</returns> | ||
public double Interpolate(double t) | ||
{ | ||
return Interpolate(t, true); | ||
} | ||
|
||
/// <summary> | ||
/// Interpolate at point t. | ||
/// </summary> | ||
/// <param name="t">Point t to interpolate at.</param> | ||
/// <param name="allowExtrapolate">set to fals if extrapolate should not be allowed</param> | ||
/// <returns>Interpolated value x(t).</returns> | ||
/// <exception cref="ArgumentOutOfRangeException">Thrown when t is outside range and would result in Extrapolation!</exception> | ||
public double Interpolate(double t, bool allowExtrapolate) | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. That all the interpolators extrapolate by default is possibly surprising behaviour, especially given that is not documented (as far as I can tell). Perhaps a cleaner implementation would be to create a decorator class called |
||
{ | ||
if (!allowExtrapolate && | ||
(t < _x[0] || t > _x[_x.Length - 1])) | ||
{ | ||
throw new ArgumentOutOfRangeException("'t' is outside of the constructed array. This would result in Extrapolation!"); | ||
} | ||
|
||
int k = LeftSegmentIndex(t); | ||
return _c0[k] + (t - _x[k])*_c1[k]; | ||
} | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am not a big fan of
bool
variables in public APIs which act like toggle switches. I would rather create another public function, something likeInterpolateWithPossibleExtrapolation
, which probably needs to defined on the interface, so every instance can implement it.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I understand, it was intended to keep the interface clean and avoid polution of weird functions. Adding an additional function like
InterpolateWithoutExtrapolation
felt a bit like polluting the clean interface.Also I didn't want to break any compatibility since the default behavior is currently with possible extrapolation.
To be honest (now I read it again) I can see it isn't making the interface less confusing since the flag name can give the impression that extrapolation is by default not allowed.
As stated in the pull request as well. If you do see potential in the addition of such functionality we can discuss what the most suitable implementation is and how it fits the library best.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hi again. I am in favor of having a clean API, and I feel that your proposal is in the right direction.
You are right, the name I suggested should have been
InterpolateWithoutExtrapolation