Thanks for really digging into this, Erich! The hardest-to-fix problem was when it worked some of the time... Anyways. Glad you tracked it down. I'll work on a fix this weekend.
Best, Maggie On Wed, Aug 6, 2014 at 5:00 PM, Erich Greene <erich.gre...@yale.edu> wrote: > 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 <erich.gre...@yale.edu> > 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 <maggie...@gmail.com> 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 <maggie...@gmail.com> wrote: >>> >>>> Thanks for noting this! I'll take a look this evening. >>>> >>>> Maggie >>>> >>>> >>>> On Tue, Aug 5, 2014 at 7:10 AM, Chris Marshall <devel.chm...@gmail.com> >>>> 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 <devel.chm...@gmail.com> >>>>> 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 >>>>> Perldl@jach.hawaii.edu >>>>> http://mailman.jach.hawaii.edu/mailman/listinfo/perldl >>>>> >>>>> >>>> >>> >> >
_______________________________________________ Perldl mailing list Perldl@jach.hawaii.edu http://mailman.jach.hawaii.edu/mailman/listinfo/perldl
