Re: [Rd] R CMD Rdconv drops sections: arguments, seealso, examples (PR#9649)
On Thu, 3 May 2007, Prof Brian Ripley wrote:
> Bill,
>
> Now we have access again to the R-bugs repository (the database has been
> offline for about a week) I can try to understand this.
>
> This is a follow up to PR#9645 which was itself a follow up to PR#9606,
> which was a report that Rdconv silently drops sections it makes no sense
> of. (The latter is well known, and that's why R CMD check has an
> independent check of Rd syntax using R code.)
>
> And this supersedes the suggestion in PR#9645, both of which are that
> Rdconv should detect unclosed sections and throw an error.
>
> It is not clear to me that throwing an error is helpful as it would stop
> the package installation process when all but one section in one .Rd file
> would be useful. But it would seem good to give a warning, and so I
> propose that we adapt your code to do so.
Doing so (now in R-devel) shows a couple of false positives (\align{{} in
Paren.Rd is one), and rather a lot of correct warnings about excess }s
that are not doing any harm. So I have tuned the warnings to be less
strident in the latter case.
> Does that reasonably reflect the various PRs?
>
> Brian
>
>
> On Tue, 1 May 2007, [EMAIL PROTECTED] wrote:
>
>> On Mon, 30 Apr 2007 [EMAIL PROTECTED] wrote:
>>
>>> On Tue, 10 Apr 2007 [EMAIL PROTECTED] wrote:
>>>
I've created a .Rd file (below), then converted that to .sgml using
R CMD Rdconv --type=Ssgm combn.Rd > combn.sgml
The output (shown below) is missing some of the sections:
arguments
seealso
examples
If instead I convert to .d (below), the same sections are missing,
and the "note" section is included but without the necessary newline.
>>>
>>> The underlying problem was that there were some unmatched open-braces.
>>> (or 'brackets'?) The attached patch to
>>> share/perl/R/Rdconv.pm:mark_brackets()
>>> seems to detect unmatched open and close braces and throw an error:
>>>
>>>% R CMD INSTALL -l /tmp/Rlib timhPackage
>>>* Installing *source* package 'timhPackage' ...
>>>** help
>>> >>> Building/Updating help pages for package 'timhPackage'
>>> Formats: text html latex example
>>>Rdconv(): mismatched braces in help file timh.Rd on or after line 12
>>>ERROR: building help failed for package 'timhPackage'
>>>** Removing '/tmp/Rlib/timhPackage'
>>>** Restoring previous '/tmp/Rlib/timhPackage'
>>>
>>> The code to report the line number doesn't work quite right
>>> since any "% comment" lines in the Rd file have been removed
>>> from $complete_text by the time we get here. I fudged by
>>> putting 'on or after line XXX' in the error message.
>>
>> The following patch adds a little more information (the
>> name of the \tag or whether it is an unmatched { or })
>> to the error message, so Tim's example results in
>>
>>% R CMD INSTALL -l /tmp/Rlib timhPackage
>>* Installing *source* package 'timhPackage' ...
>>** help
>>>>> Building/Updating help pages for package 'timhPackage'
>> Formats: text html latex example
>>Rdconv(): mismatched braces ('\arguments{') in help file timh.Rd on or
>> after line 12
>>ERROR: building help failed for package 'timhPackage'
>>** Removing '/tmp/Rlib/timhPackage'
>>** Restoring previous '/tmp/Rlib/timhPackage'
>>
>>
>> *** Rdconv.pm~ 2007-03-29 19:05:08.0 -0700
>> --- Rdconv.pm2007-05-01 10:28:55.0 -0700
>> ***
>> *** 254,259
>> --- 254,275
>> $complete_text =~ s/{([^{}]*)}/$id$1$id/s;
>> print STDERR "." if $debug;
>> }
>> + # Any remaining brackets must be unmatched ones, hence report error.
>> + if ($complete_text =~ /([{}])/s) {
>> + # Would like to tell which which line has unmatched { or },
>> + # but lines starting with % have already been removed.
>> + # Hence the 'on or after' in the message.
>> + my $badlineno=0 ;
>> +my $extra_info = "(\'$1\')" ;
>> + if ($complete_text =~ /(\\\w+{)/) {
>> +$extra_info = "(\'$1\')" ;
>> +}
>> + foreach my $line (split /\n/, $complete_text) {
>> + $badlineno++;
>> + last if ($line =~ /[{}]/) ;
>> + }
>> + die "Rdconv(): mismatched braces $extra_info in help file $Rdname
>> on or after line $badlineno\n" ;
>> + }
>> }
>>
>> sub unmark_brackets {
>>
>> __
>> R-devel@r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-devel
>>
>
>
--
Brian D. Ripley, [EMAIL PROTECTED]
Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/
University of Oxford, Tel: +44 1865 272861 (self)
1 South Parks Road, +44 1865 272866 (PA)
Oxford OX1 3TG, UKFax: +44 1865 272595
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Display list redraw incomplete
Since compiling R 2.5.0 from source on my Mac (PowerBook) I've noticed some strange behavior when plotting. I'm not sure if it's a problem with my setup/compilation because I feel like a problem as basic as this one would have been reported already. I'm running R with X11 and R was built with gcc 4.0.1. Basically, I run > plot(0, 0) > dev.off() X11 4 Warning message: Display list redraw incomplete I don't think I've ever seen that warning before. In addition to the warning, two extra x11 devices are launched. Same thing happens in R-devel (r41438). Any thoughts on what might be going on? Thanks, -roger -- Roger D. Peng | http://www.biostat.jhsph.edu/~rpeng/ __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Imports/exports of S4 methods
I'm wrestling with the same issues, so this is the blind leading the
blind, but that usually prompts someone knowledgeable to say something
useful.
Roger D. Peng wrote:
>I have a question about what to do in the following situation (please bear
>with
>the setup):
>
>Package A defines an S4 generic 'foo' and as well as S4 methods for 'foo' and
>has
>
>exportMethods("foo")
>
>in its NAMESPACE file.
>
>Package B defines another method for 'foo' for class "bar" and has
>
>importFrom(A, "foo")
>exportMethods("foo")
>exportClasses("bar")
>
>in its NAMESPACE file. Should Package B also have Package A in the 'Depends:'
>field of the DESCRIPTION file or is it correct to import Package A only?
>
>
I thought it should only be necessary to import A in NAMESPACE and list
it in Imports in the DESCRPTION file, but I get warning messages if the
code in B does not require("A") in the .onLoad function. This in turn
means that A needs to be in the Depends line of DESCRIPTION.
>Finally, Package C has a single exported function named 'myfunc' which needs
>to
>use the method for 'foo' defined in Package B, so its NAMESPACE file has
>
>importFrom(A, "foo")
>importMethodsFrom(B, "foo")
>importClassesFrom(B, "bar")
>export("myfunc")
>
>Is this the correct thing to do?
>
>
I don't think you need the imports in this case, just the the export.
You do need B (and thus implicitly A) in the Depends line of DESCRIPTION.
>The error I get under this setup is that 'myfunc' cannot find the method for
>'foo' defined in Package B when 'myfunc' calls 'foo' on an object of class
>"bar".
>
>
I'm not sure why, but the one problem I have had is that when the syntax
of the NAMESPACE file is messed up, you only get warnings when to
require the package, but then you get errors when you try to use the
functions. Be sure to look back and see if you got warnings when you
require("B").
>If you've made it this far I'm already grateful! Any help with this would be
>appreciated.
>
>
Thanks, you just saved me writing up the same questions.
>-roger
>
>
La version française suit le texte anglais.
This email may contain privileged and/or confidential inform...{{dropped}}
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Qt device update
On May 3, 2007, at 8:52 PM, Deepayan Sarkar wrote:
> [...] I have a couple of related questions. First, dev.interactive
> (), used in example() and many demo()-s to decide if the current
> device is interactive, is currently implemented as:
>
>> dev.interactive
> function (orNone = FALSE)
> {
> iDevs <- c("X11", "GTK", "gnome", "quartz", "windows", "JavaGD")
> interactive() && (.Device %in% iDevs || (orNone && .Device ==
> "null device" && getOption("device") %in% iDevs))
> }
>
> This makes it impossible for new devices to be treated as interactive.
I think we should finally pass this question to the device itself.
For some devices like Cairo the answer depends on the parameters with
which the device was created (e.g. type='x11' is interactive whereas
type='png' is not), so each instance of the device will answer
differently. We could simply add an another capability flag - that is
IMHO the only reliable solution. Any other ideas?
Cheers,
Simon
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Bug in qr.R ? (PR#9655)
Ladies and Gentlemen, using > A <- structure(c(1, 0, 0, 3, 2, 1, 4, 5, -3, -2, 1, 0), .Dim = as.integer(c(3,4))) I get > dim(A) [1] 3 4 > qr.R(qr(A),complete=TRUE) [,1] [,2] [,3] [,4] [1,] -1 -3.00 -4.00 2.000 [2,]0 -2.236068 -3.130495 -0.8944272 [3,]0 0.00 -4.919350 -0.4472136 > qr.R(qr(A),complete=FALSE) [,1] [,2] [,3] [,4] [1,] -1 -3.00 -4.00 2.000 [2,]0 -2.236068 -3.130495 -0.8944272 [3,]0 0.00 -4.919350 -0.4472136 In ?qr.R I find /qr.R returns R. The number of rows of R is nrow(X) or ncol(X), depending on whether complete is TRUE or FALSE./ As you can see, the number of rows stays the same... Thank you. D. Trenkler --please do not edit the information below-- Version: platform = i386-pc-mingw32 arch = i386 os = mingw32 system = i386, mingw32 status = major = 2 minor = 5.0 year = 2007 month = 04 day = 23 svn rev = 41293 language = R version.string = R version 2.5.0 (2007-04-23) Windows XP (build 2600) Service Pack 2.0 Locale: LC_COLLATE=English_United States.1252;LC_CTYPE=English_United States.1252;LC_MONETARY=English_United States.1252;LC_NUMERIC=C;LC_TIME=English_United States.1252 Search Path: .GlobalEnv, package:stats, package:graphics, package:grDevices, package:utils, package:datasets, package:methods, Autoloads, package:base -- Dietrich Trenkler c/o Universitaet Osnabrueck Rolandstr. 8; D-49069 Osnabrueck, Germany email: [EMAIL PROTECTED] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Qt device update
On 5/3/07, Prof Brian Ripley <[EMAIL PROTECTED]> wrote:
> On Thu, 3 May 2007, Deepayan Sarkar wrote:
>
> > Hi,
> >
> > a few days back I had asked for help on a Qt device package. Thanks to
> > hints from Duncan TL and Thomas Friedrichsmeier, I now have something
> > more or less functional. For those interested, It can be downloaded
> > from
> >
> > http://dsarkar.fhcrc.org/R/R-Qt.html
> >
> > I have a couple of related questions. First, dev.interactive(), used
> > in example() and many demo()-s to decide if the current device is
> > interactive, is currently implemented as:
> >
> >> dev.interactive
> > function (orNone = FALSE)
> > {
> >iDevs <- c("X11", "GTK", "gnome", "quartz", "windows", "JavaGD")
> >interactive() && (.Device %in% iDevs || (orNone && .Device ==
> >"null device" && getOption("device") %in% iDevs))
> > }
> >
> > This makes it impossible for new devices to be treated as interactive.
> > Perhaps it would be better to change this to something like
> >
> >iDevs <- c("X11", "GTK", "gnome", "quartz", "windows", "JavaGD",
> > getOption("interactive.devices"))
> >
> > so that packages can set an option to be included in this list.
>
> That would work differently from any existing option, adding to the list.
> But it would make sense for package grDevices to have a function to
> request being added to the list.
>
> (If the device is already running we could use
> grDevices:::dev.displaylist() to ask if this looked like a screen device.)
I will be happy with anything that works. Given Simon's comments, it
looks like this might be non-trivial, so a short term solution could
be to add a ask= argument to demo() (like example() already has) and
remove the explicit overrides in the standard demos.
> > Second, can someone explain the details of what happens when a symbol
> > font is requested (with font=5 or with plotmath stuff)? demo(plotmath)
> > seems to work on a machine with LANG=en_US (I don't know what encoding
> > this means, probably latin1),
>
> If a Linux machine, yes, it is shorthand for en_US.iso88591.
> It could also mean ASCII and according to the standards (XPG?) probably
> should.
>
> > but some symbols don't work on my desktop which has en_US.UTF-8.
> > Presumably, this means I have to interpret the encoding differently, but
> > what exactly is the rule? Is it enough to treat it as latin1? Some
> > devices have a lot of code dealing with encodings, and I want to make
> > sure I understand the issues before I go off on a wild goose chase.
>
> The symbol font is regarded as being in Adobe Symbol encoding, which is an
> 8-bit encoding. So you have to be careful to handle font 5 without
> re-encoding, but that's not hard at device level (the graphics engine has
> handled the re-encoding needed).
Ah, that's the piece I was missing. I was reencoding everything using
QString::fromLocal8bit(). If I skip that when fontface=5, things work
better. I do need it for other fontfaces to get multibyte encodings
working properly.
> If some symbols work and some do not, this is almost certainly a font
> selection issue. If X11 is involved (and AFAIK the Qt implementations on
> Linux run on X11), you do need to ensure that getting a font in the
> desired encoding is given top priority (which can be hard to achieve in
> X11).
That may be a problem in general, but the only problem I see on (both)
my Linux machines after the above fix is that %prop% shows up as mu
(but Windows is fine). I'm not really sure what font is being used,
I'll try to track it down.
-Deepayan
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Qt device update
On Fri, 4 May 2007, Simon Urbanek wrote:
>
> On May 3, 2007, at 8:52 PM, Deepayan Sarkar wrote:
>
>> [...] I have a couple of related questions. First, dev.interactive
>> (), used in example() and many demo()-s to decide if the current
>> device is interactive, is currently implemented as:
>>
>>> dev.interactive
>> function (orNone = FALSE)
>> {
>> iDevs <- c("X11", "GTK", "gnome", "quartz", "windows", "JavaGD")
>> interactive() && (.Device %in% iDevs || (orNone && .Device ==
>> "null device" && getOption("device") %in% iDevs))
>> }
>>
>> This makes it impossible for new devices to be treated as interactive.
>
>
> I think we should finally pass this question to the device itself.
> For some devices like Cairo the answer depends on the parameters with
> which the device was created (e.g. type='x11' is interactive whereas
> type='png' is not), so each instance of the device will answer
> differently. We could simply add an another capability flag - that is
> IMHO the only reliable solution. Any other ideas?
Do we need a reliable solution? The worst that happens that if R thinks a
device is interactive and it is not, you get asked to go on to the next
page a few times.
I've altered R-devel to look at the displaylist. All the devices I knew
had that enabled by default iff they are screen devices, but I've just
looked at Cairo and it seems that could be a bit less dumb about its
setting.
You can't in general ask the device, as there might be no device open and
you need to know what the device that would automatically opened will do.
And you don't want to open it, as it might not be needed. Allowing
devices to say by name that they will be interactive is the only way
anyone has come up with on this so far.
--
Brian D. Ripley, [EMAIL PROTECTED]
Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/
University of Oxford, Tel: +44 1865 272861 (self)
1 South Parks Road, +44 1865 272866 (PA)
Oxford OX1 3TG, UKFax: +44 1865 272595
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] sending signals to embedded R
Hi, one thing I haven't been able to figure out from R-exts is how to interrupt a calculation running inside an embedded R. C code inside R calls R_CheckUserInterrupt() intermittently to check for interrupts, but how does my GUI tell R that the user wants it interrupted? -Deepayan __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] sending signals to embedded R
On Fri, 4 May 2007, Deepayan Sarkar wrote: > one thing I haven't been able to figure out from R-exts is how to > interrupt a calculation running inside an embedded R. C code inside R > calls R_CheckUserInterrupt() intermittently to check for interrupts, > but how does my GUI tell R that the user wants it interrupted? Well, the intention is that you send an interrupt, which hardly needs to be in the manual. But SIGINT is caught and used to set R_interrupts_pending = 1, so you could risk using that non-API entry point (and be prepared to have your GUI broken at any time). -- Brian D. Ripley, [EMAIL PROTECTED] Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/ University of Oxford, Tel: +44 1865 272861 (self) 1 South Parks Road, +44 1865 272866 (PA) Oxford OX1 3TG, UKFax: +44 1865 272595 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] sending signals to embedded R
On 5/4/07, Prof Brian Ripley <[EMAIL PROTECTED]> wrote: > On Fri, 4 May 2007, Deepayan Sarkar wrote: > > > one thing I haven't been able to figure out from R-exts is how to > > interrupt a calculation running inside an embedded R. C code inside R > > calls R_CheckUserInterrupt() intermittently to check for interrupts, > > but how does my GUI tell R that the user wants it interrupted? > > Well, the intention is that you send an interrupt, which hardly needs to > be in the manual. I didn't mean to imply that it does. I'm just new to signals and things that should be obvious aren't. Basically kill(2) seems to be the right thing to use, but I wasn't sure what the PID needs to be. Turns out sending SIGINT to my GUI from a shell interrupts R, so raise(SIGINT) should be enough. -Deepayan __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] sending signals to embedded R
On Fri, 4 May 2007, Deepayan Sarkar wrote: > On 5/4/07, Prof Brian Ripley <[EMAIL PROTECTED]> wrote: >> On Fri, 4 May 2007, Deepayan Sarkar wrote: >> >>> one thing I haven't been able to figure out from R-exts is how to >>> interrupt a calculation running inside an embedded R. C code inside R >>> calls R_CheckUserInterrupt() intermittently to check for interrupts, >>> but how does my GUI tell R that the user wants it interrupted? >> >> Well, the intention is that you send an interrupt, which hardly needs to >> be in the manual. > > I didn't mean to imply that it does. I'm just new to signals and > things that should be obvious aren't. > > Basically kill(2) seems to be the right thing to use, but I wasn't > sure what the PID needs to be. Turns out sending SIGINT to my GUI from > a shell interrupts R, so raise(SIGINT) should be enough. The tricky bit here is figuring out who does the sending. It you have a separate thread/process for the GUI and R then that is fine (though may raise other issues). If it is a single thread then you need your event processing to get an occasional look in to recognise the user action that triggers an interrupt. The Windows version handles this by having R_CheckUserInterrupt() do a limited amount of event processing (you need to be careful in GUI events have R actions associated with them). I believe the Mac version is similar though it has been a while since I looked at that. I don't believe the unix version of R_CheckUserInterrupt() does not provide hooks for installing such checking (we have talked about this off an on but I don't believe anything happened -- could be wrong there though). If Qt allows this one option may be to have events on your nterrupt widget managed by a small thread that does nothing other than send a signal to the main thread if the widget is clicked. Best, luke -- Luke Tierney Chair, Statistics and Actuarial Science Ralph E. Wareham Professor of Mathematical Sciences University of Iowa Phone: 319-335-3386 Department of Statistics andFax: 319-335-3017 Actuarial Science 241 Schaeffer Hall email: [EMAIL PROTECTED] Iowa City, IA 52242 WWW: http://www.stat.uiowa.edu __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] [R] factanal AIC?
Dear R Developers:
What is the proper log(likelihood) for 'factanal'? I believe it
should be something like the following:
(-n/2)*(k*(log(2*pi)+1)+log(det(S)))
or without k*(log(2*pi)-1):
(-n/2)*log(det(S)),
where n = the number of (multivariate) observations.
The 'factanal' help file say the factanal component "criteria:
The results of the optimization: the value of the negative
log-likelihood and information on the iterations used."
However, I'm not able to get this. If it's a log(likelihood),
then replacing a data set m1 by rbind(m1, m1) should double the
log(likelihood). However it has no impact on it. Consider the
following modification of the first example in the 'factanal' help page:
>v1 <- c(1,1,1,1,1,1,1,1,1,1,3,3,3,3,3,4,5,6)
> v2 <- c(1,2,1,1,1,1,2,1,2,1,3,4,3,3,3,4,6,5)
> v3 <- c(3,3,3,3,3,1,1,1,1,1,1,1,1,1,1,5,4,6)
> v4 <- c(3,3,4,3,3,1,1,2,1,1,1,1,2,1,1,5,6,4)
> v5 <- c(1,1,1,1,1,3,3,3,3,3,1,1,1,1,1,6,4,5)
> v6 <- c(1,1,1,2,1,3,3,3,4,3,1,1,1,2,1,6,5,4)
> m1 <- cbind(v1,v2,v3,v4,v5,v6)
> tst <- factanal(m1, factors=3)
> fit1 <- factanal(m1, factors=3)
> fit2 <- factanal(rbind(m1, m1), factors=3)
> fit1$criteria["objective"]
objective
0.4755156
> fit2$criteria["objective"]
objective
0.4755156
From the following example, it seems that the "k*(log(2*pi)-1)
term is omitted:
> x2 <- c(-1,1)
> X2.4 <- as.matrix(expand.grid(x2, x2, x2, x2))
> factanal(X2.4, 1)$criteria
objective counts.function counts.gradient
0 7 7
However, I can't get the 'fit1$criteria' above, even ignoring the
sample size. Consider the following:
> S3 <- tcrossprod(fit1$loadings)+diag(fit1$uniquenesses)
> log(det(S3))
[1] -6.725685
Shouldn't this be something closer to the 0.4755 for fit1$criteria?
Thanks,
Spencer Graves
JENS: For your purposes, I suggest you try to compute
(-n/2)*log(det(tcrossprod(fit$loadings)+diag(fit$uniquenesses)). If you
do this, you might get more sensible results with your examples.
Hope this helps.
Spencer Graves
Jens Oehlschlägel wrote:
> Dear list members,
>
> Could any expert on factor analysis be so kind to explain how to calculate
> AIC on the output of factanal. Do I calculate AIC wrong or is
> factanal$criteria["objective"] not a negative log-likelihood?
>
> Best regards
>
>
> Jens Oehlschlägel
>
>
>
> The AIC calculated using summary.factanal below don't appear correct to me:
>
> n items factors total.df rest.df model.df LL AIC
> AICc BIC
> 1 100020 1 210 170 40 -5.192975386 90.38595
> 93.80618 286.6962
> 2 100020 2 210 151 59 -3.474172303 124.94834
> 132.48026 414.5059
> 3 100020 3 210 133 77 -1.745821627 157.49164
> 170.51984 535.3888
> 4 100020 4 210 116 94 -0.120505369 188.24101
> 207.97582 649.5700
> 5 100020 5 210 100 110 -0.099209921 220.19842
> 247.66749 760.0515
> 6 100020 6 210 85 125 -0.072272695 250.14455
> 286.18574 863.6140
> 7 100020 7 210 71 139 -0.054668588 278.10934
> 323.36515 960.2873
> 8 100020 8 210 58 152 -0.041708051 304.08342
> 358.99723 1050.0622
> 9 100020 9 210 46 164 -0.028686298 328.05737
> 392.87174 1132.9292
> 10 100020 10 210 35 175 -0.015742783 350.03149
> 424.78877 1208.8887
> 11 100020 11 210 25 185 -0.007007901 370.01402
> 454.55947 1277.9487
> 12 100020 12 210 16 194 -0.005090725 388.01018
> 481.99776 1340.1147
>
>
> summary.factanal <- function(object, ...){
> if (inherits(object, "try-error")){
> c(n=NA, items=NA, factors=NA, total.df=NA, rest.df=NA, model.df=NA,
> LL=NA, AIC=NA, AICc=NA, BIC=NA)
> }else{
> n <- object$n.obs
> p <- length(object$uniquenesses)
> m <- object$factors
> model.df <- (p*m) + (m*(m+1))/2 + p - m^2
> total.df <- p*(p+1)/2
> rest.df <- total.df - model.df # = object$dof
> LL <- -as.vector(object$criteria["objective"])
> k <- model.df
> aic <- 2*k - 2*LL
> aicc <- aic + (2*k*(k+1))/(n-k-1)
> bic <- k*log(n) - 2*LL
> c(n=n, items=p, factors=m, total.df=total.df, rest.df=rest.df,
> model.df=model.df, LL=LL, AIC=aic, AICc=aicc, BIC=bic)
> }
> }
>
> multifactanal <- function(factors=1:3, ...){
> names(factors) <- factors
> ret <- lapply(factors, function(factors){
> try(factanal(factors=factors, ...))
> })
> class(ret) <- "multifactanal"
> ret
> }
>
> summary.multifactanal <- function(object,...){
> do.call("rbind", lapply(object, summary.factanal))
> }
>
> print.multifactanal <- function(x,...){
> ret <- summary.multifactanal(x)
> print(ret, ...)
> invisible(ret)
> }
>
> # simulate
