PositionInfo, v0, traditional decoding, Is there a way to specify overlapping window size and overlap size

[shijiegu]

A critical validation of decoding is by the traditional overlapping window big window size Bayesian decoding with uniform prior.

In traditional decoding, the steps are

• upsample, a function of overlapping window size,
• smoothing a function of smoothing window size,

which are in principle, interchangeable in order with how it is processed now:

• smoothing first for which we specify window size
• then upsample so that the window sizes are of the target duration of time.

However, the correspondence can have minor problems which make them not exactly the same:

Use Ambrose et al., 2016 as an example, where they use 20ms window size, 10 ms overlapping window size.
This can be simply implemented as upsample to 100 Hz then apply moving window size of 2 bins (20ms).
My attempt to translate to our current pipeline is:

• smoothing with window 2 bins * size raw_position_sampling_freq / 100Hz. [In my case sampling_freq = 28Hz, so this smoothing only works with Gaussian kernel and does not work with simple square windows.]
• upsample to 100 Hz.

One way to allow the traditional position processing is to have an alternate calculate_position_info() in the make function of PositionInfo. I will implement this on my own if no other methods are available with the existing code.

[edeno]

Hi @shijiegu, there are no plans to make this available in spyglass as I don't think there's general user demand for it. The 20 ms with 10 ms overlap is just a different set of assumptions than the state space models. I would not necessarily call it a validation.

[shijiegu]

I think this is important

• because most of the prior literature and other labs' decoding approaches specify moving and overlapping window size. We should be able to use the most commonly used decoding parameters. Not necessarily validation. But replicating with old methods is valuable in providing convergent evidence.

• We should be reminded of the problems that come with the rigidity in designing the data base. The v0.PositionInfo parameter tables have a very specific set of parameters that can be used only with a specific downstream make() function. Parameter table designs like v0 spike sorting are more versatile.