Bug 16391 - factanal returns wrong rotation matrix when rotation method calls GPArotation package
Summary: factanal returns wrong rotation matrix when rotation method calls GPArotation...
Status: UNCONFIRMED
Alias: None
Product: R
Classification: Unclassified
Component: Models (show other bugs)
Version: R-devel (trunk)
Hardware: Other Windows 64-bit
: P5 major
Assignee: R-core
URL:
Depends on:
Blocks:
 
Reported: 2015-05-20 10:00 UTC by Amy Mulick Cassidy
Modified: 2015-05-20 10:00 UTC (History)
0 users

See Also:


Attachments
R script for reproducing factanal rotation matrix bug (1.44 KB, text/x-matlab)
2015-05-20 10:00 UTC, Amy Mulick Cassidy
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Amy Mulick Cassidy 2015-05-20 10:00:43 UTC
Created attachment 1829 [details]
R script for reproducing factanal rotation matrix bug

I believe the assignment of the rotation matrix, rotmat, is wrong in stats:::factanal when it calls a rotation routine from the add-on package GPArotation.  In the GPArotation help files, the rotation matrix is stored as Th.  However the factanal command reads this matrix but then takes the transpose of its inverse before returning it as the 'rotation matrix'.

if (rotation != "none") {
        rot <- do.call(rotation, c(list(load), cn$rotate))
        load <- if (is.list(rot)) {
            load <- rot$loadings
            fit$rotmat <- if (inherits(rot, "GPArotation")) 
                t(solve(rot$Th))
            else rot$rotmat
            rot$loadings
        }
        else rot
    }

This is a problem for users who have been using oblique rotations, as the result is no longer the rotation matrix; and especially for users who have been using the property t(rotmat) %*% rotmat = Phi to access the factor correlation matrix which is not otherwise returned by factanal, without confirming that this does not actually produce Phi.

Attached is a script detailing this problem.