Palamedes Toolbox Forum

One thing that causes much confusion in my lab is the fact that beta (AKA 'slope') must be defined in logarithmic terms, whereas all other parameters (alpha, gamma and lambda – threshold, guess rate and lapse rate, respectively), are all taken 'as-is'. This means one has to be very careful when setting up priors for a PAL_AMPM<...> object not to enter beta in the wrong format.

The slope of a psychometric function is hugely dependent on the units of the intensity scale (e.g. there is a 1000-fold difference between ms and seconds for a time-based task, and for a lot of tasks, intensity values only range from 0-1). I wonder does anyone have a simple 'rule of thumb' for how to set an initial guess for beta when designing a psychophysical task? As a workaround I find myself entering the priorBetaRange using exp() as a way to view it in 'real' terms. But I wonder if I'm over-thinking this – perhaps it's simpler to always use the default priorBetaRange irrespective of the units of intensity measurement, since this covers a huge range of possible slope values?

What's your method for determining what to set priorBetaRange, or do you just leave things at the default setting? Note that I typically will 'marginalize' slope since I'm usually primarily interested in threshold, but I do want it to be a free parameter.

I notice that Psignifit takes a different approach to defining beta: rather than giving the value for the slope of the function, Psignifit instead defines it in terms of 'width', i.e. the width of the interval over which the psychometric function rises (typically from 0.1 to 0.9). This feels like a more intuitive way of defining this parameter than specifying the slope directly. Is there some way to define beta in this way in Palamedes? This might resolve the confusion a little by allowing it to be conceived of in terms that are easier to grasp.

There are a lot of factors that play into our choice of using log(beta) as the parameter to be estimated. One is that the likelihood function and posterior on beta is severely skewed. This has undesirable consequences. E.g., a grid for a posterior defined over raw beta values will have the bulk of the posterior sitting at the edge of the grid while still having the posterior ‘run off’ the grid at the other end. The likelihood function on log(beta) is much more symmetrical and is, even at a relatively small number of trials, typically well modeled by a normal distribution. The domain for beta (as well as that for width) has a boundary at 0 [unless you want negative beta or width to be meaningful (we don’t)], while the domain for log(beta) has no such boundary. A parameter space with a boundary is much more difficult for an MCMC sampler to navigate.
Ease of use and capability/flexibility of software do not get along. Unapologetically: when in conflict, ease of use has lower priority in the design of Palamedes compared to capability/flexibility. A rather unique (and, sadly, very much underused) capability of Palamedes is that it can fit multiple conditions and multiple observers simultaneously in one analysis with an option to specify parameters corresponding directly to interesting research questions. And an option to reduce model complexity by implementing reasonable assumptions. Examples here: https://www.palamedestoolbox.org/modelcomparisons.html and here: https://www.palamedestoolbox.org/downlo ... ss2019.pdf. The mechanics behind PAL_PFHB_fitModel’s flexibility regarding model specification/testing involve creating new parameters that are linear combinations of the raw parameters (the same thing that happens with contrasts in the context of ANOVA, for those more familiar with that). As mentioned above, the normal distribution is a good model for the prior and posterior of the log(beta) parameter. A very nice property of the normal distribution is that a linear combination of normally distributed random variables is itself a normally distributed variable. Linear combinations of beta or ‘width’, on the other hand, are a mess. Avoiding negative beta values would be very difficult and awkward if the parameters to be estimated are linear combinations of betas [instead of log(beta)]. All in all, for our purposes, log(beta) is the only sensible choice.
To find a sensible range for log(beta) to use in PAL_AMPM we suggest using something like this and trying different values for logBetaValueToTry:
myStimulusRange = [-4:.01:4];
logBetaValueToTry = 0;
plot(myStimulusRange,PAL_Logistic([0 10.^logBetaValueToTry 0 0],myStimulusRange));