Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Fix min energy handling in SpectrumEnergyGrouper #1210
@jjlk - Thanks for improving these tests!
In test_edges you take a
How about deleting the
Apart from that, I still don't get what's up with
And then for the line where you have
I think that's a reasonable expectation, maybe we can / should change the behaviour!
But it is relying on a float number comparison: 1 TeV is at the exact edge, and what's happening is that
For me, this is not a quick fix to do. I would have to take an hour or two, fully understand the problem and code again, and then think about what a good solution is. It could be just a change in logic and addition of unit-tests for the lower-level methods I linked to in this comment to make them well-understood and well-behaved, or it could be re-thinking the high-level interface: it's inherently tricky to take multiple float
@jjlk - Can you do this deep dive into the spectrum energy grouping and start to make it better by adding lower-level tests that show the current behaviour (and then feel free to change it if there are bugs or it's non-intuitive)? If yes, great! If no, assign to me and I'll try to find time next week.
Basically it should be possible to write a lower-level test (using the lower-level classes, not the grouper) with ~ 5 lines of code that just uses one energy bin and results in "underflow" where you expect "normal"?
@jjlk - You think this is a bug and that behaviour should change, no? Can you spot a place where to make a change to get more sensible behaviour?
I think that we want this to work, no? If my data is binned as [0.1, 0.2, 0.3...,1] TeV and that I want flux points for energy bins corresponding to [0.2, 0.3...,0.9] TeV, the current code remove the lowest and highest bin. Which is shitty no? This use case exists, for example, when someone wants to select bins according to sane criteria, e.g., minimal excess, minimal signifiance, systematics on background, ETC!!!
Do you agree?
I'm not sure it's easy to deal with that in the current implmentation. If I found a dirty solution, are you okay to 'pythoned' it?
What do you think?
@jjlk - Thanks!
I'll have a look at this today and probably do some more coding / cleanup for the energy grouping. At least there's this one fail: https://travis-ci.org/gammapy/gammapy/jobs/304390957#L2667
Hi @cdeil ,
Concerning the failling test,
There is a test to assert the value of the first flux point for the energy binning:
The first bin starts at 1.13646366639 TeV. The binning for the spectral extraction is (keeping values above 1 TeV and 55 TeV):
After the correction of the bug, the output of the flux points gives:
So the test was also suffering of the bug.
Oké to update the value?
@jjlk - Yes!
Is the behaviour at the high end as you expect? I.e. is
Didn't we discuss that the behaviour should be to only look to the left edge of the "fin bin" when assigning to flux point energy bins? Is this how it works in the middle already in this case?
I don't really have an opinion what to do at the upper end, i.e. whether to keep or remove the last "fine bin". This is just a question to you @jjlk to please review this test while you update the numbers (and to maybe leave a one-line comment saying what is going on if it's non-obvious like with the last point).
Especially I think that we should write grouping tests like this, where it's clear just from looking at the
What's missing is to reduce and rewrite the many methods that apply emin / emax or energy binnings to much fewer / simpler code (and to remove the