similar to: mvfft

This message is in MIME format --_=XFMail.1.3.p0.Linux:990422185944:4782=_ Content-Type: text/plain; charset=us-ascii R-0.64.0 on RedHat Linux 5.1 Some problems with multivariate fast fourier transform. I have attached the dump of a 30 x 3 matrix that seems to reliably reproduce these problems 1) mvfft doesn't like vectors. It complains about not having enough memory: R>

Hi All, I found "mvfft" in R and "fft2" in Matlab give different result and can't figure out why. My example is: In R: > matrix(c(1,4,2,20), nrow=2) [,1] [,2] [1,] 1 2 [2,] 4 20 > mvfft(matrix(c(1,4,2,20), nrow=2)) [,1] [,2] [1,] 5+0i 22+0i [2,] -3+0i -18+0i In Matlab: >fft2([1,2;4,20]) ans= 27 -17 -21 15 Does any function in R

Dear all, I have an image that I need to filter, and so I'm looking for a method to convolve it with a matrix. If I understood the docs for convolve correctly, it only works in 1D (and I have tried to convolve, it didn't look good). So, I wondered if anybody have implemented 2D convolution in R, or have any good advices to share (beyond having a look at mvfft), before I go hacking?

Dear all, I am trying to upgrade R-1.6.2 to R-1.7.0 on an SGI running IRIX6.5. Everything compiles but I get an error in the testing phase: [snip] running regression tests make[3]: Entering directory `/usr/local/src/R-1.7.0/tests' running code in 'reg-tests-1.R' ...make[3]: *** [reg-tests-1.Rout] Error 1 make[3]: Leaving directory `/usr/local/src/R-1.7.0/tests' make[2]: ***

Hello, I propose two small changes to spec.pgram to get modest speedup when dealing with input (x) having multiple columns. With plot = FALSE, I commonly see ~10-20% speedup, for a two column input matrix and the speedup increases for more columns with a maximum close to 45%. In the function as it currently exists, only the upper right triangle of pgram is necessary and pgram is not returned by

I have done a fair bit of spectral analysis, and hadn't finished collecting my thoughts for a reply, so hadn't replied yet. What exactly do you mean by normalize? I have not used the functons periodogram or spectrum, however from the description for periodogram it appears that it returns the spectral density, which is already normalized by frequency, so you don't have to worry about

I'm using the dump command to pass data to WinBUGS/OpenBUGS/JAGS and have run into a problem. Here is some R-code: foo <- array(1:6, dim=c(2,3)) dump('foo', file='dumpdata.R') dump('foo', file='dumpdata.R', append=TRUE, evaluate=TRUE) foo2 <- array(c(2,3,5,7,9,7,5,3), dim=c(2,4)) dump('foo2', file='dumpdata.R', append=TRUE) And here is

The newest version of R for Unix (version 0.49) is now available (or soon will be) from the following sites. NORTH AMERICA: http://lib.stat.cmu.edu/R/Alpha EUROPE: ftp://ftp.stat.math.ethz.ch/R/ ftp://statlab.uni-heidelberg.de/pub/mirrors/auckland/R/ JAPAN: ftp://ftp.u-aizu.ac.jp/pub/lang/R/ NEW ZEALAND: ftp://stat.auckland.ac.nz/pub/R/ Please

The newest version of R for Unix (version 0.49) is now available (or soon will be) from the following sites. NORTH AMERICA: http://lib.stat.cmu.edu/R/Alpha EUROPE: ftp://ftp.stat.math.ethz.ch/R/ ftp://statlab.uni-heidelberg.de/pub/mirrors/auckland/R/ JAPAN: ftp://ftp.u-aizu.ac.jp/pub/lang/R/ NEW ZEALAND: ftp://stat.auckland.ac.nz/pub/R/ Please

The newest version of R for Unix (version 0.49) is now available (or soon will be) from the following sites. NORTH AMERICA: http://lib.stat.cmu.edu/R/Alpha EUROPE: ftp://ftp.stat.math.ethz.ch/R/ ftp://statlab.uni-heidelberg.de/pub/mirrors/auckland/R/ JAPAN: ftp://ftp.u-aizu.ac.jp/pub/lang/R/ NEW ZEALAND: ftp://stat.auckland.ac.nz/pub/R/ Please

Dear Tom, Short answer, if your using spec.pgram(), use the smoothing kernel to get a better estimate at the frequency centered in the bandwidth. If your frequency bin of interest is wider than the bandwidth of the kernel, average across frequencies (I think). The estimate appears to be normalized already. If you are calculating your PSD independently, then oversample (e.g. 2, perhaps 4 or more

Hi All, I just used "dump" on Splus to transfer a pile of survival objects from Splus 3.4 on Solaris 7 to R 0.63.3 on Intel. The only trick is that survival objects contain an element holding the original call that generated the object. When Splus writes these out, it doesn't mark them in any way, so when R tries to read them in, it ends up trying to reevaluate the call. Not

Hi All, I just used "dump" on Splus to transfer a pile of survival objects from Splus 3.4 on Solaris 7 to R 0.63.3 on Intel. The only trick is that survival objects contain an element holding the original call that generated the object. When Splus writes these out, it doesn't mark them in any way, so when R tries to read them in, it ends up trying to reevaluate the call. Not

This worked for me with your example: source("dumpdata.R") storage.mode(x.hc$merge) <- "integer" plot(x.hc) (R-1.4.1 compiled from source on WinNT4.) Andy > -----Original Message----- > From: Hugh Chipman [mailto:hachipma at icarus.math.uwaterloo.ca] > Sent: Wednesday, February 20, 2002 5:32 PM > To: andy_liaw at merck.com > Cc: r-help at stat.math.ethz.ch

Hi, Sorry if this is already known... contour() sometimes draws contour lines that intersect. Is there a temporary fix? A dataset which causes problems is at http://www.maths.uwa.edu.au/~adrian/dumpdata.R If you try just source("dumpdata.R") image(huh) contour(huh) the 100 x 100 matrix 'huh' contains an hourglass-shaped region of values around 0.8. The contour plot

I've been trying to get plot.hclust to work with a hclust object I created and have not had much success. It seems that there is some "hidden" characteristic of a hclust object that I can't see. This is most easily seen in the following example, where plot.hclust works on one object, but when this object is "dumped" and then re-read, plot.hclust no longer works. Is

The combination is bit awkward so not sure why this is happening, but with Xen 4.1.x hypervisor (64-bit), with a 32-bit dom0 (3.3-rcX or 3.2) and with a 3.3-rcX or 3.2 domU I get this: sh-4.1# Feb 20 17:47:41 tst006 init: reloading /etc/inittab xl info host : tst006.dumpdata.com release : 3.3.0-rc4 version : #1 SMP PREEMPT Mi686 nr_cpus

Based on a report to the Windows maintainers from Richard Rowe <Richard.Rowe@jcu.edu.au>: NEWS for 1.3.0 says o Exact p-values are available for the two-sided two-sample Kolmogorov-Smirnov test. I think the (new) p-values are computed but are backwards: > set.seed(123) > x <- rnorm(50) > y <- runif(50) > ks.test(x,y, exact=T)$p [1] 1 > 1 - ks.test(x,y,

> tmp <- data.frame(y=rnorm(12), a=factor(rep(letters[1:4],3))) > tmp y a 1 -0.60866099 a 2 0.55500538 b 3 0.12231693 c 4 -0.24613790 d 5 -0.09253593 a 6 -1.54652581 b 7 0.17204210 c 8 -1.22778942 d 9 1.22151194 a 10 -0.43982577 b 11 -1.25444287 c 12 -0.97251060 d > tmp.aov <- aov(y ~ a, data=tmp) > summary(tmp.aov) Df Sum Sq Mean Sq F value

Full_Name: Martin Kober Version: 2.6.0 OS: Vista & Linux Submission from: (NULL) (137.208.185.169) Hi! I just stumbled upon a problem with file source()ing: R will fail to source a file if it contains lines longer than about 8192 bytes ("input buffer overflow"). While it's save to say that human-written code won't contain lines that long, dump()ed data structures may