Faster TimeSelector and SpacecraftHistory#543
Conversation
- Faster, using only 64bit precision - Add unit tests - Be consistent about tstart inclusive, stop exclusive. Signed-off-by: Israel Martinez <imc@umd.edu>
Codecov Report❌ Patch coverage is
... and 7 files with indirect coverage changes 🚀 New features to boost your workflow:
|
Still need to fix some unit tests Signed-off-by: Israel Martinez <imc@umd.edu>
Signed-off-by: Israel Martinez <imc@umd.edu>
Signed-off-by: Israel Martinez <imc@umd.edu>
Signed-off-by: Israel Martinez <imc@umd.edu>
Signed-off-by: Israel Martinez <imc@umd.edu>
Signed-off-by: Israel Martinez <imc@umd.edu>
jdbuhler
left a comment
There was a problem hiding this comment.
I don't have a good sense of how expensive the conversions between Time and Julian date are, but I assume they are way less painful than the TimeAxis operations. I'll have to benchmark the SpacecraftHistory after the changes to see what the overhead of select_interval() is.
I see that intervals_duration() now returns a value in days. Are there other places where we were used to using seconds as the typical time unit of orientation history but are now going to have to change?
|
@jdbuhler Thanks for checking. I used Julian days because that's what the underlying Time objects use. It just needs to sum jd1+jd2. Hopefully this sum is not much of an overhead, and it will allows us to still use Time for the inputs/outputs.
No code should assume units of intervals_duration(). The function only "promises" to return Quantity. If we find such instance using |
|
Thanks @jdbuhler ! |
TimeSelector:
I'll work on a similar trick (64bit precision) for SpacecraftHistory (I'll abandon histpy.TimeAxis in favor of a regular Axis since COSI doesn't need <1us precision).