Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

More flexible sob_terms #65

Open
mjlarson opened this issue Mar 5, 2021 · 0 comments
Open

More flexible sob_terms #65

mjlarson opened this issue Mar 5, 2021 · 0 comments
Labels
enhancement New feature or request

Comments

@mjlarson
Copy link
Collaborator

mjlarson commented Mar 5, 2021

At L126 of test_statistics.py, we have a construction like this:

for term in self._sob_terms:
      sob *= term(params, self._events)

Because the terms are treated independently and sequentially, this provides an incredible opportunity for us to provide flexibility in the test statistics. Imagine a rewrite that lets us do this:

events = self._events.copy()
for term in self._sob_terms:
      events, sob = term(params, events, sob)

This would allow us to do filtering of events during each term based on the current total sob. We could then have something like a TXS analysis that does this:

def txs_like_uniform(params, events, sob):
    # find the pair that gives the largest increase in sob, which
    # should correspond roughly to the most interesting window
    cumulative_sob = np.cumsum(np.log(sob))  # assumes time-sorted
    
    # potentially memory-intensive! Probably a better way to do this,
    # but haven't sunk much thought into it yet.
    increase = cumulative_sob[np.newaxis, :] - cumulative_sob[:, np.newaxis]
    indices = np.argwhere(increase == increase.max())
    
    result = np.zeros_like(sob)
    result[indices[0]:indicies[1]] = (sig_time_profile(events[indices[0]:indices[1]]) 
                                                         / bg_time_profile(events[indices[0]:indices[1]]))
    return events, sob*result

This wouldn't let you make the fancy TS/p vs time plots, but it could prevent you from needing to minimize independently for each pair. You could also incorporate the Erlang time stuff this way without any other changes to the code, since it would be able to filter events inside of the time likelihood term itself.

@mjlarson mjlarson added the enhancement New feature or request label Mar 5, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

1 participant