passing posterior probs of a dichotomous node to a probebility weigh node

[PCherubini]

Hello,
in our studies we often need to distort accurate probability estimates to match actual estimates made by subjects. In the attached example (a small subset extracted from a larger hierarchical model) the "linlog" (linear-to-log-odds) equation in the network properties is one of many possible distorting functions. The problem is... what I can now do with genie is graph A: "assuming" that what the subject is estimating is her level of accuracy p(sbj response|stimulus), and distorting it ("confidence" node). But in so doing I'm knowingly imposing to the subject a "fallacy of the inverse" error. What I should actually do is graph B: the subject confidence should be a distortion of p(stimulus|sbj response). But in order to do so I should pass to the confidence node the probabilities of the two states of the stimulus node (or - equivalently - the mean value of the node), and not the node state values (which are 0 or 1). Please also notice that the nodes in the example are equations, but all of them will be discretized, because when running the (full) net with subject data we need backward updating from the subjects confidence responses to the most probable probability of the stimulus... and when you discretize the confidence node according to the stimulus node of course the two input values are 0 and 1, and the distorting function output for those values are...0 and 1). I could use a "probability of the stimulus" multilevel node instead of the dichotomic "stimulus", but the meaning would be utterly different: Its result would be the posterior estimate of the most liklely baserate of the stimuli given the subject response, and not the posterior probability of a stimulus being present/absent given the subject response. I also tried to do it in smile (the whole net is run through smile in iterative cycles), and it is easy to take the probability of the stimulus states and compute the linlog confidence, but I can't find any way to make it affect the update of the stimulus probabilities. Any suggestions? Thx

example prob weight.xdsl

(14.81 KiB) Downloaded 33 times

[marek [BayesFusion]]

I may be understanding your description incorrectly (I had a hard time connecting the models to your description, as you are using different symbols -- it may be obvious for you but it is not for me :-)), but is your question related to being able to use probability distributions as arguments to functions in other nodes? If so, I'm afraid this is impossible in GeNIe and SMILE. Being able to use the results in calculating the results would be problematic semantically. Am I understanding your question correctly?
Cheers,

Marek

[PCherubini]

Hi Marek, I apologize for obscurity in the previous post. I think you grasped it correctly but, to be sure, I try with a more neat example. In the attached mininet there is a stimulus (.5 priors), a human detector with accuracy .9 (it is a point prob in the example, but please consider that it would be a global mean, and accuracy might vary depending on the difficulty of the incoming stimulus). The detector must also estimate the probability of the stimulus (node "estimate of pStimulus by human detector"). In this example I use a simple one-parameter function (a famous one used by Kahneman and Tversky 1992, even though not the best one; it is in the functions slot of the network and at p. 132 of the attached paper, even though I renamed gamma their beta parameter) for weighting the true probability of the stimulus and obtaining the distorted estimate.
If the detector says "yes, the stimulus is present", the actual pStimulus of course rises to .9. The estimate should be around .71 (with gamma =.61 as I set). Of course, though, the mean value of the node is not .71 but .5, because the stimulus node does not pass its mean (.9), but passes "1 with p .9 and 0 with p .1": since the probability weight formula output 1 for p=1, and 0 for p=0, the result is .5.
Of course I agree with the proposition "if the probability estimate by the human detector it is a distortion of the actual probability estimate, why should it modify the actual probability estimate?". But then: imagine the more general case where I know only the human mean accuracy (with actual accuracy varying through different trials), and a mean baserate of the stimulus (pStimulus not always .5), and the mean parameters of the human distortion of probabilities. The data are: 1) the human categorical response, 2) the human probability estimate (commonly known as "confidence"). then both data could pinpoint the most probable actual probability of the stimulus. But we can't do that in GeNIe, because the stimulus node can't pass its probability array? confirm? Thx

clearer example.xdsl

(2.8 KiB) Downloaded 28 times

On_the_Shape_of_the_Probability_Weightin.pdf

(240.66 KiB) Downloaded 26 times

[marek [BayesFusion]]

I'd like to confirm that you cannot pass posterior/marginal probability distributions as arguments to other nodes in a model. The main reason for this design decision is that we make a clear distinction between definitions/domains and values. Inference algorithms calculate values (including probability distributions over them) from definitions. We have never felt the need to violate this decision. Is there any Bayesian network software that allows for this?
Cheers,

Marek

[PCherubini]

I understand your very sensible design choice! I'll stay with linking human distortions to accuracy nodes, instead of linking them to dichotomic stimulus nodes. As for your question... agenarisk and netica do not allow passing distributions, same as GeNIe. I do not know anything about the crazily expensive products by Bayesia, they are far from my budget ;-). I'm very happy with GeNIe, and I will never thank you guys enough for keeping it free for educational and research academic purposes!

[marek [BayesFusion]]

Thank you for your kind words. We hear a lot of good things about GeNIe and SMILE from their users. They are in no way inferior in their functionality, speed, and reliability to the "crazily expensive" software and are only getting better with time.
Cheers,

Marek