similar to: fft fails for lengths 392, 588, 968, 980 .... (PR#1429)

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, I am new to R. and even though I've made my code to run and do what it needs to . It is taking forever and I can't use it like this. I was wondering if you could help me find ways to fix the code to run faster. Here are my codes.. the data set is a bunch of 0s and 1s in a data.frame. What I am doing is this. I pick a column and make up a new column Y with values associated with that

I have very large csv files (up to 1GB each of ASCII text). I'd like to be able to read them directly in to R. The problem I am having is with the variable length of the data in each record. Here's a (simplified) example: $ cat foo.csv Name,Start Month,Data Foo,10,-0.5615,2.3065,0.1589,-0.3649,1.5955

See https://stat.ethz.ch/pipermail/r-devel/2017-August/074746.html for the origin of the example here. That pretty(c(-1,1)*1e300, n = 1e9, min.n = 1) gave 20 intervals, far from 1e9, but pretty(c(-1,1)*1e300, n = 1e6, min.n = 1) gave 1000000 intervals (on a machine), made me trace through the code to function 'R_pretty' in https://svn.r-project.org/R/trunk/src/appl/pretty.c . *lo is

Examples similar to pretty(c(-1,1)*1e300, n = 1e9, min.n = 1) with smaller 'n': pretty(c(-1,1)*1e304, n = 1e5, min.n = 1) pretty(c(-1,1)*1e306, n = 1e3, min.n = 1) A report on 'pretty' when working with integers, similar to what led to change of 'seq' fuzz, is https://bugs.r-project.org/bugzilla3/show_bug.cgi?id=15137 -------------------------------------------- On Tue,

There is a problem with 'default argument evaluation' when I use an existing function name as argument name : sintest <- function(x, y = 2, sin= sin(pi/4)) { ## Purpose: Test of "default argument evaluation" ## -------- Fails for R-0.49. Martin Maechler, Date: 9 May 97. c(x=x, y=y, sin=sin) } ## R-0.49: R> sintest(1) ##> Error in sintest(1) : recursive

Hi Developers, I am looking for another new project to help me get more up to speed on R and to learn something outside of R internals. One recent R issue I have run into is finding a fast implementations of the equivalent to the following SAS code: /* MDPC is an integer sort key made from two integer columns */ MDPC = (MD * 100000) + PCO; /* sort the dataset by the key */ PROC SORT;

(1) ...need to speed up a monte-carlo sampling...any suggestions about how I can get R to use all 8 cores of a mac pro would be most useful and very appreciated... (2) spent the last few hours trying to get pnmath to compile under os- x 10.5.4... using gcc version 4.2.1 (Apple Inc. build 5553) as downloaded from CRAN, xcode 3.0... ...xcode 3.1 installed over top of above after

Today I installed the newest R develepment branch R version 2.14.0 Under development (unstable) (2011-03-18 r54866) on FreeBSD 9.0-CURRENT (amd64). All seems fine so far. After that I updated my R packages with option 'checkBuilt=TRUE'. There are four packages (spatstat, pscl, adehabitatLT, adehabitatHR) which gives an error like this: Error in dyn.load(file, DLLpath = DLLpath, ...) :

On a recent FreeBSD 8.0-CURRENT (i386) building R (any version) breaks with the following messages: ---------------------------------------------------------------------- [...snip...] gcc -std=gnu99 -I. -I../../src/include -I../../src/include -I/usr/local/include -DHAVE_CONFIG_H -g -O2 -c wilcox.c -o wilcox.o gcc -std=gnu99 -I. -I../../src/include -I../../src/include -I/usr/local/include

https://bugzilla.netfilter.org/show_bug.cgi?id=1429 Bug ID: 1429 Summary: Empty file in source directory - 'netlink_delinearize.' Product: nftables Version: unspecified Hardware: All OS: All Status: NEW Severity: trivial Priority: P5 Component: nft

CentOS Errata and Bugfix Advisory 2011:1429 Upstream details at : https://rhn.redhat.com/errata/RHBA-2011-1429.html The following updated files have been uploaded and are currently syncing to the mirrors: ( md5sum Filename ) x86_64: 42f7f6bebca2bca06e92705df62aa4a6 rsh-0.17-40.el5_7.1.x86_64.rpm 518f2cf8031b802ac12e8a105e90cb8a rsh-server-0.17-40.el5_7.1.x86_64.rpm Source:

CentOS Errata and Bugfix Advisory 2011:1429 Upstream details at : https://rhn.redhat.com/errata/RHBA-2011-1429.html The following updated files have been uploaded and are currently syncing to the mirrors: ( md5sum Filename ) i386: 2c197ffc732880dd3748d3f8627ccde5 rsh-0.17-40.el5_7.1.i386.rpm c050f22324d23b984c5c71c89b3da8b1 rsh-server-0.17-40.el5_7.1.i386.rpm Source:

CentOS Errata and Security Advisory 2020:1429 Important Upstream details at : https://access.redhat.com/errata/RHSA-2020:1429 The following updated files have been uploaded and are currently syncing to the mirrors: ( sha256sum Filename ) i386: 92fa23b14ba91a20f2d063b24670606180b0f9aa2e572c3e6546665a7a51e6e3 firefox-68.7.0-2.el6.centos.i686.rpm x86_64:

https://bugzilla.mindrot.org/show_bug.cgi?id=1429 Summary: ssh -q doesn't suppress all warning messages Classification: Unclassified Product: Portable OpenSSH Version: 4.7p1 Platform: HPPA OS/Version: All Status: NEW Severity: normal Priority: P2 Component: ssh AssignedTo: bitbucket at

predict.warn() -- a function to display factor levels in new data for linear model prediction that do not exist in the estimating data. Date: 2005-8-24 From: John C. Nash (with thanks to Uwe Ligges for suggestions) nashjc at uottawa.ca Motivation: In computing predictions from a linear model using factors, it is possible to introduce new factor levels. This was encountered on a practical

> I am working on DSP module of Ne10. I see there are fixed-point and > floating-point FFT inside Opus. Is fixed-point FFT only a fall back for CPU > without VFP? On ARMv7-A and ARMv8-A, benchmark result shows that fixed-point > (int32) and floating-point (float32) FFT have similar performance. I guess > fixed-point version is not often used on these platforms. Is it worth the >

There is definitely some use for a Neon fixed-point FFT. How much exactly I'm not sure. Fixed-point is a bit more than just a fall-back for CPUs with no FPU. There are CPUs for which fixed-point is still faster. It depends on the exact model but also on what you run. For example, even on x86 I believe that SILK encoding is slightly faster in fixed-point, even though CELT is faster in float.

Thanks Timothy and Jean-Marc, I will start NEON optimizing fixed-point FFT. Is it int32 good enough? Benchmark data shows that FFT using int16 is much faster than FFT using int32. > -----Original Message----- > From: Timothy B. Terriberry [mailto:tterribe at xiph.org] > Sent: Friday, December 26, 2014 6:52 AM > To: Phil Wang; opus at xiph.org > Cc: Zhongwei Yao; Yang Zhang; Zhou

Hello! thank you for your efforts creating R! While preparing the next lessons I found that I had to multiply with 1/length(x) by hand if I want to get the inverse Fouriertransform. The help states it will do it by itself. Version R-0.60.1, Linux Seems to be pretty easy to correct either the fft or :-) the help(fft)! Cu Detlef Detlef Steuer Universitaet Dortmund ///////