[Rd] Help with OS X (BSD) ps command
My fame package has a function that checks to see if a FAME SERVER process is
already running. On Linux, I can do this in one of two ways:
pid <- Sys.getpid()
user <- Sys.info()["user"]
cmd <- paste("pgrep -fU", user, "-P", pid, "'FAME SERVER'")
fameRunning <- as.logical(length(system(cmd, intern = T)))
or I can use
cmd <- paste("ps -ef | grep", user, "| grep", pid,
"| grep -v grep | grep -c 'FAME SERVER'")
fameRunning <- as.logical(as.numeric(system(cmd, intern = T)))
Mac OS X does not have pgrep, and being a BSD derivative, takes different
arguments for the 'ps' command. I don't have access to a BSD machine. Can
someone who does tell me the correct invocation of 'ps' to see if 'user' is
running a 'FAME SERVER' process with the R process as its parent process?
Please don't tell me how to get pgrep for OS X, as my objective here is to
stop the CRAN test machine from complaining about my invalid ps command.
While FAME is not officially supported on OS X, I am told that it can be made
to work there. Had I not heard this, of course, I could just answer FALSE for
OS X and be done with it.
--
Jeff
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Help with OS X (BSD) ps command
Most systems do not have pgrep: it is not POSIX. From Linux:
STANDARDS
pkill and pgrep were introduced in Sun's Solaris 7. This
implementation is fully
compatible.
The man pages of Darwin and many other systems are online, and linked from
developer.r-project.org. You could do what the R developers do, and look
at them.
However, you seem not to have looked on your own system, as my Linux 'ps'
man page tells me the BSD syntax, and I can test it on Linux's 'ps'. I
guess you want 'ps ux'.
On Fri, 2 Feb 2007, Jeffrey J. Hallman wrote:
> My fame package has a function that checks to see if a FAME SERVER process is
> already running. On Linux, I can do this in one of two ways:
>
> pid <- Sys.getpid()
> user <- Sys.info()["user"]
>
> cmd <- paste("pgrep -fU", user, "-P", pid, "'FAME SERVER'")
> fameRunning <- as.logical(length(system(cmd, intern = T)))
>
> or I can use
>
> cmd <- paste("ps -ef | grep", user, "| grep", pid,
> "| grep -v grep | grep -c 'FAME SERVER'")
> fameRunning <- as.logical(as.numeric(system(cmd, intern = T)))
>
> Mac OS X does not have pgrep, and being a BSD derivative, takes different
> arguments for the 'ps' command. I don't have access to a BSD machine. Can
> someone who does tell me the correct invocation of 'ps' to see if 'user' is
> running a 'FAME SERVER' process with the R process as its parent process?
>
> Please don't tell me how to get pgrep for OS X, as my objective here is to
> stop the CRAN test machine from complaining about my invalid ps command.
>
> While FAME is not officially supported on OS X, I am told that it can be made
> to work there. Had I not heard this, of course, I could just answer FALSE for
> OS X and be done with it.
>
>
--
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] SEXP i/o, .Call(), and garbage collection.
K. B. Udaya wrote: > Apologies for any obtuseness in the following. We have been working > on Version 2.0 of the randomSurvivalForest CRAN package and we're > encountering a perplexing 'memory not mapped' segfault that we believe > is "influenced" by GC. [...] > We are wondering if there is something fundamentally missing in our > understanding of the interaction between R and C via SEXP objects, > memory allocation, persistency, and any potential garbage collection > that may be occurring. Any comments would be greatly appreciated. > > Our environment is as follows, though we have seen the same behaviour > on an SGI Altix system, a Mac OS X (Intel) system, and with R 2.3.0: If you can run your code on linux (x86, amd64, ppc32, or ppc64), then consider using valgrind for catching memory access problems. You would need to recompile R with debugging support (-g) and it would be best to compile without optimizations (although -O1 seems to be tolerated). And running R within valgrind is as simple as: R -d valgrind --vanilla < script.R or even interactively with: R -d valgrind Best, Jeff -- http://biostat.mc.vanderbilt.edu/JeffreyHorner __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Inaccuracy in ?convolve
Hi, Man page for 'convolve' says: conj: logical; if 'TRUE', take the complex _conjugate_ before back-transforming (default, and used for usual convolution). The complex conjugate of 'x', of 'y', of both? In fact it seems that it takes the complex conjugate of 'y' only which is OK but might be worth mentioning because (1) conj=TRUE is the default and (2) with this default then convolve(x,y) is not the same as convolve(y,x). Note that 'convolve' is commutative with conj=FALSE and would be too if conj=TRUE was taking the complex conjugate of x _and_ y... Cheers, H. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] convolve: request for "usual" behaviour + some improvements + some fixes
Hi again,
There are many problems with current 'convolve' function.
The author of the man page seems to be aware that 'convolve' does _not_ the
usual thing:
Note that the usual definition of convolution of two sequences 'x'
and 'y' is given by 'convolve(x, rev(y), type = "o")'.
and indeed, it does not:
> x <- 1:3
> y <- 3:1
> convolve(x, y, type="o")
[1] 1 4 10 12 9
The "usual" convolution would rather give:
> convolve(x, rev(y), type="o")
[1] 3 8 14 8 3
Also the "usual" convolution is commutative:
> convolve(y, rev(x), type="o")
[1] 3 8 14 8 3
but convolve is not:
> convolve(y, x, type="o")
[1] 9 12 10 4 1
Of course I could write the following wrapper:
usual_convolve <- function(x, y, ...) convolve(x, rev(y))
to work around those issues but 'convolve' has other problems:
(1) The input sequences shouldn't need to have the same length when
type = "circular" (the shortest can be right-padded with 0s up
to the length of the longest).
(2) If the input sequences are both integer vectors, then the result
should be an integer vector too.
(3) The "filter" feature seems to be broken (it's not even clear
what it should do or why we need it though):
> x <- 1:9
> y <- 1
> convolve(x, y, type="f")
Error in convolve(x, y, type = "f") : subscript out of bounds
> convolve(y, x, type="f")
numeric(0)
(4) If you look at the source code, you'll see that 'x' is first left-padded
with '0's. The "usual" convolution doesn't do that: it always padd
sequences on the _same_ side (generally on the right).
(5) It's not clear why we need a 'conj' arg. All what it does is
take the conjugate of fft(y) before it does the product with fft(x).
But this has the "non-usual" effect of reverting the expected result:
> round(convolve(as.integer(c(0,0,0,1)), 1:7, type="o"))
[1] 0 0 0 7 6 5 4 3 2 1
Here below is my version of 'convolve' just in case. It does the "usual"
convolution plus:
- no need to have 'x' and 'y' of the same length when 'type' is "circular",
- when 'x' and 'y' are integer vectors, the output is an integer vector,
- no more 'conj' arg (not needed, only leads to confusion),
- when type is "filter", the output sequence is the same as with
type="open" but is truncated to the length of 'x' (the original signal)
It can be seen has the result of 'x' filtered by 'y' (the filter).
convolve2 <- function(x, y, type = c("circular", "open", "filter"))
{
type <- match.arg(type)
nx <- length(x)
ny <- length(y)
if (type == "circular")
nz <- max(nx, ny)
else
nz <- nx + ny - 1
if (nz > nx)
x[(nx+1):nz] <- as.integer(0)
if (nz > ny)
y[(ny+1):nz] <- as.integer(0)
fx <- fft(x)
fy <- fft(y)
fz <- fx * fy
z <- fft(fz, inverse=TRUE) / nz
if (is.numeric(x) && is.numeric(y))
z <- Re(z)
if (is.integer(x) && is.integer(y))
z <- as.integer(round(z))
if (type == "filter")
z[1:nx]
else
z
}
Cheers,
H.
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] convolve: request for "usual" behaviour + some improvements + some fixes
Last but not least: convolve2 can be made 100 times or 1000 times faster
than convolve by choosing a power of 2 for the length of the fft-buffer
(a length of 2^n is the best case for the fft, the worst case being when
the length is a prime number):
> x <- 1:13
> y <- 1:1
> system.time(cc <- convolve(x, y, type="o")) # uses buffer length of 13
user system elapsed
76.428 0.016 76.445
> system.time(cc <- convolve2(x, y, type="o")) # uses buffer length of 2^17
user system elapsed
0.164 0.012 0.179
Here is the modified 'convolve2':
convolve2 <- function(x, y, type = c("circular", "open", "filter"))
{
type <- match.arg(type)
nx <- length(x)
ny <- length(y)
if (type == "circular") {
nz <- max(nx, ny)
} else {
nz0 <- nx + ny - 1
nz <- 2^ceiling(log2(nz0))
}
if (nz > nx)
x[(nx+1):nz] <- as.integer(0)
if (nz > ny)
y[(ny+1):nz] <- as.integer(0)
fz <- fft(x) * fft(y)
z <- fft(fz, inverse=TRUE) / nz
if (type == "open") {
z <- z[1:nz0]
} else {
if (type == "filter")
z <- z[1:nx]
}
if (is.numeric(x) && is.numeric(y))
z <- Re(z)
if (is.integer(x) && is.integer(y))
z <- as.integer(round(z))
z
}
In fact, it should try to be smarter than that and not use the fft at all
when one of the 2 input sequences is very short (less than 3 or 4) or
e.g. when one is 1 times shorter than the other one.
Cheers,
H.
Herve Pages wrote:
> Hi again,
>
> There are many problems with current 'convolve' function.
> The author of the man page seems to be aware that 'convolve' does _not_ the
> usual thing:
>
> Note that the usual definition of convolution of two sequences 'x'
> and 'y' is given by 'convolve(x, rev(y), type = "o")'.
>
> and indeed, it does not:
>
> > x <- 1:3
> > y <- 3:1
> > convolve(x, y, type="o")
> [1] 1 4 10 12 9
>
> The "usual" convolution would rather give:
>
> > convolve(x, rev(y), type="o")
> [1] 3 8 14 8 3
>
> Also the "usual" convolution is commutative:
>
> > convolve(y, rev(x), type="o")
> [1] 3 8 14 8 3
>
> but convolve is not:
>
> > convolve(y, x, type="o")
> [1] 9 12 10 4 1
>
> Of course I could write the following wrapper:
>
> usual_convolve <- function(x, y, ...) convolve(x, rev(y))
>
> to work around those issues but 'convolve' has other problems:
>
> (1) The input sequences shouldn't need to have the same length when
> type = "circular" (the shortest can be right-padded with 0s up
> to the length of the longest).
> (2) If the input sequences are both integer vectors, then the result
> should be an integer vector too.
> (3) The "filter" feature seems to be broken (it's not even clear
> what it should do or why we need it though):
> > x <- 1:9
> > y <- 1
> > convolve(x, y, type="f")
> Error in convolve(x, y, type = "f") : subscript out of bounds
> > convolve(y, x, type="f")
> numeric(0)
> (4) If you look at the source code, you'll see that 'x' is first left-padded
> with '0's. The "usual" convolution doesn't do that: it always padd
> sequences on the _same_ side (generally on the right).
> (5) It's not clear why we need a 'conj' arg. All what it does is
> take the conjugate of fft(y) before it does the product with fft(x).
> But this has the "non-usual" effect of reverting the expected result:
> > round(convolve(as.integer(c(0,0,0,1)), 1:7, type="o"))
> [1] 0 0 0 7 6 5 4 3 2 1
>
> Here below is my version of 'convolve' just in case. It does the "usual"
> convolution plus:
> - no need to have 'x' and 'y' of the same length when 'type' is "circular",
> - when 'x' and 'y' are integer vectors, the output is an integer vector,
> - no more 'conj' arg (not needed, only leads to confusion),
> - when type is "filter", the output sequence is the same as with
> type="open" but is truncated to the length of 'x' (the original signal)
> It can be seen has the result of 'x' filtered by 'y' (the filter).
>
> convolve2 <- function(x, y, type = c("circular", "open", "filter"))
> {
> type <- match.arg(type)
> nx <- length(x)
> ny <- length(y)
> if (type == "circular")
> nz <- max(nx, ny)
> else
> nz <- nx + ny - 1
> if (nz > nx)
> x[(nx+1):nz] <- as.integer(0)
> if (nz > ny)
> y[(ny+1):nz] <- as.integer(0)
> fx <- fft(x)
> fy <- fft(y)
> fz <- fx * fy
> z <- fft(fz, inverse=TRUE) / nz
> if (is.numeric(x) && is.numeric(y))
> z <- Re(z)
> if (is.integer(x) && is.integer(y))
> z <- as.integer(round(z))
> if (type == "filter")
> z[1:nx]
> else
> z
> }
>
> Cheers,
> H.
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>
___
