I have a problem with nlme on Windows 2000, and I'm having a devil of a
time determining whether the problem is with my computer or with
something in R. I'm running v1.8.1 on a Dell Pentium III with 512MB of
RAM and all of the recommended Windows 2000 updates applied.
If I use Rterm, I can run analyses with NLME to my heart's content. But
when I run Rgui, I encounter a floating point exception. To be concrete if I
> library(nlme)
Loading required package: lattice
> data(Rail)
> lme(travel ~ 1, data = Rail, random = ~ 1 | Rail)
(the first example in Pinheiro and Bates), R churns for a while and a
window pops up informing me of an application error. Specifically, "The
exception Floating-point division by zero. (0xc000008e) occurred in the
application at location 0x639b50ff." There error occurs every time. The
same analysis runs flawlessly in Rterm.
To make it even stranger, I get the same error on a Toshiba Pentium
laptop (also with 512MB of memory, although I haven't tried the analyses
in Rterm on that machine). On that machine, I get a blue screen after
acknowledging the error. The laptop is a dual boot on which I run Linux
(Fedora Core 1). R works perfectly on it under Linux.
I've downloaded and re-installed the binaries on both machines several
times, so I don't think I have a corrupted download. Any ideas on how to
diagnose (and solve) this problem would be greatly appreciated.
Kent
--
Kent E. Holsinger kent at darwin.eeb.uconn.edu
http://darwin.eeb.uconn.edu
-- Department of Ecology & Evolutionary Biology
-- University of Connecticut, U-3043
-- Storrs, CT 06269-3043
See the rw-FAQ, specifically Q2.19. It is very likely some piece of rogue software on your machines. On Thu, 8 Apr 2004, Kent Holsinger wrote:> I have a problem with nlme on Windows 2000, and I'm having a devil of a > time determining whether the problem is with my computer or with > something in R. I'm running v1.8.1 on a Dell Pentium III with 512MB of > RAM and all of the recommended Windows 2000 updates applied. > > If I use Rterm, I can run analyses with NLME to my heart's content. But > when I run Rgui, I encounter a floating point exception. To be concrete if I > > > library(nlme) > Loading required package: lattice > > data(Rail) > > lme(travel ~ 1, data = Rail, random = ~ 1 | Rail) > > (the first example in Pinheiro and Bates), R churns for a while and a > window pops up informing me of an application error. Specifically, "The > exception Floating-point division by zero. (0xc000008e) occurred in the > application at location 0x639b50ff." There error occurs every time. The > same analysis runs flawlessly in Rterm. > > To make it even stranger, I get the same error on a Toshiba Pentium > laptop (also with 512MB of memory, although I haven't tried the analyses > in Rterm on that machine). On that machine, I get a blue screen after > acknowledging the error. The laptop is a dual boot on which I run Linux > (Fedora Core 1). R works perfectly on it under Linux. > > I've downloaded and re-installed the binaries on both machines several > times, so I don't think I have a corrupted download. Any ideas on how to > diagnose (and solve) this problem would be greatly appreciated. > > Kent > >-- Brian D. Ripley, ripley at stats.ox.ac.uk 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, UK Fax: +44 1865 272595
On Thu, 08 Apr 2004 08:03:56 -0400, you wrote:>If I use Rterm, I can run analyses with NLME to my heart's content. But >when I run Rgui, I encounter a floating point exception.I agree with Prof Ripley: I'd suspect video (or other) drivers messing up the floating point control word. Identifying the exact cause is quite hard, but you can probably confirm this by rebooting in "safe mode" (i.e. with minimal drivers loaded). You do this by hitting F8 during the boot sequence. R can run fine in safe mode; if you don't get the error, then it's pretty clearly one of the drivers that you usually load that is causing the trouble. Figuring out which one won't be easy... Duncan Murdoch