[Rd] nlme: augPred.lme for factor covariates
Hi everybody,
as you may be aware the function augPred.lme does not work as soon as
the covariate is a factor. The problem lies in the line
newprimary <- seq(from = minimum, to = maximum, length.out = length.out)
which does not make sense for factors. I think augPred.lme can be useful
for models with a factor covariate as well. Thus, I propose to change
the code to:
augPred.lme <- function (object, primary = NULL, minimum = min(primary),
maximum = max(primary),
length.out = 51, level = Q, newprim = NULL, ...)
{
data <- eval(object$call$data)
if (!inherits(data, "data.frame")) {
stop(paste("Data in", substitute(object), "call must evaluate to
a data frame"))
}
if (is.null(primary)) {
if (!inherits(data, "groupedData")) {
stop(paste(sys.call()[[1]], "without \"primary\" can only be
used with fits of groupedData objects"))
}
primary <- getCovariate(data)
prName <- deparse(getCovariateFormula(data)[[2]])
}
else {
primary <- asOneSidedFormula(primary)[[2]]
prName <- deparse(primary)
primary <- eval(primary, data)
}
# allow for non numeric covariates #
if (!is.null(newprim)) {
newprimary <- newprim
} else if (is.numeric(primary)) {
newprimary <- seq(from = minimum, to = maximum, length.out =
length.out)
} else {
warning("'primary' is not numeric. Provide either 'newprim' or
use a numeric primary")
newprimary <- primary
}
[...]
The function now takes an additional parameter newprim. The user thus
can explicitly specify the values based on which the prediction should
be made. Additionally, if the user does not provide newprim and the
primary is not a numeric a warning is issued and the predictions are
based on the original values.
Any feedback appreciated.
BR, Thorn
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] R CMD build wiped my computer
Hi, I ran R (version 2.9.0) CMD build under root in Fedora (9). When it tried to remove "junk files" it removed EVERYTHING in my local account! (See below). Can anyone tell me what happened, and even more importantly if I can I restore what was lost. Panickingly, Jarrod [jar...@localhost AManal]$ R CMD build MCMCglmm_2.05 * checking for file 'MCMCglmm_2.05/DESCRIPTION' ... OK * preparing 'MCMCglmm_2.05': * checking DESCRIPTION meta-information ... OK * cleaning src * installing the package to re-build vignettes * Installing *source* package ?MCMCglmm? ... ** libs g++ -m64 -I/usr/include/R -I/usr/local/include-fpic -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic -c MCMCglmm.cc -o MCMCglmm.o MCMCglmm.cc: In function ?void MCMCglmm(double*, double*, double*, int*, int*, int*, int*, int*, int*, double*, int*, int*, double*, int*, int*, double*, double*, int*, int*, int*, int*, int*, int*, int*, int*, int*, int*, double*, double*, double*, int*, int*, int*, int*, double*, double*, double*, int*, double*, bool*, double*, double*, int*, int*, int*, int*, int*, double*, int*, int*, int*, double*, double*, double*, int*, int*, double*, int*, int*, int*, int*, double*, double*, double*, double*)?: MCMCglmm.cc:228: warning: ?pvLS? may be used uninitialized in this function MCMCglmm.cc:227: warning: ?pvLL? may be used uninitialized in this function MCMCglmm.cc:225: warning: ?Lrv? may be used uninitialized in this function MCMCglmm.cc:225: warning: ?pmuL? may be used uninitialized in this function MCMCglmm.cc:225: warning: ?pvL? may be used uninitialized in this function MCMCglmm.cc:225: warning: ?LambdaX? may be used uninitialized in this function MCMCglmm.cc:225: warning: ?bv_tmp? may be used uninitialized in this function MCMCglmm.cc:225: warning: ?bv? may be used uninitialized in this function MCMCglmm.cc:225: warning: ?A? may be used uninitialized in this function MCMCglmm.cc:86: warning: ?dimG? may be used uninitialized in this function MCMCglmm.cc:228: warning: ?AlphainvS? may be used uninitialized in this function MCMCglmm.cc:227: warning: ?AlphainvL? may be used uninitialized in this function MCMCglmm.cc:225: warning: ?alphalocation_tmp? may be used uninitialized in this function MCMCglmm.cc:225: warning: ?alphalocation? may be used uninitialized in this function MCMCglmm.cc:225: warning: ?alphazstar? may be used uninitialized in this function MCMCglmm.cc:225: warning: ?alphapred? may be used uninitialized in this function MCMCglmm.cc:225: warning: ?alphaastar? may be used uninitialized in this function MCMCglmm.cc:225: warning: ?muAlpha? may be used uninitialized in this function MCMCglmm.cc:225: warning: ?Alphainv? may be used uninitialized in this function MCMCglmm.cc:225: warning: ?tXalpha? may be used uninitialized in this function MCMCglmm.cc:225: warning: ?Xalpha? may be used uninitialized in this function MCMCglmm.cc:225: warning: ?linky_orig? may be used uninitialized in this function MCMCglmm.cc:228: warning: ?tYKrinvYS? may be used uninitialized in this function MCMCglmm.cc:228: warning: ?LambdaS? may be used uninitialized in this function MCMCglmm.cc:227: warning: ?tYKrinvYL? may be used uninitialized in this function MCMCglmm.cc:227: warning: ?LambdaLU? may be used uninitialized in this function MCMCglmm.cc:225: warning: ?tYKrinvY? may be used uninitialized in this function MCMCglmm.cc:225: warning: ?tYKrinv? may be used uninitialized in this function MCMCglmm.cc:225: warning: ?ILY? may be used uninitialized in this function MCMCglmm.cc:225: warning: ?tY? may be used uninitialized in this function MCMCglmm.cc:225: warning: ?Y? may be used uninitialized in this function MCMCglmm.cc:225: warning: ?I? may be used uninitialized in this function MCMCglmm.cc:228: warning: ?alphaS? may be used uninitialized in this function MCMCglmm.cc:225: warning: ?alphaMME? may be used uninitialized in this function MCMCglmm.cc:225: warning: ?alphaM? may be used uninitialized in this function MCMCglmm.cc:225: warning: ?XtmKRinv? may be used uninitialized in this function MCMCglmm.cc:227: warning: ?alphaL? may be used uninitialized in this function MCMCglmm.cc:227: warning: ?L? may be used uninitialized in this function MCMCglmm.cc:225: warning: ?alphaastar_tmp? may be used uninitialized in this function MCMCglmm.cc:225: warning: ?dev? may be used uninitialized in this function MCMCglmm.cc:225: warning: ?astar_tmp? may be used uninitialized in this function MCMCglmm.cc:225: warning: ?Worig? may be used uninitialized in this function gcc -m64 -std=gnu99 -I/usr/include/R -I/usr/local/include-fpic -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic -c cs_add.c -o cs_add.o gcc -m64 -std=gnu99 -I/usr/include/R -I/usr/local/include-fpic -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexcep
Re: [Rd] R CMD build wiped my computer
> Jarrod Hadfield > on Tue, 27 Jul 2010 21:37:09 +0100 writes: > Hi, I ran R (version 2.9.0) CMD build under root in > Fedora (9). When it tried to remove "junk files" it > removed EVERYTHING in my local account! (See below). > Can anyone tell me what happened, the culprit may lay here: >> * removing junk files >> unlink MCMCglmm_2.05/R/ residuals.MCMCglmm.R >> ~ where it seems that someone (you?) have added a newline in the filname, so instead of 'residuals.MCMCglmm.R~' you got 'residuals.MCMCglmm.R ~' and the unlink / rm command interpreted '~' as your home directory. But I can hardly believe it. This seems explanation seems a bit doubtful to me.. ... > and even more importantly if I can I restore what was lost. well, you just get it from the backup. You do daily backups, do you? Regards, Martin Maechler, ETH Zurich > Panickingly, > Jarrod > [jar...@localhost AManal]$ R CMD build MCMCglmm_2.05 > * checking for file 'MCMCglmm_2.05/DESCRIPTION' ... OK > * preparing 'MCMCglmm_2.05': > * checking DESCRIPTION meta-information ... OK > * cleaning src > * installing the package to re-build vignettes > * Installing *source* package ?MCMCglmm? ... > ** libs > g++ -m64 -I/usr/include/R -I/usr/local/include-fpic -O2 -g -pipe > -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector > --param=ssp-buffer-size=4 -m64 -mtune=generic -c MCMCglmm.cc -o > MCMCglmm.o > MCMCglmm.cc: In function ?void MCMCglmm(double*, double*, double*, > int*, int*, int*, int*, int*, int*, double*, int*, int*, double*, > int*, int*, double*, double*, int*, int*, int*, int*, int*, int*, > int*, int*, int*, int*, double*, double*, double*, int*, int*, int*, > int*, double*, double*, double*, int*, double*, bool*, double*, > double*, int*, int*, int*, int*, int*, double*, int*, int*, int*, > double*, double*, double*, int*, int*, double*, int*, int*, int*, > int*, double*, double*, double*, double*)?: > MCMCglmm.cc:228: warning: ?pvLS? may be used uninitialized in this function > MCMCglmm.cc:227: warning: ?pvLL? may be used uninitialized in this function > MCMCglmm.cc:225: warning: ?Lrv? may be used uninitialized in this function > MCMCglmm.cc:225: warning: ?pmuL? may be used uninitialized in this function > MCMCglmm.cc:225: warning: ?pvL? may be used uninitialized in this function > MCMCglmm.cc:225: warning: ?LambdaX? may be used uninitialized in this function > MCMCglmm.cc:225: warning: ?bv_tmp? may be used uninitialized in this function > MCMCglmm.cc:225: warning: ?bv? may be used uninitialized in this function > MCMCglmm.cc:225: warning: ?A? may be used uninitialized in this function > MCMCglmm.cc:86: warning: ?dimG? may be used uninitialized in this function > MCMCglmm.cc:228: warning: ?AlphainvS? may be used uninitialized in > this function > MCMCglmm.cc:227: warning: ?AlphainvL? may be used uninitialized in > this function > MCMCglmm.cc:225: warning: ?alphalocation_tmp? may be used > uninitialized in this function > MCMCglmm.cc:225: warning: ?alphalocation? may be used uninitialized in > this function > MCMCglmm.cc:225: warning: ?alphazstar? may be used uninitialized in > this function > MCMCglmm.cc:225: warning: ?alphapred? may be used uninitialized in > this function > MCMCglmm.cc:225: warning: ?alphaastar? may be used uninitialized in > this function > MCMCglmm.cc:225: warning: ?muAlpha? may be used uninitialized in this function > MCMCglmm.cc:225: warning: ?Alphainv? may be used uninitialized in this > function > MCMCglmm.cc:225: warning: ?tXalpha? may be used uninitialized in this function > MCMCglmm.cc:225: warning: ?Xalpha? may be used uninitialized in this function > MCMCglmm.cc:225: warning: ?linky_orig? may be used uninitialized in > this function > MCMCglmm.cc:228: warning: ?tYKrinvYS? may be used uninitialized in > this function > MCMCglmm.cc:228: warning: ?LambdaS? may be used uninitialized in this function > MCMCglmm.cc:227: warning: ?tYKrinvYL? may be used uninitialized in > this function > MCMCglmm.cc:227: warning: ?LambdaLU? may be used uninitialized in this > function > MCMCglmm.cc:225: warning: ?tYKrinvY? may be used uninitialized in this > function > MCMCglmm.cc:225: warning: ?tYKrinv? may be used uninitialized in this function > MCMCglmm.cc:225: warning: ?ILY? may be used uninitialized in this function > MCMCglmm.cc:225: warning: ?tY? may be used uninitialized in this function > MCMCglmm.cc:225: warning: ?Y? may be used uninitialized in this function > MCMCglmm.cc:225: warning: ?I? may be used uninitialized in this function > MCMCglmm.cc:228: warning: ?alphaS? may be used uninitialized in this function > MCMCglmm.cc
Re: [Rd] R CMD build wiped my computer
Hi Martin, I think this is the most likely reason given that the name in the DESCRIPTION file does NOT have a version number. Even so, it is very easy to misname a file and then delete it/change its name (as I've done here) and I hope current versions of R would not cause this problem. Perhaps Fedora should not use ~ as its back up file suffixes? Cheers, Jarrod On 28 Jul 2010, at 11:41, Martin Maechler wrote: Jarrod Hadfield on Tue, 27 Jul 2010 21:37:09 +0100 writes: Hi, I ran R (version 2.9.0) CMD build under root in Fedora (9). When it tried to remove "junk files" it removed EVERYTHING in my local account! (See below). Can anyone tell me what happened, the culprit may lay here: * removing junk files unlink MCMCglmm_2.05/R/ residuals.MCMCglmm.R ~ where it seems that someone (you?) have added a newline in the filname, so instead of 'residuals.MCMCglmm.R~' you got 'residuals.MCMCglmm.R ~' and the unlink / rm command interpreted '~' as your home directory. But I can hardly believe it. This seems explanation seems a bit doubtful to me.. ... and even more importantly if I can I restore what was lost. well, you just get it from the backup. You do daily backups, do you? Regards, Martin Maechler, ETH Zurich Panickingly, Jarrod [jar...@localhost AManal]$ R CMD build MCMCglmm_2.05 * checking for file 'MCMCglmm_2.05/DESCRIPTION' ... OK * preparing 'MCMCglmm_2.05': * checking DESCRIPTION meta-information ... OK * cleaning src * installing the package to re-build vignettes * Installing *source* package ?MCMCglmm? ... ** libs g++ -m64 -I/usr/include/R -I/usr/local/include-fpic -O2 -g - pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic -c MCMCglmm.cc -o MCMCglmm.o MCMCglmm.cc: In function ?void MCMCglmm(double*, double*, double*, int*, int*, int*, int*, int*, int*, double*, int*, int*, double*, int*, int*, double*, double*, int*, int*, int*, int*, int*, int*, int*, int*, int*, int*, double*, double*, double*, int*, int*, int*, int*, double*, double*, double*, int*, double*, bool*, double*, double*, int*, int*, int*, int*, int*, double*, int*, int*, int*, double*, double*, double*, int*, int*, double*, int*, int*, int*, int*, double*, double*, double*, double*)?: MCMCglmm.cc:228: warning: ?pvLS? may be used uninitialized in this function MCMCglmm.cc:227: warning: ?pvLL? may be used uninitialized in this function MCMCglmm.cc:225: warning: ?Lrv? may be used uninitialized in this function MCMCglmm.cc:225: warning: ?pmuL? may be used uninitialized in this function MCMCglmm.cc:225: warning: ?pvL? may be used uninitialized in this function MCMCglmm.cc:225: warning: ?LambdaX? may be used uninitialized in this function MCMCglmm.cc:225: warning: ?bv_tmp? may be used uninitialized in this function MCMCglmm.cc:225: warning: ?bv? may be used uninitialized in this function MCMCglmm.cc:225: warning: ?A? may be used uninitialized in this function MCMCglmm.cc:86: warning: ?dimG? may be used uninitialized in this function MCMCglmm.cc:228: warning: ?AlphainvS? may be used uninitialized in this function MCMCglmm.cc:227: warning: ?AlphainvL? may be used uninitialized in this function MCMCglmm.cc:225: warning: ?alphalocation_tmp? may be used uninitialized in this function MCMCglmm.cc:225: warning: ?alphalocation? may be used uninitialized in this function MCMCglmm.cc:225: warning: ?alphazstar? may be used uninitialized in this function MCMCglmm.cc:225: warning: ?alphapred? may be used uninitialized in this function MCMCglmm.cc:225: warning: ?alphaastar? may be used uninitialized in this function MCMCglmm.cc:225: warning: ?muAlpha? may be used uninitialized in this function MCMCglmm.cc:225: warning: ?Alphainv? may be used uninitialized in this function MCMCglmm.cc:225: warning: ?tXalpha? may be used uninitialized in this function MCMCglmm.cc:225: warning: ?Xalpha? may be used uninitialized in this function MCMCglmm.cc:225: warning: ?linky_orig? may be used uninitialized in this function MCMCglmm.cc:228: warning: ?tYKrinvYS? may be used uninitialized in this function MCMCglmm.cc:228: warning: ?LambdaS? may be used uninitialized in this function MCMCglmm.cc:227: warning: ?tYKrinvYL? may be used uninitialized in this function MCMCglmm.cc:227: warning: ?LambdaLU? may be used uninitialized in this function MCMCglmm.cc:225: warning: ?tYKrinvY? may be used uninitialized in this function MCMCglmm.cc:225: warning: ?tYKrinv? may be used uninitialized in this function MCMCglmm.cc:225: warning: ?ILY? may be used uninitialized in this function MCMCglmm.cc:225: warning: ?tY? may be used uninitialized in this function MCMCglmm.cc:225: warning: ?Y? may be used uninitialized in this function MCMCglmm.cc:225: warning: ?I? may be used uninitialized in this function MCMCglmm.cc:228: warning: ?alphaS? may be used uninitialized in this function MCMCglmm.cc:225: warning: ?alphaMME? may be
Re: [Rd] Plot window does not update in embedded code
Took a while to find enough time to have a good look at this, but I
have this working now. I am using the for-loop calling the handlers.
Using only R_CheckUserInterrupt() did not work. It was a bit of work
to track down all of the function declarations in R's source.
Thanks!
Regards,
Jan
On Thu, Jul 22, 2010 at 4:06 PM, Simon Urbanek
wrote:
>
> On Jul 22, 2010, at 3:31 AM, Jan van der Laan wrote:
>
>> Thomas, Simon,
>>
>> Thank you for your answers. I will have a look at the code Thomas gave
>> me and probably also have another look at src/unix/sys-std.c. I'll get
>> back when I have this working, or, more likely, when I can't get this
>> to work.
>>
>> As for the example code. I know it is very fragile. I tried to make a
>> minimal complete example that showed the problem without having to
>> attach hundreds of lines of code that nobody will read. However, what
>> parts are unix specific? Is it the int Rf_initialize_R and
>> R_running_as_main_program? What non os specific options do I have?
>>
>
> I was talking about the snippet Thomas sent - not your code - yours was
> nicely minimalistic. The issue with running the handlers by hand is that it's
> unix-only. But as I corrected in my second e-mail - it is the way to go right
> now since there is no alternative at the moment (again, you may get away with
> simply calling R_CheckUserInterrupt() but some devices may be using input
> handlers in which case it is not sufficient). The fact that you can check
> handlers manually is a good thing but it may be worth considering providing
> an API call like R_idle(int timeoutMillis) that does the job across all
> platforms.
>
> Cheers,
> Simon
>
>
>
>> Again thank you for your answers.
>>
>> Regards,
>>
>> Jan
>>
>> On Wed, Jul 21, 2010 at 10:52 PM, Simon Urbanek
>> wrote:
>>>
>>> On Jul 21, 2010, at 4:28 PM, Simon Urbanek wrote:
>>>
Use
R_CheckUserInterrupt()
>>>
>>> Actually, the above is true but assumes that you're running R's REPL and
>>> not your own R_ReadConsole (it will work even in your ReadConsole but unix
>>> handlers are not run in that case so only some events will work).
>>>
>>>
The code below is very fragile and unix-specific.
>>>
>>> That is true, too, but even after R_ProcessEvenrts refactorization the
>>> handlers are still-unix specific so I stand corrected and you still have to
>>> run handlers manually (note that you don't need PolledEvents anymore since
>>> they are part of the handlers).
>>>
>>> Cheers,
>>> Simon
>>>
>>>
>
> On Wednesday 21 July 2010, Jan van der Laan wrote:
>> How do I ensure that the windows keep being updated?
>
> in RKWard we run the following periodically during idle phases:
>
>
> // this basically copied from R's unix/sys-std.c (Rstd_ReadConsole)
> #ifndef Q_WS_WIN
> for (;;) {
> fd_set *what;
> what = R_checkActivityEx(R_wait_usec > 0 ? R_wait_usec : 50,
> 1,
> Rf_onintr);
> R_runHandlers(R_InputHandlers, what);
> if (what == NULL) break;
> }
> /* This seems to be needed to make Rcmdr react to events. Has this
> always
> been the case? It was commented out for a long time, without anybody
> noticing.
> */
> R_PolledEvents ();
> #else
> R_ProcessEvents();
> #endif
>
>
> Regards
> Thomas
> __
> 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
>>>
>>> __
>>> 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
Re: [Rd] R.exe crashes on R v2.12.0dev (Windows Vista)
Hi, by pure luck, I discovered that it has to do with the number of characters (or similar) in the Windows system environment variable 'PATH'. I used a custom PATH when it crashed. When I tried to a plain/fresh Command prompt, the PATH is shorter and then R.exe doesn't crash. This is that working PATH: C:\Program Files\Common Files\Microsoft Shared\Windows Live;c:\Rtools212\bin;c:\Rtools212\perl\bin;c:\Rtools212\MinGW\bin;c:\Rtools\bin;c:\Rtools\perl\bin;c:\Rtools\MinGW\bin;C:\PROGRA~1\GTK2-R~1\bin;C:\Program Files\MiKTeX 2.7\miktex\bin;c:\program files\imagemagick-6.4.2-q16;C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Program Files\Common Files\Lenovo;C:\Program Files\ThinkPad\ConnectUtilities;C:\Program Files\Lenovo\Client Security Solution;C:\Program Files\Microsoft SQL Server\90\Tools\binn\;C:\Program Files\GTK2-Runtime\lib;C:\Program Files\aspell\bin;C:\Program Files\TortoiseSVN\bin;C:\Windows\System32\WindowsPowerShell\v1.0\;C:\Program Files\QuickTime\QTSystem\;C:\Program Files\Common Files\DivX Shared\;C:\Program Files\SlikSvn\bin\;C:\Program Files\ThinkPad\ConnectUtilities\;C:\Program Files\TortoiseSVN\bin;C:\Program Files\Common Files\Microsoft Shared\Windows Live;C:\Program Files\SSH Communications Security\SSH Secure Shell;C:\Users\hb\bin Starting with this PATH and making it longer and longer I can eventually reproduce the crash again. It occurs when my PATH is ~1182 characters long: path C:/1234567890/1234567890/1234567890/1234567890/1234567890/;%PATH% path C:/1234567890/1234567890/1234567890/1234567890/1234567890/;%PATH% path C:/1234567890/1234567890/1234567890/1234567890/1234567890/;%PATH% path C:/1234567890/1234567/;%PATH% echo %PATH% | wc "%ProgramFiles%/R/R-2.12.0dev/bin/i386/R.exe" If I make it a few characters shorter, R.exe starts, but when I do quit() it crashes. Note that there is no problem with Rterm.exe. Thanks /Henrik PS. I've installed Microsoft Debug Diagnostic Tool v1.1 and tried to get something useful out of it without much success. If the above PATH troubleshooting is not enough, I'll spend more time trying to figure out how that tool works. On Mon, Jul 26, 2010 at 5:20 PM, Duncan Murdoch wrote: > On 26/07/2010 10:25 AM, Henrik Bengtsson wrote: >> >> Shame on me; I put important only in the subject line. >> >> It's Windows Vista Business 32-bit (Service Pack 2) English with the >> latest updates. >> > > Oops, didn't notice that. I don't have a Vista machine to test on. I don't > see the crash on a slightly newer build of R on XP SP3 or Windows 7. > > If you know of a debugger that can dump a stack trace at the time of the > crash, that would be helpful information. (We used to use Dr. Watson for > this, but I don't think it works in Vista/Win 7. I've heard of something > called "userdump", but never tried it.) > > Duncan Murdoch >> >> /Henrik >> >> On Mon, Jul 26, 2010 at 1:30 PM, Duncan Murdoch >> wrote: >> > On 26/07/2010 5:15 AM, Henrik Bengtsson wrote: >> >> >> >> Just FYI: Problem remains (on same system) with "R version 2.12.0 >> >> Under development (unstable) (2010-07-21 r52590)": >> >> >> >> Problem signature: >> >> Problem Event Name: APPCRASH >> >> Application Name: R.exe >> >> Application Version: 2.120.52590.0 >> >> Application Timestamp: 4c471362 >> >> Fault Module Name: R.exe >> >> Fault Module Version: 2.120.52590.0 >> >> Fault Module Timestamp: 4c471362 >> >> Exception Code: c005 >> >> Exception Offset: 240e >> >> OS Version: 6.0.6002.2.2.0.256.6 >> > >> > What is your OS? I don't know the MS numbering scheme... >> > >> > Duncan Murdoch >> > >> >> Locale ID: 1033 >> >> Additional Information 1: 8772 >> >> Additional Information 2: 9431192a7274b0ee769861df31ecee58 >> >> Additional Information 3: f768 >> >> Additional Information 4: 930d06d3f6aed4162dca7601993082f5 >> >> >> >> Anyone knows if there anything else I can do to provide more debug >> >> information on this? >> >> >> >> /Henrik >> >> >> >> On Sat, May 22, 2010 at 10:37 AM, Henrik Bengtsson >> >> >> >> wrote: >> >>> >> >>> Using the latest developers version of R [2.12.0 Under development >> >>> (unstable) (2010-05-21 r52061)], R.exe crashes: >> >>> >> >>> "%ProgramFiles%/R/R-2.12.0dev/bin/i386/R.exe" >> >>> >> >>> with Windows reporting: >> >>> >> >>> Problem signature: >> >>> Problem Event Name: APPCRASH >> >>> Application Name: R.exe >> >>> Application Version: 2.120.52061.0 >> >>> Application Timestamp: 4bf638bd >> >>> Fault Module Name: R.exe >> >>> Fault Module Version: 2.120.52061.0 >> >>> Fault Module Timestamp: 4bf638bd >> >>> Exception Code: c005 >> >>> Exception Offset: 1d94 >> >>> OS Version: 6.0.6002.2.2.0.256.6 >> >>> Locale ID: 1033 >> >>> Additional Information 1: 1c1d >> >>> Additional Information 2: e064c795479179a5f08d19e37de8915e >> >>> Additional Information 3: 50ea >> >>> Additional Inform
Re: [Rd] R.exe crashes on R v2.12.0dev (Windows Vista)
On 28/07/2010 9:37 AM, Henrik Bengtsson wrote: Hi, by pure luck, I discovered that it has to do with the number of characters (or similar) in the Windows system environment variable 'PATH'. I used a custom PATH when it crashed. When I tried to a plain/fresh Command prompt, the PATH is shorter and then R.exe doesn't crash. This is that working PATH: Thanks, I can reproduce it now. Should be fixable. Duncan Murdoch C:\Program Files\Common Files\Microsoft Shared\Windows Live;c:\Rtools212\bin;c:\Rtools212\perl\bin;c:\Rtools212\MinGW\bin;c:\Rtools\bin;c:\Rtools\perl\bin;c:\Rtools\MinGW\bin;C:\PROGRA~1\GTK2-R~1\bin;C:\Program Files\MiKTeX 2.7\miktex\bin;c:\program files\imagemagick-6.4.2-q16;C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Program Files\Common Files\Lenovo;C:\Program Files\ThinkPad\ConnectUtilities;C:\Program Files\Lenovo\Client Security Solution;C:\Program Files\Microsoft SQL Server\90\Tools\binn\;C:\Program Files\GTK2-Runtime\lib;C:\Program Files\aspell\bin;C:\Program Files\TortoiseSVN\bin;C:\Windows\System32\WindowsPowerShell\v1.0\;C:\Program Files\QuickTime\QTSystem\;C:\Program Files\Common Files\DivX Shared\;C:\Program Files\SlikSvn\bin\;C:\Program Files\ThinkPad\ConnectUtilities\;C:\Program Files\TortoiseSVN\bin;C:\Program Files\Common Files\Microsoft Shared\Windows Live;C:\Program Files\SSH Communications Security\SSH Secure Shell;C:\Users\hb\bin Starting with this PATH and making it longer and longer I can eventually reproduce the crash again. It occurs when my PATH is ~1182 characters long: path C:/1234567890/1234567890/1234567890/1234567890/1234567890/;%PATH% path C:/1234567890/1234567890/1234567890/1234567890/1234567890/;%PATH% path C:/1234567890/1234567890/1234567890/1234567890/1234567890/;%PATH% path C:/1234567890/1234567/;%PATH% echo %PATH% | wc "%ProgramFiles%/R/R-2.12.0dev/bin/i386/R.exe" If I make it a few characters shorter, R.exe starts, but when I do quit() it crashes. Note that there is no problem with Rterm.exe. Thanks /Henrik PS. I've installed Microsoft Debug Diagnostic Tool v1.1 and tried to get something useful out of it without much success. If the above PATH troubleshooting is not enough, I'll spend more time trying to figure out how that tool works. On Mon, Jul 26, 2010 at 5:20 PM, Duncan Murdoch wrote: > On 26/07/2010 10:25 AM, Henrik Bengtsson wrote: >> >> Shame on me; I put important only in the subject line. >> >> It's Windows Vista Business 32-bit (Service Pack 2) English with the >> latest updates. >> > > Oops, didn't notice that. I don't have a Vista machine to test on. I don't see the crash on a slightly newer build of R on XP SP3 or Windows 7. > > If you know of a debugger that can dump a stack trace at the time of the crash, that would be helpful information. (We used to use Dr. Watson for this, but I don't think it works in Vista/Win 7. I've heard of something called "userdump", but never tried it.) > > Duncan Murdoch >> >> /Henrik >> >> On Mon, Jul 26, 2010 at 1:30 PM, Duncan Murdoch >> wrote: >> > On 26/07/2010 5:15 AM, Henrik Bengtsson wrote: >> >> >> >> Just FYI: Problem remains (on same system) with "R version 2.12.0 >> >> Under development (unstable) (2010-07-21 r52590)": >> >> >> >> Problem signature: >> >> Problem Event Name: APPCRASH >> >> Application Name: R.exe >> >> Application Version: 2.120.52590.0 >> >> Application Timestamp:4c471362 >> >> Fault Module Name:R.exe >> >> Fault Module Version: 2.120.52590.0 >> >> Fault Module Timestamp: 4c471362 >> >> Exception Code: c005 >> >> Exception Offset: 240e >> >> OS Version: 6.0.6002.2.2.0.256.6 >> > >> > What is your OS? I don't know the MS numbering scheme... >> > >> > Duncan Murdoch >> > >> >> Locale ID:1033 >> >> Additional Information 1: 8772 >> >> Additional Information 2: 9431192a7274b0ee769861df31ecee58 >> >> Additional Information 3: f768 >> >> Additional Information 4: 930d06d3f6aed4162dca7601993082f5 >> >> >> >> Anyone knows if there anything else I can do to provide more debug >> >> information on this? >> >> >> >> /Henrik >> >> >> >> On Sat, May 22, 2010 at 10:37 AM, Henrik Bengtsson >> >> wrote: >> >>> >> >>> Using the latest developers version of R [2.12.0 Under development >> >>> (unstable) (2010-05-21 r52061)], R.exe crashes: >> >>> >> >>> "%ProgramFiles%/R/R-2.12.0dev/bin/i386/R.exe" >> >>> >> >>> with Windows reporting: >> >>> >> >>> Problem signature: >> >>> Problem Event Name: APPCRASH >> >>> Application Name: R.exe >> >>> Application Version: 2.120.52061.0 >> >>> Application Timestamp:4bf638bd >> >>> Fault Module Name:R.exe >> >>> Fault Module Version: 2.120.52061.0 >> >>> Fault Module Timestamp: 4bf638bd >> >>> Exception Code: c005 >> >>> Exception Offset: 1d94 >> >>> OS Version: 6.0.6002.2.2.0.256.6 >> >>> Locale ID:1033 >> >>> Additional Information 1: 1c1d >> >>> Additional Information
Re: [Rd] R.exe crashes on R v2.12.0dev (Windows Vista)
On 28/07/2010 11:06 AM, Duncan Murdoch wrote: On 28/07/2010 9:37 AM, Henrik Bengtsson wrote: > Hi, > > by pure luck, I discovered that it has to do with the number of > characters (or similar) in the Windows system environment variable > 'PATH'. I used a custom PATH when it crashed. When I tried to a > plain/fresh Command prompt, the PATH is shorter and then R.exe doesn't > crash. This is that working PATH: > Thanks, I can reproduce it now. Should be fixable. Yes, it was a buffer overflow. I'll commit a change soon. This only affected R-devel, not the current release. Duncan Murdoch Duncan Murdoch > C:\Program Files\Common Files\Microsoft Shared\Windows > Live;c:\Rtools212\bin;c:\Rtools212\perl\bin;c:\Rtools212\MinGW\bin;c:\Rtools\bin;c:\Rtools\perl\bin;c:\Rtools\MinGW\bin;C:\PROGRA~1\GTK2-R~1\bin;C:\Program > Files\MiKTeX 2.7\miktex\bin;c:\program > files\imagemagick-6.4.2-q16;C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Program > Files\Common Files\Lenovo;C:\Program > Files\ThinkPad\ConnectUtilities;C:\Program Files\Lenovo\Client > Security Solution;C:\Program Files\Microsoft SQL > Server\90\Tools\binn\;C:\Program Files\GTK2-Runtime\lib;C:\Program > Files\aspell\bin;C:\Program > Files\TortoiseSVN\bin;C:\Windows\System32\WindowsPowerShell\v1.0\;C:\Program > Files\QuickTime\QTSystem\;C:\Program Files\Common Files\DivX > Shared\;C:\Program Files\SlikSvn\bin\;C:\Program > Files\ThinkPad\ConnectUtilities\;C:\Program > Files\TortoiseSVN\bin;C:\Program Files\Common Files\Microsoft > Shared\Windows Live;C:\Program Files\SSH Communications Security\SSH > Secure Shell;C:\Users\hb\bin > > Starting with this PATH and making it longer and longer I can > eventually reproduce the crash again. It occurs when my PATH is ~1182 > characters long: > > path C:/1234567890/1234567890/1234567890/1234567890/1234567890/;%PATH% > path C:/1234567890/1234567890/1234567890/1234567890/1234567890/;%PATH% > path C:/1234567890/1234567890/1234567890/1234567890/1234567890/;%PATH% > path C:/1234567890/1234567/;%PATH% > echo %PATH% | wc > "%ProgramFiles%/R/R-2.12.0dev/bin/i386/R.exe" > > If I make it a few characters shorter, R.exe starts, but when I do > quit() it crashes. > > Note that there is no problem with Rterm.exe. > > Thanks > > /Henrik > > PS. I've installed Microsoft Debug Diagnostic Tool v1.1 and tried to > get something useful out of it without much success. If the above > PATH troubleshooting is not enough, I'll spend more time trying to > figure out how that tool works. > > > On Mon, Jul 26, 2010 at 5:20 PM, Duncan Murdoch > wrote: > > On 26/07/2010 10:25 AM, Henrik Bengtsson wrote: > >> > >> Shame on me; I put important only in the subject line. > >> > >> It's Windows Vista Business 32-bit (Service Pack 2) English with the > >> latest updates. > >> > > > > Oops, didn't notice that. I don't have a Vista machine to test on. I don't see the crash on a slightly newer build of R on XP SP3 or Windows 7. > > > > If you know of a debugger that can dump a stack trace at the time of the crash, that would be helpful information. (We used to use Dr. Watson for this, but I don't think it works in Vista/Win 7. I've heard of something called "userdump", but never tried it.) > > > > Duncan Murdoch > >> > >> /Henrik > >> > >> On Mon, Jul 26, 2010 at 1:30 PM, Duncan Murdoch > >> wrote: > >> > On 26/07/2010 5:15 AM, Henrik Bengtsson wrote: > >> >> > >> >> Just FYI: Problem remains (on same system) with "R version 2.12.0 > >> >> Under development (unstable) (2010-07-21 r52590)": > >> >> > >> >> Problem signature: > >> >> Problem Event Name: APPCRASH > >> >> Application Name: R.exe > >> >> Application Version: 2.120.52590.0 > >> >> Application Timestamp:4c471362 > >> >> Fault Module Name:R.exe > >> >> Fault Module Version: 2.120.52590.0 > >> >> Fault Module Timestamp: 4c471362 > >> >> Exception Code: c005 > >> >> Exception Offset: 240e > >> >> OS Version: 6.0.6002.2.2.0.256.6 > >> > > >> > What is your OS? I don't know the MS numbering scheme... > >> > > >> > Duncan Murdoch > >> > > >> >> Locale ID:1033 > >> >> Additional Information 1: 8772 > >> >> Additional Information 2: 9431192a7274b0ee769861df31ecee58 > >> >> Additional Information 3: f768 > >> >> Additional Information 4: 930d06d3f6aed4162dca7601993082f5 > >> >> > >> >> Anyone knows if there anything else I can do to provide more debug > >> >> information on this? > >> >> > >> >> /Henrik > >> >> > >> >> On Sat, May 22, 2010 at 10:37 AM, Henrik Bengtsson > >> >> wrote: > >> >>> > >> >>> Using the latest developers version of R [2.12.0 Under development > >> >>> (unstable) (2010-05-21 r52061)], R.exe crashes: > >> >>> > >> >>> "%ProgramFiles%/R/R-2.12.0dev/bin/i386/R.exe" > >> >>> > >> >>> with Windows reporting: > >> >>> > >> >>> Problem signature: > >> >>> Problem Event Name: APPCRASH > >> >>> Application Name: R.exe > >> >>> Application Version: 2.120.
Re: [Rd] R.exe crashes on R v2.12.0dev (Windows Vista)
On Wed, Jul 28, 2010 at 6:24 PM, Duncan Murdoch wrote: > On 28/07/2010 11:06 AM, Duncan Murdoch wrote: >> >> On 28/07/2010 9:37 AM, Henrik Bengtsson wrote: >> > Hi, >> > >> > by pure luck, I discovered that it has to do with the number of >> > characters (or similar) in the Windows system environment variable >> > 'PATH'. I used a custom PATH when it crashed. When I tried to a >> > plain/fresh Command prompt, the PATH is shorter and then R.exe doesn't >> > crash. This is that working PATH: >> > >> Thanks, I can reproduce it now. Should be fixable. >> > > Yes, it was a buffer overflow. I'll commit a change soon. Duncan, thanks for fixing. /Henrik > > This only affected R-devel, not the current release. > > Duncan Murdoch >> >> Duncan Murdoch >> > C:\Program Files\Common Files\Microsoft Shared\Windows >> > >> > Live;c:\Rtools212\bin;c:\Rtools212\perl\bin;c:\Rtools212\MinGW\bin;c:\Rtools\bin;c:\Rtools\perl\bin;c:\Rtools\MinGW\bin;C:\PROGRA~1\GTK2-R~1\bin;C:\Program >> > Files\MiKTeX 2.7\miktex\bin;c:\program >> > >> > files\imagemagick-6.4.2-q16;C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Program >> > Files\Common Files\Lenovo;C:\Program >> > Files\ThinkPad\ConnectUtilities;C:\Program Files\Lenovo\Client >> > Security Solution;C:\Program Files\Microsoft SQL >> > Server\90\Tools\binn\;C:\Program Files\GTK2-Runtime\lib;C:\Program >> > Files\aspell\bin;C:\Program >> > >> > Files\TortoiseSVN\bin;C:\Windows\System32\WindowsPowerShell\v1.0\;C:\Program >> > Files\QuickTime\QTSystem\;C:\Program Files\Common Files\DivX >> > Shared\;C:\Program Files\SlikSvn\bin\;C:\Program >> > Files\ThinkPad\ConnectUtilities\;C:\Program >> > Files\TortoiseSVN\bin;C:\Program Files\Common Files\Microsoft >> > Shared\Windows Live;C:\Program Files\SSH Communications Security\SSH >> > Secure Shell;C:\Users\hb\bin >> > >> > Starting with this PATH and making it longer and longer I can >> > eventually reproduce the crash again. It occurs when my PATH is ~1182 >> > characters long: >> > >> > path C:/1234567890/1234567890/1234567890/1234567890/1234567890/;%PATH% >> > path C:/1234567890/1234567890/1234567890/1234567890/1234567890/;%PATH% >> > path C:/1234567890/1234567890/1234567890/1234567890/1234567890/;%PATH% >> > path C:/1234567890/1234567/;%PATH% >> > echo %PATH% | wc >> > "%ProgramFiles%/R/R-2.12.0dev/bin/i386/R.exe" >> > >> > If I make it a few characters shorter, R.exe starts, but when I do >> > quit() it crashes. >> > >> > Note that there is no problem with Rterm.exe. >> > >> > Thanks >> > >> > /Henrik >> > >> > PS. I've installed Microsoft Debug Diagnostic Tool v1.1 and tried to >> > get something useful out of it without much success. If the above >> > PATH troubleshooting is not enough, I'll spend more time trying to >> > figure out how that tool works. >> > >> > >> > On Mon, Jul 26, 2010 at 5:20 PM, Duncan Murdoch >> > wrote: >> > > On 26/07/2010 10:25 AM, Henrik Bengtsson wrote: >> > >> >> > >> Shame on me; I put important only in the subject line. >> > >> >> > >> It's Windows Vista Business 32-bit (Service Pack 2) English with the >> > >> latest updates. >> > >> >> > > >> > > Oops, didn't notice that. I don't have a Vista machine to test on. I >> > > don't see the crash on a slightly newer build of R on XP SP3 or Windows >> > > 7. >> > > >> > > If you know of a debugger that can dump a stack trace at the time of >> > > the crash, that would be helpful information. (We used to use Dr. Watson >> > > for this, but I don't think it works in Vista/Win 7. I've heard of >> > > something called "userdump", but never tried it.) >> > > >> > > Duncan Murdoch >> > >> >> > >> /Henrik >> > >> >> > >> On Mon, Jul 26, 2010 at 1:30 PM, Duncan Murdoch >> > >> wrote: >> > >> > On 26/07/2010 5:15 AM, Henrik Bengtsson wrote: >> > >> >> >> > >> >> Just FYI: Problem remains (on same system) with "R version 2.12.0 >> > >> >> Under development (unstable) (2010-07-21 r52590)": >> > >> >> >> > >> >> Problem signature: >> > >> >> Problem Event Name: APPCRASH >> > >> >> Application Name: R.exe >> > >> >> Application Version: 2.120.52590.0 >> > >> >> Application Timestamp: 4c471362 >> > >> >> Fault Module Name: R.exe >> > >> >> Fault Module Version: 2.120.52590.0 >> > >> >> Fault Module Timestamp: 4c471362 >> > >> >> Exception Code: c005 >> > >> >> Exception Offset: 240e >> > >> >> OS Version: 6.0.6002.2.2.0.256.6 >> > >> > >> > >> > What is your OS? I don't know the MS numbering scheme... >> > >> > >> > >> > Duncan Murdoch >> > >> > >> > >> >> Locale ID: 1033 >> > >> >> Additional Information 1: 8772 >> > >> >> Additional Information 2: 9431192a7274b0ee769861df31ecee58 >> > >> >> Additional Information 3: f768 >> > >> >> Additional Information 4: 930d06d3f6aed4162dca7601993082f5 >> > >> >> >> > >> >> Anyone knows if there anything else I can do to provide more debug >> > >> >> information on this? >> > >> >> >> > >> >> /Henrik >> > >> >> >> > >> >> O
Re: [Rd] problem with zero-weighted observations in predict.lm?
Peter Dalgaard wrote: > William Dunlap wrote: >> In modelling functions some people like to use >> a weight of 0 to drop an observation instead of >> using a subset value of FALSE. E.g., >> weights=c(0,1,1,...) >> instead of >> subset=c(FALSE, TRUE, TRUE, ...) >> to drop the first observation. >> >> lm() and summary.lm() appear to treat these in the >> same way, decrementing the number of degrees of >> freedom for each dropped observation. However, >> predict.lm() does not treat them the same. It >> doesn't seem to diminish the df to account for the >> 0-weighted observations. E.g., the last printout >> from the following script is as follows, where >> predw is the prediction from the fit that used >> 0-weights and preds is from using FALSE's in the >> subset argument. Is this difference proper? > > Nice catch. > > The issue is that the subset fit and the zero-weighted fit are not > completely the same. Notice that the residuals vector has different > length in the two analyses. With a simplified setup: > >> length(lm(y~1,weights=w)$residuals) > [1] 10 >> length(lm(y~1,subset=-1)$residuals) > [1] 9 >> w > [1] 0 1 1 1 1 1 1 1 1 1 > > This in turn is what confuses predict.lm because it gets n and residual > df from length(object$residuals). summary.lm() uses NROW(Qr$qr), and I > suppose that predict.lm should follow suit. > ...and then when I went to fix it, I found that the actual line in the sources (stats/R/lm.R) reads 27442 ripley n <- length(object$residuals) # NROW(object$qr$qr) so it's been like that since December 2003. I wonder if Brian remembers what the point was? (27442 was the restructuring into the stats package, so it might not actually be Brian's code). -pd -- Peter Dalgaard Center for Statistics, Copenhagen Business School Phone: (+45)38153501 Email: pd@cbs.dk Priv: pda...@gmail.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] problem with zero-weighted observations in predict.lm?
On Thu, 29 Jul 2010, Peter Dalgaard wrote: Peter Dalgaard wrote: William Dunlap wrote: In modelling functions some people like to use a weight of 0 to drop an observation instead of using a subset value of FALSE. E.g., weights=c(0,1,1,...) instead of subset=c(FALSE, TRUE, TRUE, ...) to drop the first observation. lm() and summary.lm() appear to treat these in the same way, decrementing the number of degrees of freedom for each dropped observation. However, predict.lm() does not treat them the same. It doesn't seem to diminish the df to account for the 0-weighted observations. E.g., the last printout from the following script is as follows, where predw is the prediction from the fit that used 0-weights and preds is from using FALSE's in the subset argument. Is this difference proper? Nice catch. The issue is that the subset fit and the zero-weighted fit are not completely the same. Notice that the residuals vector has different length in the two analyses. With a simplified setup: length(lm(y~1,weights=w)$residuals) [1] 10 length(lm(y~1,subset=-1)$residuals) [1] 9 w [1] 0 1 1 1 1 1 1 1 1 1 This in turn is what confuses predict.lm because it gets n and residual df from length(object$residuals). summary.lm() uses NROW(Qr$qr), and I suppose that predict.lm should follow suit. ...and then when I went to fix it, I found that the actual line in the sources (stats/R/lm.R) reads 27442 ripley n <- length(object$residuals) # NROW(object$qr$qr) so it's been like that since December 2003. I wonder if Brian remembers what the point was? (27442 was the restructuring into the stats package, so it might not actually be Brian's code). At least that wasn't the point of change: the code was the same in R 1.8.1 (pre-split). I think you will find that 'n' is used in several ways in predict.lm, and since NA-handling was introduced in R 1.8.0 they may differ in value. So the safest route seems to be to change just 'n' in df <- n - p -- 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
