`memory` not stable between runs

[freemansw1]

It seems that memory, under certain conditions, is not stable/deterministic. I've put an example below. At some times, the value of particle at index 10 is 3, and at others it is 4. Both are reasonable choices, but it should always select one or the other, not both.

I've tried to dig into the source code with an eye to a PR, but frankly I'm struggling to understand how the memory module works. I'm happy to put some effort into a PR, but need a bit more insight there before putting one together.

I'm on an M2 Mac, Python 3.12.7, trackpy version 0.6.4.

import pandas as pd
import trackpy
import numpy as np

y_coords = [2, 3, 0, 10, 3, 1, 11, 4, 1, 2, 12, 5, 0]
x_coords = [3, 4, 4, 14, 4, 5, 15, 5, 2, 6, 16, 6, 1]
frame =    [2, 2, 2,  2, 3, 3,  3, 4, 4, 4,  4, 5, 5]

trackpy_df = pd.DataFrame({"y": y_coords, "x": x_coords, "frame": frame})
pred = trackpy.predict.NearestVelocityPredict(                
        initial_guess_positions=[[1,2],[4,5]],
        initial_guess_vels=[[1,1],[-1,-1]],
        pos_columns=['y', 'x'],
        span=1,
)
out = pred.link_df(trackpy_df, search_range = 1.8, memory=1, t_column="frame", neighbor_strategy="BTree",
                adaptive_step=None,
                adaptive_stop=None,
)

[nkeim]

@freemansw1 Thanks for providing the example!! You are right that this is likely to be very hard to solve. Long ago in #601 we decided to use un-ordered data structures whenever possible (specifically, set) to maximize performance, which meant that the trajectories would always be the same, but the particle IDs could change from run to run, even though that happens rarely in practice. The present issue might be related, but here the behavior feels more like a bug. Thankfully, degeneracy in linking is an edge case that is only encountered for e.g. integer coordinates.

Some questions/thoughts for discussion:

• What happens when you specify the neighbor_strategy='BTree' argument for linking? (There's a brief discussion in one of the tutorials).
• Could this be related to the use of prediction?
• With memory turned off, what does trackpy normally do when it encounters degeneracy in linking? E.g. a trajectory that appears to bifurcate perfectly.

[nkeim]

Re-reading the example code from @freemansw1 above, we already have neighbor_strategy="BTree". So, what if you remove this argument and use the default KDTree?

Assuming #782 is the same problem,

• it is not just with recent versions of Python, and not just on the Mac
• prediction is not required. (But an example without prediction could be very helpful!)

[SebastienTs]

Hello, any progress on this issue related to #782 ?

I have installed trackpy 0.7 and I still consistently observe slight variations between runs when memory is not set to 0.