Nice work on the new features, especially the Brouwer-Lyddane implementation.
Question about the Duration and MedianDate classes. I would guess that duration is computed as d = t1-t0, but the class seems to implement d = 0.5 (t1-t0). Similarly I would think MedianDate would be implemented as tm = 0.5 (t1 + t0) but is seems to be implemented as tm = t1 + t0. Am I missing a factor of 1/2 or is the factor misplaced in the implementation?
Has there been any testing to show the performance improvements of using DoubleArrayDictionary? I would be surprised if there is a significant performance increase relative to HashMap or TreeMap, as there is no autoboxing avoided and Strings cache their hashcodes. But I am often surprised.
This works the other way round. When using MedianDate and Duration, we consider that the independent variables are the median date and the duration and that start and stop dates are dependent variables. Then when one moves the median date say by one second in the future but keep the duration constant, this is equivalent to move both start and stop dates one second in the future. Moving a start date in the future means we remove a one second acceleration at start, and moving a stop date in the future means we add one second acceleration at stop, but the sign correction is already considered in the startTime and stopTime derivatives performed by other state providers, hence the computation. There is a similar trick for duration.
The expected improvements were mainly on memory rather than run time (default size for HashMap is 16 for example) because we generate a huge number of SpacecraftState, including intermediate ones when adding attitude, and then states/derivatives during propagation. Another point that was interesting (but was not the main design goal) is that the dedicated toString method that displays additional state name and size proved useful when debugging. I agree I should have done some performance tests, and also some memory consumption tests. I did not do that, I’m sorry.
I also did not check when I switched from triangular arrays in major row order to flat arrays in major column order backward from high order to low order in gravity fields (to match Holmes-Featherstone loops). Here again I should have done that, and here again performance gains are not expected to be really significant (except perhaps when high degree and order fields are used).
I am probably not demanding enough with myself when developing
