Error returned when I do mediation analysis with very small numbers
When I do mediation analysis with one of the columns (for the Mediator variable) having numbers around as small as the following:
0.000798458
I get an error and no result returned. When I multiply all the numbers by 1000 to create a new column, where all numbers are greater than 1, and I use this column instead, it all works ok. So, this is a workaround. But can it really be the case that everything gets thrown by small numbers (which aren't really that small)?
A different workaround, which works, is to tick the “Standardized estimates” box.
But are my workarounds valid? Are the results I get with this workaround(s) trustworthy?
The better thing would be that JASP mediation analysis could just work with my raw numbers. Do you know why it cannot? Is my estimation that it is because the numbers are too small correct?
Actually, the whole column is thus:
0.000798458
0.000771
0.001164574
0.001319925
0.001804233
0.002713422
0.002418353
0.004975053
0.003740752
0.005934723
0.006377
0.010447035
Comments
Just bumping this. Because I think it is important, because it perhaps speaks to a fundamental problem in JASP?
How could I run this mediation analysis in the underlying R, to try and triangulate where this error lies?
If anyone wants to see if the underlying R can handle a column of small numbers (as above) for mediation analysis, please let me/us know by posting here.
In JASP, as stated above, I think I have found a work-around. BUT does this work-around give valid results?
Hi Michael_Jasper,
Could you please attach a screenshot of the error message you get?
Best,
Michael
Just to add, which I should have said before - this problem occurs when I use BOOTSTRAP.
The error message:
----------------------------------
This analysis terminated unexpectedly.
Error in chol.default(S): the leading minor of order 3 is not positive definite
Stack trace
lavaan(slotOptions = lavoptions, slotParTable = lavpartable, slotModel = model.boot, slotSampleStats = bootSampleStats, slotData = lavdata)
lav_model_vcov(lavmodel = lavmodel2, lavsamplestats = lavsamplestats, lavoptions = lavoptions, lavdata = lavdata, lavpartable = lavpartable, lavcache = lavcache, lavimplied = lavimplied, lavh1 = lavh1)
lav_model_information(lavmodel = lavmodel, lavsamplestats = lavsamplestats, lavdata = lavdata, lavcache = lavcache, lavimplied = lavimplied, lavh1 = lavh1, lavoptions = lavoptions, extra = FALSE, augmented = TRUE, inverted = TRUE, use.ginv = use.ginv)
lav_model_information_observed(lavmodel = lavmodel, lavsamplestats = lavsamplestats, lavdata = lavdata, lavimplied = lavimplied, lavh1 = lavh1, lavcache = lavcache, group.weight = group.weight, lavoptions = lavoptions, extra = extra, augmented = augmented, inverted = inverted, use.ginv = use.ginv)
lav_model_hessian(lavmodel = lavmodel, lavsamplestats = lavsamplestats, lavdata = lavdata, lavoptions = lavoptions, lavcache = lavcache, group.weight = group.weight)
lav_model_gradient(lavmodel = lavmodel, GLIST = lav_model_x2GLIST(lavmodel = lavmodel, x.left), lavsamplestats = lavsamplestats, lavdata = lavdata, lavcache = lavcache, type = 'free', group.weight = group.weight)
computeOmega(Sigma.hat = Sigma.hat, Mu.hat = Mu.hat, lavsamplestats = lavsamplestats, estimator = estimator, meanstructure = TRUE, conditional.x = conditional.x)
inv.chol(Sigma.hat[[g]][var.idx, var.idx], logdet = FALSE)
chol(S)
chol.default(S)
To receive assistance with this problem, please report the message above at: https://jasp-stats.org/bug-reports
--------------------------
To speculate, with my limited knowledge, perhaps the key line of the above is "Error in chol.default(S): the leading minor of order 3 is not positive definite".
As you can see from the code, the error is thrown by lavaan. We can look at it, but ultimately we might refer you to the lavaan community. We'll have to see.
Cheers,
E.J.
Please take a look if you can.
So, lavaan is an underlying R package?
Do they have any forum such as this one?
So, there are two strategies: one to get this fixed (long-term goal). And, second, to find a working work-around, such that I can still do the mediation analysis in the coming days and weeks (short-term goal).
So, i have found a work-around by multiplying all entries in the column of small numbers by 10,000 to make them all greater than 1. But is the bootstrap mediation analysis result (estimate and confidence intervals), using this modified column, any different than using the unmodified column (if the latter was possible, if this bug [aversion to small numbers] wasn't present)? For example, if this column is the Mediator variable.
i.e. Can this work-around produce valid results? In your estimation? Is there any way of checking the validity of this work-around? Perhaps using another tool?
To correct my initial post: the work-around is by multiplying by 10,000. Not by 1,000 as it says. The multiplication of all values in the column by 10,000 is needed to get all the values to be greater than 1.
So, I've posted on the lavaan community forum, and am making some good headway there, with some super helpful answers already. And maybe more to come.
In one of my posts there I suggest that maybe JASP can do this manipulation of columns automatically (and it is this manipulated data that is then fed to lavaan). So, this problem never comes up again. Such that the user isn't even aware of this issue. This complexity is hidden from them. Or short of that - perhaps a note that columns may need to be multiplied by a constant if any of its entries are very small. What do you think?
Hi Michael_Jasper,
Indeed, lavaan is the underlying (R) package, and these errors are given by lavaan. So, in general, this is not a problem specific to JASP, and perhaps the lavaan community (https://groups.google.com/g/lavaan) might be of better help here. You can get the lavaan syntax in JASP by choosing "Lavaan syntax" under "Options".
The core of this error message is, as assumed by you, the part "Error in chol.default(S): the leading minor of order 3 is not positive definite". This means that the estimation process failed because it's not possible to calculate a 'positive definite' covariance matrix for your data, while positive definitiveness is a property that a covariance matrix must have. Such problems can occur for many reasons, e.g. when the data is too noisy, or the sample size is too small. I would guess that in your case it may be the issue that one column has too little values in comparison to the others (and consequently a very small covariance with the other columns as well), but tbh I'm not really sure.
IMO using the standardized solution is a valid workaround, as is multiplying by 10.000 (though it depends a bit on the variable how interpretable the estimates of the effects then are). In any case, the test statistics, and conclusions in terms of 'significance' won't be affected by this.
Regards,
Michael
It wouldn't work out in practice to manipulate the columns without the knowledge of the user. The quantitative interpretations of model parameters depend on the scaling of the variables, so the users must be aware of this.
If you don't want to think about the scaling of the variables yourself, your best bet is using the standardized solution (though note that this comes with disadvantages too, as standardization scales the variables based on the standard deviations, which are estimated with some extent of uncertainty/ error).