Re: [Rd] Build directory path saved in Meta/hsearch.rds
On 04/03/06, Prof Brian Ripley <[EMAIL PROTECTED]> wrote: > I've made two changes for R 2.3.0 > > 1) as the LibPath is not actually used, it is recorded as "". (For > compatibility we don't want to remove the field.) Since it was returned > but not printed by help.search(), the actual installed path is returned > instead. (Given that the return format of help.search is undocumented, I > don't see how anyone could have made use of it without realizing it was > subject to guesswork and to change.) > > 2) hsearch.rds could usefully be stored in compressed format, and so will > be. I would like to thank you and Dirk for your answers (and Peter Daalgard FWIW :-). My concern was that R could use that path in some way. Usually this is not a problem because as Brian clearly told that path will be inexistent, the problem would exist if this temporary path could be exploited maliciously to inject code into R. I hope that these concerns don't sound too far fetched since sometimes the temporary directories are world writable. Thank you for the change, I am glad to see that this will be addressed for 2.3. Best regards, -- José Abílio __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] double pointer matrix
CC-ing r-devel for the direct e-mail.
Bernd Kriegstein wrote:
> Hi Hin-Tak,
>
> Thanks for the answer, but it's a little bit
> tangential. Mind you that y is a double pointer,
> commonly used in initialization of matrices. My
> problem is that I cannot eventually access the
> elements of this matrix from within R.
If you write the R code as (sorry, I make a mistake earlier -
you really mean a n*m matrix, not a n*1 one)
y <- double(n*m)
y <- .C("retMat", as.double(y) )[1],
y would *appear* to your C code as a double pointer,
and also would be allocated storage on the R side.
(you don't want to know how and why that is, it
is in the R-extension manual and not very clearly
explained, so you'll just have to try it out and see).
In fact
y <- .C("retMat", double(n*m), ...) [1]
probably would do the job just fine. (note it is
double(n*n), not as.double(...)) - this is allocating on
the way in.
>
> Put another way, do you have any idea about how to
> make a matrix in the C body and then pass it to R
> stack?
I do, but the only way of doing allocation and having it
interacting correctly with
R's garbage collector (i.e. having free() taken care of
automatically), is via the .Call/.External interfaces,
and it gets more complicated - basically you do something like
#include
#include
SEXP retMat(SEXP args)
{
...
PROTECT(y = allocMatrix(REALSXP,n,m)
...
}
and honestly, what I outlined earlier and again is the
simpliest way.
HTL
>
> Thanks for any answers,
>
> - b.
>
> --- Hin-Tak Leung <[EMAIL PROTECTED]>
> schrieb:
>
>
>>Please don't do malloc inside C code like this - it
>>won't interact too
>>well with the garbage collector in R, and your
>>program probably will
>>either leak or crash or both... and when are you
>>going to do your
>>free()?
>>
>>What you want is do is to delete that malloc line
>>and do the
>>allocation on the R side, something like this (the
>>first line does
>>the equivalent of your malloc allocation):
>>
>>y <- double(n)
>>y <- .C("retMat", as.double(y), as.double(n),
>>as.double(m),
>>as.double(a), as.double(b))[1]
>>
>>HTL
>>
>>Bernd Kriegstein wrote:
>>
>>>Hello,
>>>
>>>I'm having some difficulty to understand how I
>>
>>could
>>
>>>take the proper result from the following listing:
>>>
>>>-- cut ---
>>>#include
>>>#include
>>>#include
>>>
>>>void retMat ( double **y, int *n, int *m, double
>>
>>*a,
>>
>>>double *b) {
>>>int i, j;
>>>y = malloc( (*n) * sizeof( double ) );
>>>for (i=0; i<*n; i++) {
>>>y[i] = malloc ( (*m) * sizeof(
>>
>>double
>>
>>>) );
>>>}
>>>
>>>GetRNGstate();
>>>
>>>for (i=0; i<*n; i++) {
>>>for (j=0; j<*m; j++) {
>>>y[i][j] =
>>
>>(i+1)*(j+1)*rbeta(
>>
>>>*a, *b );
>>>}
>>>}
>>>
>>>PutRNGstate();
>>>}
>>>---
>>>I understand that I will have to make the matrix
>>>initialized in the double for loop above to be
>>
>>somehow
>>
>>>visible as a vector, because of the way that the
>>>matrix elements are passed in the argument when
>>
>>used
>>
>>>in the R space. Is there a way to accomplish this?
>>>
>>>Thanks for any answers,
>>>
>>>- b.
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Expanding partial names
Whoops, just noticed that I cut when I should have copied. The newArgs
function should look like this:
newArgs <- function(..., Params) {
f <- function(...) list(...)
formals(f) <- c(Params, formals(f))
names <- as.list(names(Params))
names(names) <- names
names <- lapply(names, as.name)
b <- as.list(body(f))
body(f) <- as.call(c(b[1], names, b[-1]))
f(...)
}
Duncan Murdoch
On 3/7/2006 9:18 PM, Duncan Murdoch wrote:
> Okay, here's my effort based on Deepayan's and Charles' ideas. The
> newArgs function is not what I'd call transparent, but I like the way
> the wrapper looks.
>
> > newArgs <- function(..., Params) {
> + f <- function(...) list(...)
> + formals(f) <- c(Params, formals(f))
>
> + b <- as.list(body(f))
> + body(f) <- as.call(c(b[1], names, b[-1]))
> + f(...)
> + }
> >
> > lowlevel <- function(longname = 1) {
> + cat("longname = ", longname, "\n")
> + }
> >
> > newDefaults <- list(longname=2)
> >
> > wrapper <- function (...)
> + do.call("lowlevel", newArgs(..., Params=newDefaults))
>
> newArgs sets up f to look like
>
> function (longname = 2, ...) list(longname = longname, ...)
>
> and then calls it. The thing I like about this, as opposed to using
> pmatch, is that I'm sure the partial matching is what's used by R's
> argument matching, whereas that's only pretty likely with pmatch.
>
> I also sort of like these lines:
>
> + names <- as.list(names(Params))
> + names(names) <- names
> + names <- lapply(names, as.name)
>
> but maybe I should have named Params as names, so they looked like this:
>
> + names <- as.list(names(names))
> + names(names) <- names
> + names <- lapply(names, as.name)
>
> And of course I like the fact that this seems to work, but we've seen
> several versions that do that:
>
> > wrapper()
> longname = 2
> > wrapper(longname=3)
> longname = 3
> > wrapper(long=3)
> longname = 3
> > wrapper(long=20)
> longname = 20
> > wrapper(junk=20)
> Error in lowlevel(longname = 2, junk = 20) :
> unused argument(s) (junk ...)
>
> Duncan Murdoch
>
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Wishlist - Give R a name that shows up in search engines ...
Indeed, when I was writing code in Java or VBA and I needed code, say to buble sort or invert a CDF, I could find many examples on the web since the user base was so large. R has something better: CRAN. It was really smart to make a central repository where useRs can share code. No other language that I can think of really has an equivalent. All I have to do it search CRAN and I can find 99% of what out there (I'm making a guess on the actual number here). Besides, I don't need to write bubble sort routines anymore because almost everything I need is already built into R. On 3/7/06, Liaw, Andy <[EMAIL PROTECTED]> wrote: > > From: Dirk Eddelbuettel > > > > On 7 March 2006 at 10:55, Hin-Tak Leung wrote: > > | I have given up on "R" with any topic on Google quite some time ago > > | (because bits from fragmented postscript/pdf files show up, for > > | example) - but using "r-devel" with topic normally gives me enough. > > | YMMV. > > > > Nobody seems to have mentioned the RSiteSearch() function > > which automagically restrict the search to domains relevant > > to the contect of "our" use of the letter R. I quite like > > that as I tend to have an R prompt open when I am puzzled by > > R questions ... > > My guess is that people were hoping to find things outside of what Jon > made > available or what's on or linked from www.r-project.org. I believe that's > not going to be very productive (at least for now). I don't think there's > a > whole lot of things related to R that isn't found in those two places. > > Andy > > > Dirk > > > > -- > > Hell, there are no rules here - we're trying to accomplish something. > > -- Thomas A. Edison > > > > __ > > 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 > [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Wishlist - Give R a name that shows up in search engines ...
On 3/8/06, roger bos <[EMAIL PROTECTED]> wrote: > Indeed, when I was writing code in Java or VBA and I needed code, say to > buble sort or invert a CDF, I could find many examples on the web since the > user base was so large. R has something better: CRAN. It was really smart > to make a central repository where useRs can share code. No other language > that I can think of really has an equivalent. All I have to do it search > CRAN and I can find 99% of what out there (I'm making a guess on the actual > number here). Don't forget, there's also life outside CRAN ;) /Henrik > > Besides, I don't need to write bubble sort routines anymore because almost > everything I need is already built into R. > > > > > On 3/7/06, Liaw, Andy <[EMAIL PROTECTED]> wrote: > > > > From: Dirk Eddelbuettel > > > > > > On 7 March 2006 at 10:55, Hin-Tak Leung wrote: > > > | I have given up on "R" with any topic on Google quite some time ago > > > | (because bits from fragmented postscript/pdf files show up, for > > > | example) - but using "r-devel" with topic normally gives me enough. > > > | YMMV. > > > > > > Nobody seems to have mentioned the RSiteSearch() function > > > which automagically restrict the search to domains relevant > > > to the contect of "our" use of the letter R. I quite like > > > that as I tend to have an R prompt open when I am puzzled by > > > R questions ... > > > > My guess is that people were hoping to find things outside of what Jon > > made > > available or what's on or linked from www.r-project.org. I believe that's > > not going to be very productive (at least for now). I don't think there's > > a > > whole lot of things related to R that isn't found in those two places. > > > > Andy > > > > > Dirk > > > > > > -- > > > Hell, there are no rules here - we're trying to accomplish something. > > > -- Thomas A. Edison > > > > > > __ > > > 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 > > > > [[alternative HTML version deleted]] > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel > > -- Henrik Bengtsson Mobile: +46 708 909208 (+1h UTC) __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Wishlist - Give R a name that shows up in search engines ...
On 7 March 2006 at 10:55, Hin-Tak Leung wrote: | I have given up on "R" with any topic on Google quite some time ago | (because bits from fragmented postscript/pdf files show up, for | example) - but using "r-devel" with topic normally gives me enough. | YMMV. I think Google's filetype searching can be very useful. This was discussed on R-help last May. Someone also pointed out that searching in this way would bring up lots of Rebol code, but that's easily weeded out: filetype:R -rebol apply and of the 10 hits (of 12,300) on the first page of results, only 1 points to an R project website. -- Jeffrey Horner Computer Systems Analyst School of Medicine 615-322-8606 Department of Biostatistics Vanderbilt University __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Wishlist - Give R a name that shows up in search engines ...
roger bos wrote: > Indeed, when I was writing code in Java or VBA and I needed code, say to > buble sort or invert a CDF, I could find many examples on the web since > the user base was so large. R has something better: CRAN. It was > really smart to make a central repository where useRs can share code. > No other language that I can think of really has an equivalent. All I > have to do it search CRAN and I can find 99% of what out there (I'm > making a guess on the actual number here). Hang on there - "No other language that I can think of really has an equivalent." - have you heard of CPAN, and CTAN? CRAN was modelled *after* CPAN, which in turn was modelled after CTAN... Either of them is far bigger in size, far older in history, and far more well-established. In fact, I am sorry to say, the search engine of either CPAN or CTAN are better than CRAN's. (this last sentence is subjective, of course). Obviously not a Perl nor TeX user then. (probably not a good idea to express this on r-devel, nevermind) HTL __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Wishlist: Creating horizontal PDFs
It would be nice to easily create horizontal PDF files for standard paper sizes. For example: pdf(file, paper="default", horizontal=TRUE) Currently (R 2.2.1) there is no 'horizontal' argument for the PDF driver. It looks like the only way to create a horizontal PDF is to manually specify width and height. For example: pdf(file, width=11, height=8.5) Does this feature look useful? If so, I may someday try to make the changes (I rarely have the ability to build R). If anyone else wants to make the change, the code for the PDF driver appears to be in R-devel/src/library/grDevices/src/devPS.c The changes should not be hard. FYI...there is a 'horizontal' option for the postscript driver. Kevin Wright [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R started in terminal shell script or ESS steps on LD_LIBRARY_PATH?
Hi all, In follow up to my prior post on this issue, I have found a workaround, but have not yet clearly identified the etiology of the problem. Whatever it is, it is presumably unique to my system, though if anyone can replicate this on another FC4 system... :-) The workaround involves booting to init 3 rather than init 5 and starting X manually from the console. I found this after going through some of the steps described below regarding my X configuration. In this way, LD_LIBRARY_PATH is preserved and RODBC works without issue in both ESS and the gnome-terminal shell start up script. Dirk was kind enough to send me an offlist e-mail yesterday in reply, which sparked some thoughts as I was away from the computer for a few hours yesterday afternoon and evening. Dirk's e-mail logically queried on any issues with gnome-terminal and/or the bash shell itself. Since this problem was new (this had all worked previously), I checked to see if there had been any recent updates to either gnome-terminal or bash in the FC repos. There were none, although there have been of course updates to GNOME, GTK and other libs. This got me to think about other updates since the last known time this process worked properly. So I spent several hours last night and this morning reviewing possibilities. The last Xorg updates are from last September, so these are not new. Other changes that I had made in the recent past include: 1. Modifying my xorg.conf to support nVidia TwinView hardware acceleration functionality. TwinView is like xinerama mode, spanning both displays to give me a virtual 3200x1200 screen, though supporting HW acceleration on both displays. Previously I had been using two X servers (also using the nVidia driver in non-xinerama mode) to support my dual display configuration. Reverting back to the old configuration did not resolve the problem. 2. The last nVidia driver update (8178) was in December and this process had worked since then. 3. There was an updated Cisco VPN client for Linux (4.8) to support recent kernels. The VPN client is installed from source. This normally starts up on boot as a service. Disabling the service, thus removing the kernel module, did not resolve the problem. 4. I had updated the encryption of several of my partitions on my laptop to use dm-crypt/LUKS with 256 bit AES from regular dm-crypt to take advantage of pending LUKS support updates in HAL and other system functions. Disabling the encryption (so the relevant kernel modules did not load), logging in as root and running ESS from root's home did not resolve the problem. 5. Just in case, I also reinstalled kernel version 2.6.15-1.1830 (running 1833 now) to see if there was any change there. No joy. I cannot locate any of the 2.6.14 FC4 kernel versions, as these have been removed from the repos, so it leaves open the possibility of something in the .14 to .15 rebase change. Other than routine system updates via yum, these are the only "self-inflicted" changes that I have made recently. If any of the above should spark some thoughts, let me know. My plans are to live with this for now. FC5 is targeted for release next Wednesday, presuming that it stays on schedule. I'll do a clean install with that and see if anything is resolved, perhaps indicating some other issue that is as yet unidentified. Many thanks to Dirk for your assistance. Best regards, Marc Schwartz __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R started in terminal shell script or ESS steps on LD_LIBRARY_PATH?
This sounds like a shell init issue... and you probably want to hunt down where LD_LIBRARY path is *set*, rather than how it is inherited. When you log in in run-level three, you get a login shell rather than a normal interactive shell, and your startx inherits your login-shell's environment, You get a normal interactive shell(?) inside gnome-terminal/xterm if you start at run-level 5, and finally, you get a non-interactive shell if you run a script, most of the time. The environments in the three cases are all different, and sometimes security related environment variables are not inherited by forked sub-shells, such as LD_LIBRARY_PATH; or more likely, LD_LIBRARY_PATH is set up for the login shell, and other shells simply don't get it. HTL From the INVOCATION part of bash's man page - assuming that's your login shell, otherwise, others. === When bash is invoked as an interactive login shell, or as a non-inter- active shell with the --login option, it first reads and executes com- mands from the file /etc/profile, if that file exists. After reading that file, it looks for ~/.bash_profile, ~/.bash_login, and ~/.profile, in that order, and reads and executes commands from the first one that exists and is readable. The --noprofile option may be used when the shell is started to inhibit this behavior. When a login shell exits, bash reads and executes commands from the file ~/.bash_logout, if it exists. When an interactive shell that is not a login shell is started, bash reads and executes commands from ~/.bashrc, if that file exists. This may be inhibited by using the --norc option. The --rcfile file option will force bash to read and execute commands from file instead of ~/.bashrc. When bash is started non-interactively, to run a shell script, for example, it looks for the variable BASH_ENV in the environment, expands its value if it appears there, and uses the expanded value as the name of a file to read and execute. Bash behaves as if the following com- mand were executed: if [ -n "$BASH_ENV" ]; then . "$BASH_ENV"; fi but the value of the PATH variable is not used to search for the file name. = Marc Schwartz (via MN) wrote: > Hi all, > > In follow up to my prior post on this issue, I have found a workaround, > but have not yet clearly identified the etiology of the problem. > Whatever it is, it is presumably unique to my system, though if anyone > can replicate this on another FC4 system... :-) > > The workaround involves booting to init 3 rather than init 5 and > starting X manually from the console. I found this after going through > some of the steps described below regarding my X configuration. In this > way, LD_LIBRARY_PATH is preserved and RODBC works without issue in both > ESS and the gnome-terminal shell start up script. > > Dirk was kind enough to send me an offlist e-mail yesterday in reply, > which sparked some thoughts as I was away from the computer for a few > hours yesterday afternoon and evening. > > Dirk's e-mail logically queried on any issues with gnome-terminal and/or > the bash shell itself. > > Since this problem was new (this had all worked previously), I checked > to see if there had been any recent updates to either gnome-terminal or > bash in the FC repos. There were none, although there have been of > course updates to GNOME, GTK and other libs. > > This got me to think about other updates since the last known time this > process worked properly. So I spent several hours last night and this > morning reviewing possibilities. > > The last Xorg updates are from last September, so these are not new. > > Other changes that I had made in the recent past include: > > 1. Modifying my xorg.conf to support nVidia TwinView hardware > acceleration functionality. TwinView is like xinerama mode, spanning > both displays to give me a virtual 3200x1200 screen, though supporting > HW acceleration on both displays. Previously I had been using two X > servers (also using the nVidia driver in non-xinerama mode) to support > my dual display configuration. Reverting back to the old configuration > did not resolve the problem. > > 2. The last nVidia driver update (8178) was in December and this process > had worked since then. > > 3. There was an updated Cisco VPN client for Linux (4.8) to support > recent kernels. The VPN client is installed from source. This normally > starts up on boot as a service. Disabling the service, thus removing the > kernel module, did not resolve the problem. > > 4. I had updated the encryption of several of my partitions on my laptop > to use dm-crypt/LUKS with 256 bit AES from regular dm-crypt to take > advantage of pending LUKS support updates in HAL and other system > functions. Disabling the encryption (so the relevant kernel modules did > not load), logging in as root and running ESS from root's home did not > resolve the problem. > > 5. Just in case, I also reinstalled kernel ver
[Rd] Clipboard connections (PR#8668)
Full_Name: Will Gray
Version: R 2.2.1
OS: WinXP SP2
Submission from: (NULL) (160.129.18.69)
I've been using R with a text editor (Tinn-R) and using a feature of the editor
that sends code to a running R session. Sometimes it is convenient to use the
command "source(file('clipboard'))" to send whole blocks of code. However, this
quickly fills up the limit of 50 connections, even if 47 are closed. What does
R hold on to connections it doesn't need, and especially multiple closed
connections to the clipboard? Should this be changed?
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R started in terminal shell script or ESS steps on LD_LIBRARY_PATH?
On Wed, 2006-03-08 at 13:54 -0600, Marc Schwartz wrote: > On Wed, 2006-03-08 at 18:39 +, Hin-Tak Leung wrote: > > This sounds like a shell init issue... and you probably want to hunt > > down where LD_LIBRARY path is *set*, rather than how it is inherited. > > > > When you log in in run-level three, you get a login shell rather than > > a normal interactive shell, and your startx inherits your login-shell's > > environment, You get a normal interactive shell(?) inside > > gnome-terminal/xterm if you start at run-level 5, and finally, you get > > a non-interactive shell if you run a script, most of the time. > > The environments in the three cases are all different, and > > sometimes security related environment variables are not inherited > > by forked sub-shells, such as LD_LIBRARY_PATH; or more likely, > > LD_LIBRARY_PATH is set up for the login shell, and other shells > > simply don't get it. > > > > HTL > > > > From the INVOCATION part of bash's man page - assuming that's your > > login shell, otherwise, others. > > === > > When bash is invoked as an interactive login shell, or as a non-inter- > > active shell with the --login option, it first reads and executes com- > > mands from the file /etc/profile, if that file exists. After reading > > that file, it looks for ~/.bash_profile, ~/.bash_login, and ~/.profile, > > in that order, and reads and executes commands from the first one that > > exists and is readable. The --noprofile option may be used when the > > shell is started to inhibit this behavior. > > > > When a login shell exits, bash reads and executes commands from the > > file ~/.bash_logout, if it exists. > > > > When an interactive shell that is not a login shell is started, bash > > reads and executes commands from ~/.bashrc, if that file exists. This > > may be inhibited by using the --norc option. The --rcfile file option > > will force bash to read and execute commands from file instead of > > ~/.bashrc. > > > > When bash is started non-interactively, to run a shell script, for > > example, it looks for the variable BASH_ENV in the environment, expands > > its value if it appears there, and uses the expanded value as the name > > of a file to read and execute. Bash behaves as if the following com- > > mand were executed: > > if [ -n "$BASH_ENV" ]; then . "$BASH_ENV"; fi > > but the value of the PATH variable is not used to search for the file > > name. > > = > Many thanks for the reply. Given the subject matter feel free to respond offlist with any further replies. I can post back should I figure this out for the sake of closure on the thread. LD_LIBRARY_PATH is set in ~/.bashrc and this has worked fine previously, so I am still unclear as to what has changed. Though I am readily willing to accept that something has been screwed up somehow. Presuming that a system wide setting has been compromised in some fashion, the pending clean install of FC 5 may be helpful. If not, I may need to consider something in my own user profile configuration. I also logged into a KDE session from init 5, to see if perhaps whatever was going on might have been GNOME specific. Unfortunately, the same behavior is seen in KDE using ESS. Two more data points under init 5 in GNOME however: 1. If I open a gnome-terminal console and start R from the CLI, things work. If I exit R and use 'gnome-terminal -x R' within that same console to mimic my startup script, it does not work, even though the variable is clearly set in the console prior to entering the command. However, if from the same initial gnome-terminal console session, I use 'xterm -e R', it works. 2. If I use the "Run Application..." dialogue from the GNOME menu, type in 'R' and check "Run in terminal", it does not work. There is something subtle going on here, that I am just not seeing. Thanks again for taking the time to reply. Best regards, Marc __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Error in return value for as.Date() (PR#8669)
Full_Name: Tom Wainwright
Version: 2.2.1 (2005-12-20 r36812)
OS: Linux (SuSE 9.3)
Submission from: (NULL) (161.55.180.38)
The as.Date function returns erroneous result for certain values using a
day-of-year format. First an example that works (last day of 1970):
> as.Date("1970.365", format="%Y.%j")
[1] "1970-12-31"
Next, a bad example (oops, 1970 wasn't a leap year). Incrementing day by one
moves
date ahead by 2 years 1 month:
> as.Date("1970.366", format="%Y.%j")
[1] "1972-01-31"
> as.Date("1970.366", format="%Y.%j") - as.Date("1970.365", format="%Y.%j")
Time difference of 396 days
The second example should probably return an NA as this is an invalid date.
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R started in terminal shell script or ESS steps on LD_LIBRARY_PATH?
I am _not_ an expert on bash. But as far as I know, .bashrc is not read when you have a login session, whereas .bash_profile is. I have never really understood the deep differences between the two - I only have some superficial understanding. But for my purposes I just have a source .bashrc in my .bash_profile script. In that way I set the same variables no matter what kind of session I have (clearly, I only use .bashrc). There are important differences when you want to run a program at login, but you do not want to run it every time you start up a shell. But simply for setting environment variables, this ought to work. Perhaps this helps? Or perhaps this is something deeper than the simple issue outlined above. /Kasper On Mar 8, 2006, at 1:42 PM, Marc Schwartz (via MN) wrote: > On Wed, 2006-03-08 at 13:54 -0600, Marc Schwartz wrote: >> On Wed, 2006-03-08 at 18:39 +, Hin-Tak Leung wrote: >>> This sounds like a shell init issue... and you probably want to hunt >>> down where LD_LIBRARY path is *set*, rather than how it is >>> inherited. >>> >>> When you log in in run-level three, you get a login shell rather >>> than >>> a normal interactive shell, and your startx inherits your login- >>> shell's >>> environment, You get a normal interactive shell(?) inside >>> gnome-terminal/xterm if you start at run-level 5, and finally, >>> you get >>> a non-interactive shell if you run a script, most of the time. >>> The environments in the three cases are all different, and >>> sometimes security related environment variables are not inherited >>> by forked sub-shells, such as LD_LIBRARY_PATH; or more likely, >>> LD_LIBRARY_PATH is set up for the login shell, and other shells >>> simply don't get it. >>> >>> HTL >>> >>> From the INVOCATION part of bash's man page - assuming that's your >>> login shell, otherwise, others. >>> === >>> When bash is invoked as an interactive login shell, or as a non- >>> inter- >>> active shell with the --login option, it first reads and >>> executes com- >>> mands from the file /etc/profile, if that file exists. After >>> reading >>> that file, it looks for ~/.bash_profile, ~/.bash_login, and >>> ~/.profile, >>> in that order, and reads and executes commands from the first >>> one that >>> exists and is readable. The --noprofile option may be used >>> when the >>> shell is started to inhibit this behavior. >>> >>> When a login shell exits, bash reads and executes commands >>> from the >>> file ~/.bash_logout, if it exists. >>> >>> When an interactive shell that is not a login shell is >>> started, bash >>> reads and executes commands from ~/.bashrc, if that file >>> exists. This >>> may be inhibited by using the --norc option. The --rcfile file >>> option >>> will force bash to read and execute commands from file >>> instead of >>> ~/.bashrc. >>> >>> When bash is started non-interactively, to run a shell >>> script, for >>> example, it looks for the variable BASH_ENV in the environment, >>> expands >>> its value if it appears there, and uses the expanded value as >>> the name >>> of a file to read and execute. Bash behaves as if the >>> following com- >>> mand were executed: >>> if [ -n "$BASH_ENV" ]; then . "$BASH_ENV"; fi >>> but the value of the PATH variable is not used to search for >>> the file >>> name. >>> = >> > > > > > Many thanks for the reply. Given the subject matter feel free to > respond offlist with any further replies. I can post back should I > figure this out for the sake of closure on the thread. > > LD_LIBRARY_PATH is set in ~/.bashrc and this has worked fine > previously, > so I am still unclear as to what has changed. Though I am readily > willing to accept that something has been screwed up somehow. > Presuming > that a system wide setting has been compromised in some fashion, the > pending clean install of FC 5 may be helpful. > > If not, I may need to consider something in my own user profile > configuration. > > I also logged into a KDE session from init 5, to see if perhaps > whatever > was going on might have been GNOME specific. Unfortunately, the same > behavior is seen in KDE using ESS. > > Two more data points under init 5 in GNOME however: > > 1. If I open a gnome-terminal console and start R from the CLI, things > work. If I exit R and use 'gnome-terminal -x R' within that same > console > to mimic my startup script, it does not work, even though the variable > is clearly set in the console prior to entering the command. > However, if > from the same initial gnome-terminal console session, I use 'xterm -e > R', it works. > > 2. If I use the "Run Application..." dialogue from the GNOME menu, > type > in 'R' and check "Run in terminal", it does not work. > > There is something subtle going on here, that I am just not seeing. > > Thanks again for taking the time to reply. > > Best regards, > > Marc > > ___
Re: [Rd] R started in terminal shell script or ESS steps on LD_LIBRARY_PATH?
On Wed, 2006-03-08 at 14:48 -0800, Kasper Daniel Hansen wrote: > I am _not_ an expert on bash. But as far as I know, .bashrc is not > read when you have a login session, whereas .bash_profile is. I have > never really understood the deep differences between the two - I only > have some superficial understanding. But for my purposes I just have a >source .bashrc > in my .bash_profile script. In that way I set the same variables no > matter what kind of session I have (clearly, I only use .bashrc). > > There are important differences when you want to run a program at > login, but you do not want to run it every time you start up a shell. > But simply for setting environment variables, this ought to work. > > Perhaps this helps? Or perhaps this is something deeper than the > simple issue outlined above. > > /Kasper Thanks for the reply Kasper. Two brief notes, so as not to consume further time and bandwidth here: 1. Dirk has just suggested that I edit /etc/ld.so.conf (then run ldconfig). Placing the requisite path into that file works and I'm back to using init 5. RODBC works now. Thanks Dirk! 2. As mentioned this all had worked just recently. My preference is to set up my user profile specifically with any customizations, since this is a single user laptop system. Thus, root's login is clean, when required for other purposes. The default FC4 ~/.bash_profile does call ~/.bashrc, which in turn calls /etc/bashrc. So, presuming that the chain is intact, this should all work, which it had been. I'm still confused as to the nature of the underlying change, but perhaps that will be resolved with a clean install soon. I do sincerely appreciate everyone's time and feedback on this. Sorry for consuming bandwidth here, for what honestly appeared to be an R specific issue. Best regards, Marc __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] bugs in simtest (PR#8670)
# R for Windows will not send your bug report automatically. # Please copy the bug report (after finishing it) to # your favorite email program and send it to # # [EMAIL PROTECTED] # ## This report is joint from Richard Heiberger <[EMAIL PROTECTED]> and Burt Holland <[EMAIL PROTECTED]>. Burt Holland is the coauthor of the paper that the ?ptukey documentation references. R was used to run an example in our elementary Stat course. It was a one-way ANOVA, the factor `strategy' having 3 levels Price, Quality and Convenience. We issued the command summary(simint(sales ~ strategy, type="Tukey", data=Xm15.01s)) and received the output Coefficients: Estimate 2.5 % 97.5 % t value Std.Err. strategyPrice-strategyConvenience 31.10 -40.67 102.87 1.043 29.824 strategyQuality-strategyConvenience75.45 3.68 147.22 2.530 29.824 strategyQuality-strategyPrice 44.35 -27.42 116.12 1.487 29.824 p raw p Bonf p adj strategyPrice-strategyConvenience 0.301 0.904 0.553 strategyQuality-strategyConvenience 0.014 0.043 0.037 strategyQuality-strategyPrice 0.143 0.428 0.305 This gives correct 95% confidence intervals and adjusted p-values for the Tukey multiple comparisons procedure. Next we issued summary(simtest(sales ~ strategy, type="Tukey", data=Xm15.01s)) which produced the output Coefficients: Estimate t value Std.Err. p raw p Bonf strategyQuality-strategyConvenience75.45 -2.530 29.824 0.014 0.043 strategyQuality-strategyPrice 44.35 -1.487 29.824 0.143 0.285 strategyPrice-strategyConvenience 31.10 -1.043 29.824 0.301 0.301 p adj strategyQuality-strategyConvenience 0.037 strategyQuality-strategyPrice 0.243 strategyPrice-strategyConvenience 0.301 Notice that the simtest output gives negative t statistics. This is wrong because the point estimates are positive. The simtest Bonferroni p-values and adjusted p-values differ from the simint values by more than trivial amounts. We are puzzled that the two functions use different conventions on sequencing the contrasts. For levels A,B,C, it looks like simint is using B-A C-A C-B and simtest is using C-A C-B B-A We verify all the p-values from the following code tt <- c(31.10,75.45,44.35)/29.824 tt 2*(1-pt(tt, 57))## raw 3 * (2*(1-pt(tt, 57))) ## Bonferroni 1-ptukey(tt*sqrt(2), 3, 57) ## tukey ## It looks like simtest is using (3:1) * (2*(1-pt(tt[c(2,3,1)], 57))) ## simtest Bonferroni ## The subscript is there to account for the different sequencing. ## The (3:1) multiplier is strange. ## It looks like simtest is using approximately (1-ptukey(tt[c(2,3,1)]*sqrt(2), 3, 57)) / (1+c(0,1,3)*.12)^2 ## We have no idea what that divisor is doing there other than ## approximating the answer that simtest is giving. ## Here is another example, this time using one of your datasets. ## Again, the p.Bonf and p.adj differ. Again, the t.values for the ## simtest have the wrong sign. ## This is from ## c:/Program Files/R/R-2.2.1/library/multcomp/R-ex/Rex.zip/simtest.R > data(cholesterol) > > # adjusted p-values for all-pairwise comparisons in a one-way > # layout (tests for restricted combinations) > simtest(response ~ trt, data=cholesterol, type="Tukey", ttype="logical") Simultaneous tests: Tukey contrasts Call: simtest.formula(formula = response ~ trt, data = cholesterol, type = "Tukey", ttype = "logical") Contrast matrix: trt1time trt2times trt4times trtdrugD trtdrugE trt2times-trt1time 0 -1 1 000 trt4times-trt1time 0 -1 0 100 trtdrugD-trt1time 0 -1 0 010 trtdrugE-trt1time 0 -1 0 001 trt4times-trt2times 00-1 100 trtdrugD-trt2times 00-1 010 trtdrugE-trt2times 00-1 001 trtdrugD-trt4times 00 0-110 trtdrugE-trt4times 00 0-101 trtdrugE-trtdrugD 00 0 0 -11 Adjusted P-Values p adj trtdrugE-trt1time 0.000 trtdrugE-trt2times 0.000 trtdrugD-trt1time 0.000 trtdrugE-trt4times 0.000 trt4times-trt1time 0.000 trtdrugD-trt2times 0.000 trtdrugE-trtdrugD 0.001 trt2times-trt1time 0.042 trt4times-trt2times 0.042 trtdrugD-trt4times 0.044 > > > summary(simtest(response ~ trt, data=cholesterol, type="Tukey", > ttype="logical")) Simultaneous tests: Tukey contrasts Call: simtest.formula(formula = response ~ trt, data = cholesterol, type = "Tukey", ttype = "logical") Tuk
Re: [Rd] Clipboard connections (PR#8668)
This is not a bug, but user error. You are failing to close the
connection. R has no idea you do not subsequently want to use the
connection via getConnection. As the help page ?file and its reference,
and also the R-news article on connections.
The correct usage is either
source("clipboard")
or
zz <- file("clipboard")
source(zz)
close(zz)
BTW, there are no `clipboard connections': there are file connections to
the clipboard on Windows only.
On Wed, 8 Mar 2006, [EMAIL PROTECTED] wrote:
> Full_Name: Will Gray
> Version: R 2.2.1
> OS: WinXP SP2
> Submission from: (NULL) (160.129.18.69)
>
>
> I've been using R with a text editor (Tinn-R) and using a feature of the
> editor
> that sends code to a running R session. Sometimes it is convenient to use the
> command "source(file('clipboard'))" to send whole blocks of code. However,
> this
> quickly fills up the limit of 50 connections, even if 47 are closed. What
> does
> R hold on to connections it doesn't need, and especially multiple closed
> connections to the clipboard? Should this be changed?
>
> __
> 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
Re: [Rd] bugs in simtest (PR#8670)
There is no simtest in R! It appears you are using contributed package multcomp. Please do re-read the FAQ. Bug reports in contributed packages should not be sent to the R-bugs repository, but to the package maintainer. This report has been closed. On Thu, 9 Mar 2006, [EMAIL PROTECTED] wrote: > # R for Windows will not send your bug report automatically. > # Please copy the bug report (after finishing it) to > # your favorite email program and send it to > # > # [EMAIL PROTECTED] > # > ## > > This report is joint from Richard Heiberger <[EMAIL PROTECTED]> > and Burt Holland <[EMAIL PROTECTED]>. > Burt Holland is the coauthor of the paper that the ?ptukey > documentation references. > > > R was used to run an example in our elementary Stat course. It was > a one-way ANOVA, the factor `strategy' having 3 levels Price, Quality > and Convenience. > > We issued the command > > summary(simint(sales ~ strategy, type="Tukey", data=Xm15.01s)) > > and received the output > > Coefficients: >Estimate 2.5 % 97.5 % t value Std.Err. > strategyPrice-strategyConvenience 31.10 -40.67 102.87 1.043 29.824 > strategyQuality-strategyConvenience75.45 3.68 147.22 2.530 29.824 > strategyQuality-strategyPrice 44.35 -27.42 116.12 1.487 29.824 >p raw p Bonf p adj > strategyPrice-strategyConvenience 0.301 0.904 0.553 > strategyQuality-strategyConvenience 0.014 0.043 0.037 > strategyQuality-strategyPrice 0.143 0.428 0.305 > > This gives correct 95% confidence intervals and adjusted p-values for the > Tukey multiple comparisons procedure. > > > > Next we issued > > summary(simtest(sales ~ strategy, type="Tukey", data=Xm15.01s)) > > which produced the output > > Coefficients: >Estimate t value Std.Err. p raw p Bonf > strategyQuality-strategyConvenience75.45 -2.530 29.824 0.014 0.043 > strategyQuality-strategyPrice 44.35 -1.487 29.824 0.143 0.285 > strategyPrice-strategyConvenience 31.10 -1.043 29.824 0.301 0.301 >p adj > strategyQuality-strategyConvenience 0.037 > strategyQuality-strategyPrice 0.243 > strategyPrice-strategyConvenience 0.301 > > Notice that the simtest output gives negative t statistics. This is > wrong because the point estimates are positive. > > The simtest Bonferroni p-values and adjusted p-values differ from the > simint values by more than trivial amounts. > > We are puzzled that the two functions use different conventions on > sequencing the contrasts. For levels A,B,C, it looks like > > simint is using > B-A > C-A > C-B > > and simtest is using > C-A > C-B > B-A > > > We verify all the p-values from the following code > > > tt <- c(31.10,75.45,44.35)/29.824 > tt > > 2*(1-pt(tt, 57))## raw > 3 * (2*(1-pt(tt, 57))) ## Bonferroni >1-ptukey(tt*sqrt(2), 3, 57) ## tukey > > ## It looks like simtest is using > (3:1) * (2*(1-pt(tt[c(2,3,1)], 57))) ## simtest Bonferroni > ## The subscript is there to account for the different sequencing. > ## The (3:1) multiplier is strange. > > ## It looks like simtest is using approximately > (1-ptukey(tt[c(2,3,1)]*sqrt(2), 3, 57)) / (1+c(0,1,3)*.12)^2 > ## We have no idea what that divisor is doing there other than > ## approximating the answer that simtest is giving. > > > > > ## Here is another example, this time using one of your datasets. > ## Again, the p.Bonf and p.adj differ. Again, the t.values for the > ## simtest have the wrong sign. > ## This is from > ## c:/Program Files/R/R-2.2.1/library/multcomp/R-ex/Rex.zip/simtest.R > >> data(cholesterol) >> >> # adjusted p-values for all-pairwise comparisons in a one-way >> # layout (tests for restricted combinations) >> simtest(response ~ trt, data=cholesterol, type="Tukey", ttype="logical") > >Simultaneous tests: Tukey contrasts > > Call: > simtest.formula(formula = response ~ trt, data = cholesterol, >type = "Tukey", ttype = "logical") > > Contrast matrix: > trt1time trt2times trt4times trtdrugD trtdrugE > trt2times-trt1time 0 -1 1 000 > trt4times-trt1time 0 -1 0 100 > trtdrugD-trt1time 0 -1 0 010 > trtdrugE-trt1time 0 -1 0 001 > trt4times-trt2times 00-1 100 > trtdrugD-trt2times 00-1 010 > trtdrugE-trt2times 00-1 001 > trtdrugD-trt4times 00 0-110 > trtdrugE-trt4times 00 0-101 > trtdrugE-trtdrugD 00 0 0 -11 > > Adjusted P-Values > >p adj > trtdrugE-trt1ti
