Performance issues with DSCompiler.rebase

Hi,

I was testing Taylor map inversion in Hipparchus, and I found huge performance issues, e.g. very slow run times, even for small algebras (3 parameters, order 8, 165 coefficients).

I was able to trace down the bottleneck to DSCompiler.rebase, which is used for TaylorMap composition and inversion.

This example

    final DSFactory factory = new DSFactory(3, 8);

    final double mu = 1.0;
    final double a = 1.0;
    final double e = 0.5;
    final double dt = FastMath.PI / 2.0;

    final DerivativeStructure[] identity = {factory.variable(0, 0), factory.variable(1, 0)};

    final DerivativeStructure aDs = identity[0].add(a);
    final DerivativeStructure eDs = identity[1].add(e);

    final DerivativeStructure nDs = aDs.pow(3).reciprocal().multiply(mu).sqrt();
    final DerivativeStructure MDs = nDs.multiply(dt);

    final double E = KeplerianAnomalyUtility.ellipticMeanToEccentric(e, MDs.getReal());
    DerivativeStructure EDs = factory.variable(2, E);
    final DerivativeStructure fDs = kepler(EDs, eDs, MDs);

    final TaylorMap directMap =
        new TaylorMap(new double[3], new DerivativeStructure[] {identity[0], identity[1], fDs});
    final TaylorMap inverseMap = directMap.invert(new LUDecomposer(0.0));

    final TaylorMap zeroMap =
        new TaylorMap(
            new double[3],
            new DerivativeStructure[] {identity[0], identity[1], aDs.getField().getZero()});
    final TaylorMap evalMap = inverseMap.compose(zeroMap);

    final TaylorMap EMap =
        new TaylorMap(new double[3], new DerivativeStructure[] {identity[0], identity[1], EDs})
            .compose(evalMap);

    EDs = EMap.getFunction(2);

where kepler is simply

  private static <T extends CalculusFieldElement<T>> T kepler(final T E, final T e, final T M) {
    return E.subtract(e.multiply(E.sin())).subtract(M);
  }

takes about 25 seconds to run on my laptop.

I implemented exactly the same algorithm in Julia using GTPSA and in C++ using DACE. Both run almost instantaneously even at order 10.

Am I using TaylorMap wrong or is this known?

Thanks,
Alberto

We were not aware of this.
When this feature was added, our focus was to get correct results, we did not look at efficiency at all. We should probably do it now that the implementation is validated.

It seems that a long time is spent in the initialization of the MultivariateCompositionMapper. The same issue also affects the initialization of the DSCompiler, though it becomes noticeable at higher orders or larger number of parameters.

Could you open a bug report on our GitHub instance so we don’t forget about it?

Hi Luc,

Done: Poor performance of DSCompiler and rebaser initialization · Issue #423 · Hipparchus-Math/hipparchus · GitHub

Alberto