DDM-HMM / Future Interoperability with EmissionModels.jl

[rsenne]

Hi SSM team,

I wanted to put a few related things on your radar.

I recently posted a preprint using an HMM whose emission model is a Ratcliff-style DDM. The goal was to track how decision-making changes across the 24-hour cycle in rats performing a TAFC task. @kiante-fernandez reached out to me on Bluesky and asked why I did not use this package, and instead wrote my own DDM code here: https://github.com/depasquale-lab/DriftDiffusionModels.jl.

That is a fair question. The short answer is:

1. I had already written most of the code for this approach before realizing this package existed.
2. My application required a stimulus-coded DDM.

By stimulus coding, I mean that the drift is parameterized by its magnitude and then multiplied by a trial-specific sign depending on which side is correct:

$$v_{\mathrm{trial}} = s_{\mathrm{trial}} |v|, \qquad s_{\mathrm{trial}} \in \{-1, 1\}.$$

This differs from accuracy coding, where the upper bound is typically treated as “correct” and the lower bound as “incorrect.” In the stimulus-coded case, the bounds correspond to stimulus/choice identity, for example right versus left, and correctness is determined afterward from the trial condition.

I would prefer not to maintain a separate DDM implementation if the relevant functionality can live in, or be built cleanly around, this package. I would therefore be happy to help with one or more of the following:

1. Add a tutorial showing how to implement stimulus-coded DDMs in this framework, including how stimulus coding changes the interpretation of parameters relative to accuracy coding.
2. Add helper utilities to make stimulus-coded DDMs easier to specify.
3. Unrelated but could also add a “coherence DDM” tutorial/helper, where drift is parameterized as something like

$$v_i = s_i k c_i^\alpha,$$

where (c_i) is stimulus coherence, (k) is gain, (\alpha) controls the nonlinearity, and (s_i) is an optional stimulus-coding sign variable.

Separately, I am working on a package called EmissionModels.jl where the goal is for it to operate with HiddenMarkovModels.jl

In relation to the DDM-HMM model above, I would ideally like to add this package as a weak dependency and create an extension that makes it possible to reproduce the DDM-HMM workflow using this package for the DDM component. That way, this package gets the appropriate credit, and my maintenance burden is limited to the HMM/emission-model interface rather than maintaining a parallel DDM implementation.

Does this sound like something that would fit the scope of the package? I am happy to help with a tutorial, helper functions, or an extension, depending on what would be most useful. And if anyone is interested in starting a PR on this over in EmissionModels.jl, I would certainly not object. 😄

[itsdfish]

@rsenne, congrats on the pre-print. It looks like very interesting research.

One of the main goals of SSMs.jl is to provide basic SSMs that can be extended to more complex models, such as those you described. One way to accomplish your goal is to make a sub-type and add code to modulate the parameters as desired. The MLBA is one such example. Does that allow you to use SMMs.jl with your package, or is a different design required or preferred?

The tutorials you described would be great!

P.S. I cannot help much at the moment due to a hand/arm injury.

[rsenne]

@itsdfish thanks much appreciated!

Yes, this sounds good to me. I guess the main question is whether you would prefer the stimulus-coded DDM support and/or the coherence/nonlinear drift variant to live upstream here, or whether it would be cleaner for those pieces to live downstream as wrappers/helpers around this package. I think either route is fine. Most of what I would write would likely be fairly lightweight interface code rather than a separate DDM implementation.

Re: tutorials, I’d be happy to work on that. I may not be able to turn it around immediately, but I can put together something using real data for a more illustrative example.

And no worries at all about timing/helping — hope you heal up soon!

[kiante-fernandez]

Thanks for following up on this here, @rsenne ! I think a tutorial makes sense. For helper utilities such as stimulus coding, are you currently envisioning something only to accommodate DDM? My worry is that coding the stimuli when fitting parameters of 2-choice SSMs may be a specific application of something someone would want to use SSM.jl to support, but it is slightly outside the basic constructors set up by the package.
Although we might want to consider a module like a SSMExt.jl to sit in codebase if this grows into a substantial suite of extensions.
also linking nice tutorial that might help here:
https://lnccbrown.github.io/HSSM/tutorials/tutorial_stim_coding/

[rsenne]

think a tutorial makes sense

Great I'll get on it!

envisioning something only to accommodate DDM

At the moment yes, solely because that's my current use case but that doesn't mean it needs to be this way

something someone would want to use SSM.jl to support

I guess that's my thought as well--it seems like a very common use case so imo, the tutorials are a lower bound on what should probably be here, and perhaps, more ideally, some set of helpers that exist here could make this seamless. I think the big problem always is to what extent is something a new model vs. just an extension of pre-existing. I mean both cases I describe above could be handled in Turing or some other library but i guess it depends on what we want to ask a user to do

Thanks for the tutorial example. I'll try and mimic that style, its well written!