Re: [Rd] MacOS X - R crashes & import problem (PR#9005)
Hi there, I have got more or less the same problem. I actually can not do anything in the R editor - as soon as I try to change something it crashes. Has anyone been able to solve this problem? I can send the full crash report if someone is interested. gr. Herwig Below my systems details: Date/Time: 2009-01-05 23:38:29 +0100 OS Version: 10.5.6 (Build 9G55) Architecture: i386 Report Version: 4 Command:R Path: /Applications/R.app/Contents/MacOS/R Version:R 2.8.1 GUI 1.27 Tiger build 32-bit (5301) Parent: launchd [87] PID:519 Event: hang Time: 43.33s Steps: 365 Process:R [519] Path: /Applications/R.app/Contents/MacOS/R -- oliver.balmer wrote: > > Full_Name: Oliver Balmer > Version: 2.3.1 > OS: Mac OS 10.4.6 > Submission from: (NULL) (157.161.74.75) > > > when working in the editor R crashes regularly. no other program ever > crashes. > one quite reliable way to crash it is by marking some code and then > pressing the > "find" command. I have had this problem with other R versions before. I > have the > feeling the editor is the problem. Another problem with the editor is that > I > always need to hit the carriage return twice after inserting the cursor at > a > certain point, after the first time, nothing happens. Not a big problem > but > probably not as it should be, and maybe a hint for a deeper problem. > > Another bug: if the imported data frame contains a µ (greek mu, as in > microliter), R can't read the file. > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel > > -- View this message in context: http://www.nabble.com/MacOS-X---R-crashes---import-problem-%28PR-9005%29-tp4933442p21301048.html Sent from the R devel mailing list archive at Nabble.com. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Apparant bug in binomial model in GLM (PR#13434)
Full_Name: Søren Faurby Version: 2.4.1 and 2.7.2 OS: Submission from: (NULL) (192.38.46.92) There appear to be a bug in the estimation of significance in the binomial model in GLM. This bug apparently appears when the correlation between two variables is to strong. Such as this dummy example c(0,0,0,0,0,1,1,1,1,1)->a a->b m1<-glm(a~b, binomial) summary(m1) It is sufficient that all 1's correspond to 1's such as this example c(0,0,0,0,0,1,1,1,1,1)->a c(0,0,0,0,1,1,1,1,1,1)->c m1<-glm(a~c, binomial) summary(m1) I hope that this message is understandable. Kind regards, Søren __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] MacOS X - R crashes & import problem (PR#9005)
On Jan 5, 2009, at 17:44 , herwig wrote: Hi there, I have got more or less the same problem. I actually can not do anything in the R editor - as soon as I try to change something it crashes. Has anyone been able to solve this problem? No, since as you can see it is filed under "not-reproducible". I can send the full crash report if someone is interested. Please do, send it to me and include your sessionInfo(). Thanks, Simon gr. Herwig Below my systems details: Date/Time: 2009-01-05 23:38:29 +0100 OS Version: 10.5.6 (Build 9G55) Architecture: i386 Report Version: 4 Command:R Path: /Applications/R.app/Contents/MacOS/R Version:R 2.8.1 GUI 1.27 Tiger build 32-bit (5301) Parent: launchd [87] PID:519 Event: hang Time: 43.33s Steps: 365 Process:R [519] Path: /Applications/R.app/Contents/MacOS/R -- oliver.balmer wrote: Full_Name: Oliver Balmer Version: 2.3.1 OS: Mac OS 10.4.6 Submission from: (NULL) (157.161.74.75) when working in the editor R crashes regularly. no other program ever crashes. one quite reliable way to crash it is by marking some code and then pressing the "find" command. I have had this problem with other R versions before. I have the feeling the editor is the problem. Another problem with the editor is that I always need to hit the carriage return twice after inserting the cursor at a certain point, after the first time, nothing happens. Not a big problem but probably not as it should be, and maybe a hint for a deeper problem. Another bug: if the imported data frame contains a µ (greek mu, as in microliter), R can't read the file. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel -- View this message in context: http://www.nabble.com/MacOS-X---R-crashes---import-problem-%28PR-9005%29-tp4933442p21301048.html Sent from the R devel mailing list archive at Nabble.com. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Strange error message
I'm testing out some changes to survreg and got the following output, the
likes of which I've never seen before:
--
R version 2.7.1 (2008-06-23)
Copyright (C) 2008 The R Foundation for Statistical Computing
ISBN 3-900051-07-0
R is free software and comes with ABSOLUTELY NO WARRANTY.
You are welcome to redistribute it under certain conditions.
Type 'license()' or 'licence()' for distribution details.
Natural language support but running in an English locale
R is a collaborative project with many contributors.
Type 'contributors()' for more information and
'citation()' on how to cite R or R packages in publications.
Type 'demo()' for some demos, 'help()' for on-line help, or
'help.start()' for an HTML browser interface to help.
Type 'q()' to quit R.
> source('setup.s')
> source('mktest1.s')
> fit1w <- survreg(Surv(time, status) ~x, test1, dist='weibull')
Warning: stack imbalance in '.Call', 26 then 27
Warning: stack imbalance in '<-', 24 then 25
Warning: stack imbalance in '{', 22 then 23
Warning: stack imbalance in 'if', 20 then 21
Warning: stack imbalance in '.Call', 23 then 24
Warning: stack imbalance in '<-', 21 then 22
Warning: stack imbalance in '{', 18 then 20
Warning: stack imbalance in '<-', 12 then 14
Warning: stack imbalance in 'if', 10 then 12
Warning: stack imbalance in '{', 8 then 10
Warning: stack imbalance in '<-', 2 then 4
> traceback()
No traceback available
--
The "setup" file simply attaches the directory containing my test version of
the survival code, and mktest1.s is
test1 <- data.frame(time= c(4, 3,1,1,2,2,3),
status=c(1,NA,1,0,1,1,0),
x= c(0, 2,1,1,1,0,0))
the simple test data set from the appendix of my book, for which I know ALL the
answers.
There has been a change to the C code. Is this possibly due to a messed up
calling chain? I've converted from "Chambers" style callback to Rinternals
style (much cleaner and less mysterious), and the result works well in Splus.
I thought I'd made it through the hard part
Hints appreciated, after which I can give more details.
Terry Therneau
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Apparant bug in binomial model in GLM (PR#13434)
This is a (too-little) known phenomenon: the problem is the low power of the Wald test in certain circumstances, and not the R implementation. You can look it up in MASS (the book) pp.197-9. Can I ask how you 'knew for certain' what this should do? From the FAQ: But be sure you know for certain what it ought to have done. If you aren't familiar with the command, or don't know for certain how the command is supposed to work, then it might actually be working right. For example, people sometimes think there is a bug in R's mathematics because they don't understand how finite-precision arithmetic works. Rather than jumping to conclusions, show the problem to someone who knows for certain. Who was your authority here? On Tue, 6 Jan 2009, soren.fau...@biology.au.dk wrote: Full_Name: Søren Faurby Version: 2.4.1 and 2.7.2 Neither of which is current. OS: Submission from: (NULL) (192.38.46.92) There appear to be a bug in the estimation of significance in the binomial model in GLM. This bug apparently appears when the correlation between two variables is to strong. Such as this dummy example c(0,0,0,0,0,1,1,1,1,1)->a a->b m1<-glm(a~b, binomial) summary(m1) It is sufficient that all 1's correspond to 1's such as this example c(0,0,0,0,0,1,1,1,1,1)->a c(0,0,0,0,1,1,1,1,1,1)->c m1<-glm(a~c, binomial) summary(m1) I hope that this message is understandable. Kind regards, Søren __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel -- Brian D. Ripley, rip...@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, UKFax: +44 1865 272595__ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Apparant bug in binomial model in GLM (PR#13434)
soren.fau...@biology.au.dk wrote: > Full_Name: Søren Faurby > Version: 2.4.1 and 2.7.2 > OS: > Submission from: (NULL) (192.38.46.92) > > > There appear to be a bug in the estimation of significance in the binomial > model > in GLM. This bug apparently appears when the correlation between two variables > is to strong. > > Such as this dummy example > c(0,0,0,0,0,1,1,1,1,1)->a > a->b > m1<-glm(a~b, binomial) > summary(m1) > > It is sufficient that all 1's correspond to 1's such as this example > > c(0,0,0,0,0,1,1,1,1,1)->a > c(0,0,0,0,1,1,1,1,1,1)->c > m1<-glm(a~c, binomial) > summary(m1) That's not a bug, just the way things work. When the algorithm diverges, as seen by the huge Std.Error, Wald tests (z) are unreliable. (Notice that the log OR in an a vs. c table is infinite whichever way you turn it.) The likelihood ratio test (as in drop1(m1, test="Chisq")) is somewhat less unreliable, but in these small examples, still quite some distance from the table based approaches of fisher.test(a,c) and chisq.test(a,c). > > I hope that this message is understandable. > > Kind regards, Søren > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel -- O__ Peter Dalgaard Øster Farimagsgade 5, Entr.B c/ /'_ --- Dept. of Biostatistics PO Box 2099, 1014 Cph. K (*) \(*) -- University of Copenhagen Denmark Ph: (+45) 35327918 ~~ - (p.dalga...@biostat.ku.dk) FAX: (+45) 35327907 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Strange error message
This indicates that your PROTECTs and UNPROTECTs are out of balance (by
one, looking at the numbers) in the .Call (which I assume is to your own
code?).
On Tue, 6 Jan 2009, Terry Therneau wrote:
I'm testing out some changes to survreg and got the following output, the
likes of which I've never seen before:
--
R version 2.7.1 (2008-06-23)
Copyright (C) 2008 The R Foundation for Statistical Computing
ISBN 3-900051-07-0
R is free software and comes with ABSOLUTELY NO WARRANTY.
You are welcome to redistribute it under certain conditions.
Type 'license()' or 'licence()' for distribution details.
Natural language support but running in an English locale
R is a collaborative project with many contributors.
Type 'contributors()' for more information and
'citation()' on how to cite R or R packages in publications.
Type 'demo()' for some demos, 'help()' for on-line help, or
'help.start()' for an HTML browser interface to help.
Type 'q()' to quit R.
source('setup.s')
source('mktest1.s')
fit1w <- survreg(Surv(time, status) ~x, test1, dist='weibull')
Warning: stack imbalance in '.Call', 26 then 27
Warning: stack imbalance in '<-', 24 then 25
Warning: stack imbalance in '{', 22 then 23
Warning: stack imbalance in 'if', 20 then 21
Warning: stack imbalance in '.Call', 23 then 24
Warning: stack imbalance in '<-', 21 then 22
Warning: stack imbalance in '{', 18 then 20
Warning: stack imbalance in '<-', 12 then 14
Warning: stack imbalance in 'if', 10 then 12
Warning: stack imbalance in '{', 8 then 10
Warning: stack imbalance in '<-', 2 then 4
traceback()
No traceback available
--
The "setup" file simply attaches the directory containing my test version of
the survival code, and mktest1.s is
test1 <- data.frame(time= c(4, 3,1,1,2,2,3),
status=c(1,NA,1,0,1,1,0),
x= c(0, 2,1,1,1,0,0))
the simple test data set from the appendix of my book, for which I know ALL the
answers.
There has been a change to the C code. Is this possibly due to a messed up
calling chain? I've converted from "Chambers" style callback to Rinternals
style (much cleaner and less mysterious), and the result works well in Splus.
I thought I'd made it through the hard part
Hints appreciated, after which I can give more details.
Terry Therneau
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
--
Brian D. Ripley, rip...@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, UKFax: +44 1865 272595
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Strange error message
Brian, Thank you. This explains why it works in Splus: PROTECT is a null macro there, so I wouldn't have caught the miscount. Terry __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
