Closed sathanas31 closed 1 month ago
Hi, I am not so familiar with the KDE support components of flarestack
so feel free to move on without my approval, but I will try to take a look nevertheless in the upcoming days.
About unwanted randomisations, my guess is that somewhere we use a RNG that is not appropriately set up with the provided seed. If I remember correctly, we still use a lot of np.random.*
calls instead of creating an instance of default_rng()
, which would be the recommended approach.
Could you check why mypy and black are still failing, @sathanas31 ?
TL;DR Improve runtime for gamma-independent KDE cases used, by not evaluating the splines for all gamma points when creating spatial cache
Main changes
Introduce optional gamma-dependency in
signal_spatial
ofNorthernTracksKDE
signal_spatial
with gamma = Nonespatial_pdf_dict
, so this case is also gamma-independent andsignal_spatial
is called with gamma = None. If gamma not specified by user, thensignal_spatial
is gamma-dependentApply changes in
StdMatrixKDEEnabledLLH
signal_pdf
method has now optional gamma-dependence,joint_SoB
so we avoid having the same spline evaluation for all the gamma support points.Miscellaneous Change the scale in
ResultsHandler
in order to avoid error when using "fixed_scale"Testing For some (unknown) reason, the full dataset passed in the llh is randomized even though the configuration is the same: no Poission injection, same seed, same catalog & dataset, 1 local trial for fixed scale. If dataset is saved and used for all testing trials then results are identical for main and branch