translationalneuromodeling / tapas

TAPAS - Translational Algorithms for Psychiatry-Advancing Science
https://translationalneuromodeling.github.io/tapas/
GNU General Public License v3.0
217 stars 90 forks source link

Questions about fitting real response data in HGF #27

Closed ghost closed 3 years ago

ghost commented 6 years ago

Dear Dr. Mathys,

Currently, I am trying to implement HGF models in my experiment. I’ve gone through the HGF toolbox following your very helpful manual and demo.   But I have a problem when I try to fit the model using the real response, and I am wondering whether you could give me some help, as you mentioned less in the manual about using real binary response.   My task is a prediction task given a prior cue, which is similar with the task in Iglesias et al 2013, Neuron. I am using both perceptual and response models to simulate the trial-wise trajectories, i.e., belief or prediction error, directly as follows: est = tapas_fitModel (y,...                          u,...                          'tapas_hgf_binary_config',...                          'tapas_unitsq_sgm_config',...                          'tapas_quasinewton_optim_config'); 

%% y is the real response vector, and u is the stimulus input (contingency space: 0 and 1).

To simplify the questions, first of all, I am wondering whether what I am doing is correct or not by simply adding the response y in the tapas_fitModel function? If not, what should be the correct procedure to fit the real response data?
   Thanks in advance, Best, Bin

chmathys commented 6 years ago

Dear Bin,

At first sight, it looks as if you’re doing everything all right. The trajectory moves in the direction of the input (green dot), as it should. This is because the model assumes belief updates to be driven by inputs. It seems you expected it to move in the direction of the response (orange dot), but that is not the case.

Best wishes, Christoph

On 17 September 2018 at 4:22:14 pm, binwang87828 (notifications@github.com) wrote:

Dear Dr. Mathys,

Currently, I am trying to implement HGF models in my experiment. I’ve gone through the HGF toolbox following your very helpful manual and demo.

But I have a problem when I try to fit the model using the real response, and I am wondering whether you could give me some help, as you mentioned less in the manual about using real binary response.

My task is a prediction task given a prior cue, which is similar with the task in Iglesias et al 2013, Neuron. I am using both perceptual and response models to simulate the trial-wise trajectories, i.e., belief or prediction error, directly as follows: est = tapas_fitModel (y,... u,... 'tapas_hgf_binary_config',... 'tapas_unitsq_sgm_config',... 'tapas_quasinewton_optim_config');

%% y is the real response vector, and u is the stimulus input (contingency space: 0 and 1).

To simplify the questions, first of all, I am wondering whether what I am doing is correct or not by simply adding the response y in the tapas_fitModel function? If not, what should be the correct procedure to fit the real response data?

Thanks in advance, Best, Bin

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/translationalneuromodeling/tapas/issues/27, or mute the thread https://github.com/notifications/unsubscribe-auth/AS6G_bkvAJNBG76LLsnNzcOkT2xD46Bfks5ub7AWgaJpZM4WsBkF .

ghost commented 6 years ago

Dear Dr. Mathys,

Thanks for your quick replying.

If the belief updates are driven only by inputs, then how about the prediction error da1(k)? The prediction error da1(k) is calculated between the actual input (0,1) and the prediction before experiencing the trial outcome (mu1hat(k)). This mu1hat(k) should be largely related with the response rather than the stimulus input, because the response is the consequence of this prediction.

But from the model, I got the prediction error (da1(k)) mainly driven by the stimulus input as well, and even I assume they are totally random responses, the prediction error doesn't change (see figure). Does that make sense? Or I am wondering whether there is any parameter from the model that can represent the trial-wise change of the choice probability? figure2

Thank you very much again

Best, Bin

chmathys commented 6 years ago

Dear Bin,

As you say correctly, the prediction error that drives belief updates depends on the input, not the response. Whether this makes sense in your context is something I cannot decide for you. You can build models where learning is driven by the learner’s own responses (and we have done that, e.g, here: http://science.sciencemag.org/content/357/6351/596), but these are models tailored to very specific situations. Normally, the assumption that learning is driven by inputs makes the most sense.

Best wishes, Chris

On 17 September 2018 at 5:30:37 pm, binwang87828 (notifications@github.com) wrote:

Dear Dr. Mathys,

Thanks for your quick replying.

If the belief updates are driven only by inputs, then how about the prediction error da1(k)? The prediction error da1(k) is calculated between the actual input (0,1) and the prediction before experiencing the trial outcome (mu1hat(k)). This mu1hat(k) should be largely related with the response rather than the stimulus input, because the response is the consequence of this prediction.

But from the model, I got the prediction error (da1(k)) mainly driven by the stimulus input as well, and even I assume they are totally random responses, the prediction error doesn't change (see figure). Does that make sense? Or I am wondering whether there is any parameter from the model that can represent the trial-wise change of the choice probability? [image: figure2] https://user-images.githubusercontent.com/43343685/45632661-26010400-ba9e-11e8-98f7-49786f66424c.PNG

Thank you very much again

Best, Bin

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/translationalneuromodeling/tapas/issues/27#issuecomment-422061662, or mute the thread https://github.com/notifications/unsubscribe-auth/AS6G_dNki3N4a0gSt-A1O93eyHxc3zswks5ub8AbgaJpZM4WsBkF .

ghost commented 6 years ago

Dear Dr. Mathys,

Thank you so much for your kind answer. I realized that the choice prediction error is what I want, rather than the outcome prediction error:)

And I have one more question about the positive or negative values of the prediction errors (i.e., precision-weighted PE or choice PE). When I perform the parametric modulation using these parameters in SPM, should I use the absolute value or the positive/negative value of them?

Thanks again, Best,

chmathys commented 6 years ago

Dear Bin,

Whether to use the absolute value of the prediction error or not depends on the substantive question you are addressing with your fMRI study. Either can be appropriate.

Best wishes, Chris

On 25 September 2018 at 5:39:18 pm, binwang87828 (notifications@github.com) wrote:

Dear Dr. Mathys,

Thank you so much for your kind answer. I realized that the choice prediction error is what I want, rather than the outcome prediction error:)

And I have one more question about the positive or negative values of the prediction errors (i.e., precision-weighted PE or choice PE). When I perform the parametric modulation using these parameters in SPM, should I use the absolute value or the positive/negative value of them?

Thanks again, Best,

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/translationalneuromodeling/tapas/issues/27#issuecomment-424391265, or mute the thread https://github.com/notifications/unsubscribe-auth/AS6G_Qsmg5M5cbpqey631cx7-zn7txjyks5uek4jgaJpZM4WsBkF .

adonda10 commented 5 years ago

Dear Chris,

a related question to using the HGF with real responses and input:

(Simple context of the binary perceptual model and unit square sigmoid as response model) Do we use at all the posterior means on some parameters from the perceptual model (e.g. omegas?)

In three of our participants using the real responses + input for the combined response+perceptual model we obtain a posterior mean on the omega (level2) that is very different (-8) than the prior value (-3 ). Also in those three participants the HGF variables look quite flat (mu(2) and implied learning rate(1)). If we fix the omegas to the posterior means from the perceptual model, is that valid? Or should we go with the Bayes-optimal parameter estimates from the combined model, even if the time course of HGF variables looks flat?

The behaviour seems ok, though (see attached figures: perceptual only / combined real response + perceptual)

Thanks so much in advance

Best

A.Donda

COMBINED: combined_response_perceptual PERCEPTUAL ONLY: perceptual

chmathys commented 5 years ago

Dear A.Donda,

In your top plot, everything seems fine. In the bottom plot, the omega_2 value is indeed very low. I don’t know exactly what you mean by fixing the omegas to the posterior means. Each subject has its own posterior mean, and as you say, some of these may be somewhat implausibly low. I wouldn’t proceed by fixing them, but rather tighten your prior by reducing the prior variance in the config file.

Best wishes, Chris

On 5 December 2018 at 7:48:14 pm, adonda10 (notifications@github.com) wrote:

Dear Chris,

a related question to using the HGF with real responses and input:

(Simple context of the binary perceptual model and unit square sigmoid as response model) Do we use at all the posterior means on some parameters from the perceptual model (e.g. omegas?)

In three of our participants using the real responses + input for the combined response+perceptual model we obtain posterior means on the omega (level2) that is very different (-8), than the prior value (-3 ). Also and in those three participants the HGF variables look quite flat (mu(2) and implied learning rate(1)). If we fix the omegas to the posterior means from the perceptual model, is that valid? Or should we go with the Bayes-optimal parameter estimates from the combined model, even if the time course of HGF variables looks flat?

The behaviour seems ok, though (see attached figures: perceptual only / combined real response + perceptual)

Thanks so much in advance

Best

A.Donda

[image: perceptual] https://user-images.githubusercontent.com/45637839/49536399-4a5ec680-f8be-11e8-994a-12ceb8397806.png [image: combined_response_perceptual] https://user-images.githubusercontent.com/45637839/49536404-4f237a80-f8be-11e8-92e8-c9e6ce2fd596.png

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/translationalneuromodeling/tapas/issues/27#issuecomment-444597935, or mute the thread https://github.com/notifications/unsubscribe-auth/AS6G_fLN-JOABeIZ6nsnh-9nR-jzxB1iks5u2BTugaJpZM4WsBkF .

adonda10 commented 5 years ago

Dear Chris,

thanks so much. That is helpful.

I guess that the main question we have is (thanks in advance!):

Why is it valid for us to decide how much variance we accept in the priors for the omegas (omega2 = -3, var = 1? or 16?). Is it ok to decide that omega2 = -8 is not valid? But then, why did the HGF find that as posterior mean for omega2?

Thanks so much!

Best wishes, Maria

chmathys commented 5 years ago

Dear Maria,

Whether a prior is valid depends on whether it conforms to the background knowledge you have and/or leads to posterior predictive distributions showing the same patterns as the real data. If you know that trajectories implied by omega2 = -8 are unrealistic, then you are within your rights to choose a prior that effectively excludes such low values.

A model always consists of a likelihood and a prior. Whenever the prior is not specified explicitly, it is still there, albeit implicitly, and it is never uninformative, so there is no way around worrying about its effect. In the end, you will have to justify your whole model on the basis of the predictions it makes. This means that you are justified in choosing a prior that, when doing posterior predictive simulations, captures your subjects’ behaviour more realistically than another - even if it reduces your model evidence.

Best wishes, Chris

On 6 December 2018 at 5:36:28 pm, adonda10 (notifications@github.com) wrote:

Dear Chris,

thanks so much. That is helpful.

I guess that the main question we have is (thanks in advance!):

Why is it valid for us to decide how much variance we accept in the priors for the omegas (omega2 = -3, var = 1? or 16?). Is it ok to decide that omega2 = -8 is not valid? But then, why did the HGF find that as posterior mean for omega2?

Thanks so much!

Best wishes, Maria

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/translationalneuromodeling/tapas/issues/27#issuecomment-444937708, or mute the thread https://github.com/notifications/unsubscribe-auth/AS6G_W1WYwfuxM35Zy9WBWZmo3iYComaks5u2UeLgaJpZM4WsBkF .

adonda10 commented 5 years ago

Fantastic,

thanks so much.

Best wishes

ianthe00 commented 5 years ago

Dear Dr. Mathys,

working now with the continuous response model (gaussian_obs), and 2 levels (mu1, mu2), everything looks fine and the LME is good as well. However we often get mu2 (volatility) values that drop from an initial value of 1 to negative values (e.g. -3 up to -10). This can be changed by constraining omega2. However, we wonder, whether this is a big issue. Is it a problem to get negative mu2 values? Thanks in advance

Best, Ianthe

hgf_continuous

chmathys commented 5 years ago

Dear Adonda,

No, that is not a problem. Strictly speaking these are log-volatility measures, so the volatility itself is always positive.

Best wishes, Chris

On 17 January 2019 at 10:05:52 pm, ianthe00 (notifications@github.com) wrote:

Dear Dr. Mathys,

working now with the continuous response model (gaussian_obs), and 2 levels (mu1, mu2), everything looks fine and the LME is good as well. However we often get mu2 (volatility) values that drop from an initial value of 1 to negative values (e.g. -3 up to -10). This can be changed by constraining omega2. However, we wonder, whether this is a big issue. Is it a problem to get negative mu2 values? Thanks in advance

Best, Adonda

[image: hgf_continuous] https://user-images.githubusercontent.com/24864318/51348492-cdb52f80-1a9a-11e9-9342-d560ca047352.png

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/translationalneuromodeling/tapas/issues/27#issuecomment-455330365, or mute the thread https://github.com/notifications/unsubscribe-auth/AS6G_QwgBdTuWCJq3OYbw2rC45mqJGEHks5vEOSJgaJpZM4WsBkF .

ianthe00 commented 5 years ago

True, thanks so much.

Ianthe

ianthe00 commented 3 years ago

Dear Chris,

on December 2018 you advised to "tighten your prior [on the omegas] by reducing the prior variance in the config file", based on the binary categorical model results we shared.

Our query now is: If a broad variance on the omegas works well for most participants (e.g. omsa [ 4 4]), except in 2-3 participants in which we would need to constraint the prior on the omegas, what is the common approach you would advise to follow? (A) Reduce the variance on the omegas for all participants? (B) Or just for those 2-3 and report it in the table of priors in a publication?

Thanks Best, Antonia

chmathys commented 3 years ago

Dear Antonia,

Always use the same priors for all participants. A different prior means a different model. You can’t compare parameters estimated with different priors because even though they still have the same names, they are parameters of a different model.

The danger with making the priors too tight is that you might lose the ability to detect differences between your participants. If that doesn’t happen, go with the tighter priors for all participants. Otherwise, just report the situation as it is: you get good results for all but a few participants with your preferred prior setting, but there are difficulties fitting some datasets. That’s normal. Perhaps you can detect something unusual in the behaviour of the participants that are hard to fit. If you do, report also that.

Since 2018, the enhanced HGF models (ehgf, ehgf_binary, ehgf_jget) have entered the toolbox. You may also want to try those.

Best, Chris On 16 Mar 2021, 9:06 PM +0100, ianthe00 @.***>, wrote:

Dear Chris, on December 2018 you advised to "tighten your prior [on the omegas] by reducing the prior variance in the config file", based on the binary categorical model results we shared. Our query now is: If a broad variance on the omegas works well for most participants (e.g. omsa [ 4 4]), except in 2-3 participants in which we would need to constraint the prior on the omegas, what is the common approach you would advise to follow? (A) Reduce the variance on the omegas for all participants? (B) Or just for those 2-3 and report it in the table of priors in a publication? Thanks Best, Antonia — You are receiving this because you commented. Reply to this email directly, view it on GitHub, or unsubscribe.

ianthe00 commented 3 years ago

Dear Chris,

thank you for the quick & insightful reply. I absolutely agree with you and (B) is not a valid option as all participants should have the same priors. We just can't seem to understand why the HGF model we're using (tapas_ehgf_binary, version 6.0.0) breaks down after a few trials in 2-3 participants with very good behavioural performance (see pic below: they learn quite well, but the bottom plot learning rate steps in black are too high).

Thanks. Yes, we're concerned that reducing the prior variances on the omegas for everybody will be too restrictive to properly estimate parameters and observe effects. But we will explore this further.

We will also try other changes in the priors. Otherwise, as you suggest, we will just report that those broad omega priors don't work well in 2-3 people and speculate why that may be - then exclude those participants from the results.

Thanks so much again for the toolbox and for maintaining this site!

Best Antonia

untitled

ianthe00 commented 3 years ago

Dear Chris,

after trying many things to try and get the ehgf_binary model to not diverge in the case (figure) we shared in the previous message, we haven't succeeded. We could exclude this (and other) participants from the final analysis, however we wonder whether you could share some insight?

Changing the prior variances on the omegas does not change much this time (as opposed to our experience with the old hgf_binary).

We checked everything, code, simulations, config file and could not get the ehgf_binary model to work for the participant (and others) shown above.

Any insight into how to avoid that the ehgf_binary model explodes in some cases would be greatly appreciated.

Thanks in advance

Best, Antonia

chmathys commented 3 years ago

Dear Antonia - could you please send me the problematic datasets by email? I’ll see what I can do.

Best wishes, Chris On 24 Mar 2021, 8:25 PM +0100, ianthe00 @.***>, wrote:

Dear Chris, after trying many things to try and get the ehgf_binary model to not diverge in the case (figure) we shared in the previous message, we haven't succeeded. We could exclude this (and other) participants from the final analysis, however we wonder whether you could share some insight? Changing the prior variances on the omegas does not change much this time (as opposed to our experience with the old hgf_binary).

• We tried to estimate omega2 and omega3 from simulated data and omega2 recovers well, omega3 does not (in our attempts). • So then we considered fixing omega3, but keeping kappa(1) free (in addition to omega2 and resp model zeta). However, the model still diverges in the participant example shown above. • • We also kept free omega2, omega3, kappa(1), zeta, and used broad / narrow prior distributions, but this didn't fix the participant model fit as shown above.

We checked everything, code, simulations, config file and could not get the ehgf_binary model to work for the participant (and others) shown above. Any insight into how to avoid that the ehgf_binary model explodes in some cases would be greatly appreciated. Thanks in advance Best, Antonia — You are receiving this because you commented. Reply to this email directly, view it on GitHub, or unsubscribe.