You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Mi...@dlr.de on 2022/09/02 17:01:24 UTC
AW: Extending math4.legacy with clamped spline interpolation
Thank you Gilles for your detailed response!
Gilles wrote:
> [...]
> How about "SplineInterpolator" provide a factory method to select one or the
> other implementation?
> I.e. something like
> ---CUT---
> public SplineInterpolator implements UnivariateInterpolator {
> /** Interpolation algorithm variant. */
> private final BiFunction<double[], double[], UnivariateFunction> algo;
>
> /**
> * Factory method.
> * @param clamped ...
> * @return a new interpolator instance.
> */
> public static SplineInterpolator create(boolean clamped) {
> if (clamped) {
> algo = new Clamped();
> } else {
> algo = new Unclamped();
> }
> }
>
> @Override
> public PolynomialSplineFunction interpolate(double[] x, double[] y) {
> return algo.apply(x, y);
> }
>
> private static class Unclamped
> implements BiFunction<double[], double[], PolynomialSplineFunction> {
> // ... current implementation ...
> }
>
> private static class Clamped
> implements BiFunction<double[], double[], PolynomialSplineFunction> {
> // ... your proposed functionality ...
> }
>
> // Commons functions ...
> }
> ---CUT---
I like your idea of a factory method for "SplineInterpolator" but am not sure whether it will provide any benefit. The newly proposed "clamped" spline requires two additional boundary conditions specifying the slopes at each interpolation run and thus, simply overloading of the interpolate(...) function of interface UnivariateInterpolator to accept two additional parameters seems to be an attractive approach. Something like this:
---CUT---8<---
public class SplineInterpolator implements UnivariateInterpolator {
@Override
public PolynomialSplineFunction interpolate(double[] x, double[] y) {
// ... current default implementation of unclamped spline ...
}
public PolynomialSplineFunction interpolate(double[] x, double[] y, double startSlope, double endSlope) {
// ... newly proposed clamped spline variant ...
}
// Commons functions ...
}
--->8---CUT---
Is this still complying with the library design or will it break hearts? What do you think? If we wanted to specify the additional slope parameters in your factory method approach, these parameters would have to be passed initially during creation of the new BiFunction object and thus would require a re-creation of the whole object for each new interpolation run with just varying slope parameters. I'm not sure if this "overhead" is desired :D
Thanks in advance!
Michi
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
AW: Extending math4.legacy with clamped spline interpolation
Posted by Mi...@dlr.de.
Gilles wrote:
> [...]
> Could you perhaps open a JIRA[1] report? You can then attach a patch, with
> use cases, from which we can further discuss what API changes would best
> handle them.
> [1] https://issues.apache.org/jira/browse/MATH
As recommended by you, I just filed this issue as feature request with a patch in JIRA https://issues.apache.org/jira/browse/MATH-1650 for further technical discussion.
Thanks!
Michi
Re: Extending math4.legacy with clamped spline interpolation
Posted by Gilles Sadowski <gi...@gmail.com>.
Hello.
Le ven. 2 sept. 2022 à 19:01, <Mi...@dlr.de> a écrit :
>
> Thank you Gilles for your detailed response!
>
> Gilles wrote:
> > [...]
> > How about "SplineInterpolator" provide a factory method to select one or the
> > other implementation?
> > I.e. something like
> > ---CUT---
> > public SplineInterpolator implements UnivariateInterpolator {
> > /** Interpolation algorithm variant. */
> > private final BiFunction<double[], double[], UnivariateFunction> algo;
> >
> > /**
> > * Factory method.
> > * @param clamped ...
> > * @return a new interpolator instance.
> > */
> > public static SplineInterpolator create(boolean clamped) {
> > if (clamped) {
> > algo = new Clamped();
> > } else {
> > algo = new Unclamped();
> > }
> > }
> >
> > @Override
> > public PolynomialSplineFunction interpolate(double[] x, double[] y) {
> > return algo.apply(x, y);
> > }
> >
> > private static class Unclamped
> > implements BiFunction<double[], double[], PolynomialSplineFunction> {
> > // ... current implementation ...
> > }
> >
> > private static class Clamped
> > implements BiFunction<double[], double[], PolynomialSplineFunction> {
> > // ... your proposed functionality ...
> > }
> >
> > // Commons functions ...
> > }
> > ---CUT---
>
> I like your idea of a factory method for "SplineInterpolator" but am not sure whether it will provide any benefit. The newly proposed "clamped" spline requires two additional boundary conditions specifying the slopes at each interpolation run and thus, simply overloading of the interpolate(...) function of interface UnivariateInterpolator to accept two additional parameters seems to be an attractive approach. Something like this:
>
> ---CUT---8<---
> public class SplineInterpolator implements UnivariateInterpolator {
>
> @Override
> public PolynomialSplineFunction interpolate(double[] x, double[] y) {
> // ... current default implementation of unclamped spline ...
> }
>
> public PolynomialSplineFunction interpolate(double[] x, double[] y, double startSlope, double endSlope) {
> // ... newly proposed clamped spline variant ...
> }
>
> // Commons functions ...
> }
> --->8---CUT---
>
> Is this still complying with the library design or will it break hearts? What do you think? If we wanted to specify the additional slope parameters in your factory method approach, these parameters would have to be passed initially during creation of the new BiFunction object and thus would require a re-creation of the whole object for each new interpolation run with just varying slope parameters. I'm not sure if this "overhead" is desired :D
Could you perhaps open a JIRA[1] report? You can then attach a patch,
with use cases, from which we can further discuss what API changes
would best handle them.
Regards,
Gilles
[1] https://issues.apache.org/jira/browse/MATH
>
> Thanks in advance!
> Michi
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org