As I put my hands again on the Python wrapper, I encountered some errors I had never seen.
Basically, I use LinearInterpolator with Field data, let’s say Gradient. When I use the value method of the result, there is an exception when Arrays.binarysearch is called, saying that it can’t cast Gradient as a Comparable. So the problem is that it’s not able to form inequalities between the input and the spline knots, making it unable to choose a polynomial. Any idea on how to make it work? I tried casting first to CalculusFieldElement to no avail. @petrus.hyvonen?
Edit: I kinda fear it’s a problem with Java, but then I don’t understand how to use Field splines
I confirm that the problem does not come from the Python wrapper, it is present in Java.
Below is a code snippet to reproduce it. Am I doing something wrong or is this a bug?
final GradientField field = GradientField.getField(2);
final Gradient time1 = field.getZero().add(1.0);
final Gradient time2 = field.getZero().add(2.0);
final Gradient time3 = field.getZero().add(3.0);
final Gradient x1 = field.getZero().add(4.0);
final Gradient x2 = field.getZero().add(-2.0);
final Gradient x3 = field.getZero().add(0.0);
final Gradient[] times = new Gradient[] {time1, time2, time3};
final Gradient[] xs = new Gradient[] {x1, x2, x3};
final FieldPolynomialSplineFunction<Gradient> spline = new LinearInterpolator().interpolate(times, xs);
spline.value(field.getZero().add(1.5));
Indeed, there is a bug here. It works in the unit tests because tests use Decimal64/Binary64 which implement Comparable interface.
I don’t know if the solution is:
Use real values instead of field values for the following line: int i = Arrays.binarySearch(knots, v);. The return value is an int, so there is no problem with the derivatives.
Let CalculusFieldElement implement Comparable. More complicated but very interesting!
As far as DerivativeStructure and the like are concerned, you can use (inverse) lexicographical order. Berz uses it in one of his original papers on the differential algebra but I can’t put my hands on it anymore. It’s quite intuitive for in the univariate case, less so in multivariate because basically you need to decide if some unknowns are larger than others.
You can use the same kind of things for complex numbers actually (this is what is done in Numpy for instance), but we can agree that it’s arbitrary.
Anyway in our case for splines, comparing via getReal() would make sense I think and requires very little coding compared to extending Comparable. However the latter should probably be explored in the future.