Hi again, Following up on the within factor masquerading as a between, I took a look at the original mixed model test (t_anova_rptd_mixed) and found the problem there as well: $a and $b are both within-subject factors. So working with the intended 3-level within * 2-level between model from that test (changing the original subject vector from 0..3x6 to 0..7x3 makes $b between-subjects), I again found a dependence on the order of the data within the piddles. (In principle, we should get the same results no matter how we permute the input vectors, as long as we apply the same permutation to all of them.) While it runs with both orderings, the output is only correct when the data is grouped by subject (my frontends all do this, which is why I'd never noticed a problem before); when the data is grouped by within var level, the error sums of squares are wrong (though the degrees of freedom are correct, unlike in the 3-level between case).
I'm attaching a revised set of tests including this stuff as well. Also a thought that probably gets into feature request territory: The BTWN parameter doesn't seem necessary, since it's always possible to tell from the input which factors are between-subjects and which are within. If a factor takes on every value for every subject, it's within; if it takes on one and only one value for each subject, it's between; if it does anything else, it's not part of a well-formed mixed model. Thanks again. ejg On Wed, Aug 6, 2014 at 1:26 PM, Erich Greene <[email protected]> wrote: > Hi Maggie, > > Thanks for digging into this. > > I think your test provides a solid clue: In it, both $a and $b are > within-subjects variables (each subject has data at every level of each > variable; a subject only corresponds to one level of a between-subjects > variable, as each participant is only part of one group), so it's > interesting that telling the routine that a within variable is between > *doesn't* make it explode. And if somewhere deep down, the code expects > subjects to be orthogonal to between variables rather than nested within > them, that could be a recipe for uninvertible matrices. > > So I took your framework, changed it to 9 subs in 3 groups each receiving > 3 conditions, renamed the factor variables $w and $b to clarify which was > supposed to be within/between, and started playing. It turns out the > routine is sensitive to the order of data within the input piddles: When > the data is grouped by within var level, the routine runs but uses > incorrect error terms (the sums of squares and the degrees of freedom are > both wrong for all effects), while when the data is grouped by subject (as > my toy program did), the routine crashes with an uninvertible matrix. > > I'm attaching a pair of test routines (one for each data grouping). I'm > new to Test::More, so I'm going off yours as a template; hopefully it won't > need much tweaking. (Also, SPSS only gives me three decimal places, so I > loosened tapprox to reflect the imprecision of the reference values.) > > Thanks again for working on this, and I hope this stuff helps. > > ejg > > > > On Tue, Aug 5, 2014 at 10:32 PM, Maggie X <[email protected]> wrote: > >> Ok, I added a test >> <https://github.com/maggiexyz/PDL-Stats/blob/v0.6.6/t/stats_glm.t#L470-L494> >> for a 3-level between subject variable in the package, and that runs fine. >> I don't know whether the results were accurate, since I haven't been able >> to compare it against another package that does mixed anova. >> >> I'll need more time to look into the problem. There's some old hairy code >> there :P >> >> >> Maggie >> >> >> >> On Tue, Aug 5, 2014 at 9:12 AM, Maggie X <[email protected]> wrote: >> >>> Thanks for noting this! I'll take a look this evening. >>> >>> Maggie >>> >>> >>> On Tue, Aug 5, 2014 at 7:10 AM, Chris Marshall <[email protected]> >>> wrote: >>> >>>> BTW, to get the code to run on my system, I >>>> had to: >>>> >>>> 1) Change 'use 5.18;' to 'use 5.10;' >>>> 2) Comment out use autodie qw(:all) >>>> >>>> Modified code attached. >>>> >>>> --Chris >>>> >>>> >>>> On Tue, Aug 5, 2014 at 7:06 AM, Chris Marshall <[email protected]> >>>> wrote: >>>> > Hi Erich- >>>> > >>>> > The input $ivs matrix generated for the call to $y->ols_t >>>> > has rows of zeros so it is definitely not invertible. Someone >>>> > who actually knows/uses these routines will need to take >>>> > a look at what is going or whether it is possible that the >>>> > calling sequence needs to be changed. >>>> > >>>> > Cheers, >>>> > Chris >>>> >>>> _______________________________________________ >>>> Perldl mailing list >>>> [email protected] >>>> http://mailman.jach.hawaii.edu/mailman/listinfo/perldl >>>> >>>> >>> >> >
REVISED_mixed_anova_test.pl
Description: Perl program
_______________________________________________ Perldl mailing list [email protected] http://mailman.jach.hawaii.edu/mailman/listinfo/perldl
