jamovi

Hiya,
I'm using v2.00 of jamovi and have re-ran a (3*2) RM ANOVA for some old data. Everything is fine and coming out as before, but now I notice the post hoc contain two errors. This has worked fine on an older version of jamovi - I can't remember which, but seems to now throw up this issue. Not sure what is the problem?

*edit - I meant a (3*2)

not sure either, we'd need to see the data set.

can you attach it here, or email it through to contact <at> jamovi.org?

with thanks

Hi Jonathon
Just confirming that I sent you a copy of the file via email earlier this morning.
Cheers!

Hi Jonathon
Just wondering if you had chance to look at this issue yet?

Cheers

hi sorry, we haven't received it. can you resend?

with thanks

Hi Jonathon,
Sorry - I didn't spot your reply. I've attached the data file here for you.

hmm, i'm not sure. these results may simply be correct of course.

i'll ask ravi.

jonathon

Hi,
Earlier this year we changed the way we calculate the estimated marginal means (on which the post-hoc tests are based) as per recommendation of the author of the package we use to estimate the RM ANOVA: https://cran.r-project.org/web/packages ... ample.html. It now uses a multivariate model in its calculations: https://github.com/jamovi/jmv/commit/a9c8cb0

Cheers,
Ravi

Hi both,
Thanks for taking a look - I'm still not clear why the new model would create two issues when generating the standard error values for two of the pairwise tests - namely 0 and NaN. The former is unlikely and the latter suggests a problem with the calculation. Admittedly JASP may well use a different formula to calculate SE for these pairwise tests, but nonetheless that program does return definite values for these two pairs (see below). Interestingly they are the same mean differences (albeit one +VE and the other -VE) and have the same SE value - not sure if that might be a clue as to what is happening...?

hey,

i wouldn't assume that definite values means that it's correct, or that not-definite answers means it's broken or not working. that heuristic isn't always reliable.

we've implemented this using afex, and we rely on henrik's judgement as to the most correct analysis here. your next step might be to reproduce this result with afex, and then go and ask henrik about it. if it turns out there is an issue here, he'll be the one making the fix.

cheers

jonathon