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

Track metadata handling update #121

Merged
merged 2 commits into from
Aug 27, 2019

Conversation

sglvladi
Copy link
Collaborator

Following discussions with @sdhiscocks during Fusion in relation to #118, this pull request aims to solve the performance issues relating to reading metadata as follows:

  • Track objects will now maintain a copy of what should be the most up-to-date metadata at each time. Thus, reading metadata should be more efficient, at the expense of the additional memory required to store the metadata and a small computational overhead when new states are added to a track.
  • Metadata is updated automatically every time a new state is added to a track. This assumes (as we have done so far) that the last state in the list of states is also the latest one, i.e. the proposed approach will "fail" if states are added in an out-of-sequence manner.
  • Although not implemented here, this approach can be extended to allow users to edit and/or add to the track metadata (e.g. by implementing a Track.metadata() setter method).

As part of the above, a small correction has also been applied to StateMutableSequence to ensure that the states property is always a list after initialisation, even if a single State object is passed. Previously, a statement of the form track = Track(states=State(np.array([[1]]), timestamp=datetime.datetime.now()) would cause track.states to be a State object, rather than a list of length 1.

@sglvladi sglvladi requested a review from sdhiscocks July 10, 2019 23:30
# from all hypotheses are retained, but more likely
# hypotheses will over-write the metadata set by less likely
# ones.
for hypothesis in sorted(state.hypothesis, reverse=True):
Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not sure if this is correct. My (possibly wrong) intuition says that calling sorted on a MultipleHypothesis object should return a list of hypotheses, with the most likely being first. In the case of SingleProbabilityHypothesis this means that the hypothesis with highest probability would come first, while for SingleDistanceHypothesis the hypothesis with lowest distance would be first.. Thus, to have them sorted in reverse, I have included the argument reverse=True.

@mamoonrashid mamoonrashid self-assigned this Aug 13, 2019
Copy link
Member

@sdhiscocks sdhiscocks left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should probably also consider removal of states, and updating metadata. Might be worth making a note on the Track type for now if not implemented.

@@ -61,6 +61,9 @@ class StateMutableSequence(Type, MutableSequence):
def __init__(self, states=None, *args, **kwargs):
if states is None:
states = []
elif not isinstance(states, list):
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

May be better to check if states is a collections.abc.MutableSequence instead.

Copy link
Collaborator

@mamoonrashid mamoonrashid left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks fine to me.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants