finmath/finmath-lib

TimeDiscretization inconsistency

delreluca opened this issue · 1 comments

TimeDiscretization states that it will round times to a certain tick size in the Javadoc. This is done inconsistently between the different constructors:

The ellipsis/double array constructor will not round the given times to tick size.
The other constructors (boxed Double array, Set and ArrayList) will do that.

All constructors fail to remove duplicates though.

A unit test for the missing rounding can look like this:

public class TimeDiscretizationTest {

    private static double getHalfTickMore(double a) {
        return a + 0.5 / (365.0 * 24.0);
    }

    @Test
    public void testTickRoundingOfUnboxedArrayConstruction() {

        double a = 4.2;
        double identicalToA = getHalfTickMore(a);

        TimeDiscretization discretization = new TimeDiscretization(a, identicalToA);

        Assert.assertEquals(discretization.getTime(0), discretization.getTime(1), 0.0);
    }

    @Test
    public void testTickRoundingOfBoxedArrayConstruction() {

        double a = 4.2;
        double identicalToA = getHalfTickMore(a);

        TimeDiscretization discretization = new TimeDiscretization(new Double[] { a, identicalToA});

        Assert.assertEquals(discretization.getTime(0), discretization.getTime(1), 0.0);
    }
}

There is another inconsistency: The interface Set<> is accepted but List<> is not, although its implementation ArrayList<> is.

I will try and perform a pull request with the following fixes and unit tests soon:

  • The tests above should all pass.
  • In addition, in the above tests discretization should only contain 1 time point.
  • Any Iterable<> should be accepted

Here are some other features that might be useful:

  • Add methods for union and intersection to the TimeDiscretizationInterface as these are actually quite common operations (the SDE process time discretization must contain the LIBOR period discretization in the LIBORMarketModel for example). The implementation of this for TimeDiscretization would depend on the correct rounding and duplicate removal.
  • I have no personal stake in this but control of the tick size might be useful for people operating on high frequencies. In this case I propose adding the tick size to the interface and having unions/intersections use the coarser tick size.
  • Windowing a time discretization (intersecting with an interval) might also be a useful operation.

Fixed by PR #60