Hello,
I have been trying for weeks to compile a 64-bit Rblas. I started with ATLAS
where I have had success in the past, but 64 bit was not behaving, and as each
compilation takes between 9 and 12 hours, "test, check, and revise" was not
going to be really viable. I therefore switched to OpenBLas (OPBL). I was
successful in compiling R-3.0.1 and an OPBL-based BLAS for Windows 64bit
SANDYBRIDGE (Corei7-avx) which passes all of OPBL's internal checks, and all
but *one* of R's checks (it passes the spline one failed by the 32-bit version
which I asked about yesterday). Well, it fails the same procedure twice, but
not all the time.
The error is found in a call to the `factanal` procedure, specifically the call
to `optim` therein, and it returns an error code "NEW_X", which I have never
seen before. It fails this call in the checks for both stats.R and datasets.R,
but does not fail them all, and for those it works, it returns the proper
answers.
The first call that fails is in statsEx.Rout
fa <- factanal( ~., 2, data = swiss)
Error in factanal(~., 2, data = swiss) :
unable to optimize from this starting value
Interestingly, using 1 or 3 as the value for factor works fine, it is 2 which
fails.
The other failed call is in datasetsEx, and it is...
(Harman23.FA <- factanal(factors = 1, covmat = Harman23.cor))
...other code...
for(factors in 2:4) print(update(Harman23.FA, factors =
factors))
...when the value for factors is 4 (1, 2, and 3 work fine).
I understand that "unable to optimize" can only come from no convergent "best
fit" being found in the `factanal.fit.mle` procedure. Some detective work shows
that the failure is in the call to `optim`. Specifically, when the call
__passes__, it returns:
> nfit
Call:
NULL
Uniquenesses:
Fertility Agriculture Examination
Education
0.420 0.492 0.270
0.005
Catholic Infant.Mortality
0.061 0.960
Loadings:
Factor1 Factor2
Fertility -0.674 0.356
Agriculture -0.648 0.297
Examination 0.713 -0.471
Education 0.997
Catholic -0.178 0.953
Infant.Mortality -0.104 0.169
Factor1 Factor2
SS loadings 2.419 1.373
Proportion Var 0.403 0.229
Cumulative Var 0.403 0.632
The degrees of freedom for the model is 4 and the fit was 0.5017
> nfit$converged
[1] TRUE
But when it __fails__ it returns:
> nfit
Call:
NULL
Uniquenesses:
Fertility Agriculture Examination
Education
0.417 0.487 0.258
0.012
Catholic Infant.Mortality
0.097 0.951
Loadings:
Factor1 Factor2
Fertility -0.683 0.340
Agriculture -0.658 0.282
Examination 0.728 -0.461
Education 0.993
Catholic -0.203 0.929
Infant.Mortality -0.110 0.171
Factor1 Factor2
SS loadings 2.469 1.302
Proportion Var 0.411 0.217
Cumulative Var 0.411 0.628
The degrees of freedom for the model is 4 and the fit was 0.5042
> nfit$converged
[1] FALSE
This results in a different set of starting values being passed to `optim`,
namely:
__FAIL__:
$par
[,1]
Fertility 0.4180782
Agriculture 0.4898004
Examination 0.2608759
Education 0.0005000
Catholic 0.1028010
Infant.Mortality 0.9454609
$value
[1] 0.5015197
$counts
function gradient
302 302
$convergence
[1] 1
$message
[1] "NEW_X"
_____________________________________________
__PASS__:
$par
[,1]
Fertility 0.41936338
Agriculture 0.49205978
Examination 0.26976286
Education 0.00050000
Catholic 0.06973751
Infant.Mortality 0.96007318
$value
[1] 0.5008949
$counts
function gradient
22 22
$convergence
[1] 0
$message
[1] "CONVERGENCE: REL_REDUCTION_OF_F <= FACTR*EPSMCH"
I have never seen that particular failure message from `optim` before, "NEW_X",
and I cannot locate what it means. It is possible, if not probably, that it has
to do with one of the functions internal to `factanal.fit.mle`, possibly the
call to `eigen` as I presume that calls Rblas, but without knowing what the
error means, I'm not sure what else to do. I know the errors are significant,
as the SurviveGoto2 Blas's compiled by Dr. Nakama do not exhibit these errors,
but I have no idea as to what is causing it.
What I am hoping is that one of the experts on this list (perhaps one of the
members of the core team who helped write `factanal`) can recognize what may be
causing the call to `optim` to fails sometimes, and could suggest some possible
investigatory paths or explain why it may not be possible to be solved. I'd
also be happy to e-mail or post the compiled dll's if anyone wants to look at
them directly, although that would require access to a SandyBridge running
Windows 64 bit.
Thank you very much,
Avraham Adler
______________________________________________
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
