similar to: Computing means, variances and sums

Full_Name: Nick Efthymiou Version: R1.5.0 and above OS: Red Hat Linux Submission from: (NULL) (162.93.14.73) With the introduction of the functions rowSums(), colSums(), rowMeans() and colMeans() in R1.5.0, function "SEXP do_colsum(SEXP call, SEXP op, SEXP args, SEXP rho)" was added to perform the fast summations. We have an excellent opportunity to improve the accuracy by

I have just started trying Opus with a view to using it in a project. I am interested in embedded hardware and tried it on the Raspberry Pi using the raspbian distro. The version of libopus in the repos is 0.9.14. I installed this and tried encoding 2 minutes of speech from a librevox recording. It managed this at a respectable pace for complexity 10: Skipping chunk of type "LIST",

Has R been ported to 64-bit platforms? E.g. as in FORTRAN when you define double precision number as: REAL*16 I have heard that some SUN computers already offer 64-bit architecture but I am unsure about the GNU support for that hardware. I am seeking increased accuracy in floating point operations. regards Helgi -- Helgi Tomasson FAX: 354-552-6806

I wanted to roughly benchmark how the different version of libopus performed at each complexity level for a 6kbit/s output opus file. This was conducted on a Raspberry Pi so it is a constant hardware platform. This was done on an early Pi so only 256MB RAM but it was never used up so should not make a difference. I compiled the three final versions of each major release of libopus so that was

>>>>> "daheiser" == daheiser <daheiser@gvn.net> >>>>> on Tue, 6 Apr 2004 04:24:35 +0200 (CEST) writes: daheiser> It is an error in the algorithm. "it" being the behavior reported in bug report PR#1228 --- [too bad you didn't use the whole string "PR#1228" in your subject; if you had, no new report would have

> a <- 0 ; for(i in (1:200000000)) a <- a + 1/i > b <- 0 ; for(i in (200000000:1)) b <- b + 1/i > c <- sum(1/(1:200000000)) > d <- sum(1/(200000000:1)) > order(c(a,b,c,d)) [1] 1 2 4 3 > b<c [1] TRUE > c==d [1] FALSE I'd expected b being the largest, since we sum up the smallest numbers first. Instead, c is the largest, which is

Hi Manoj, Not too late at all, we have not got to that point of the work yet. Are there examples of this kind of build setup that are available publicly? I think I understand the problem but it'd help to see one in action. To see if there are any other Arm extensions that are already being added like this and whether those systems support GCC and how. Thanks, David Spickett.

Hi All, What would be interesting would be a plot of complexity versus subjective or object audio quality. I've not had a chance to look at the new analysis code in 1.1 so maybe in the case of a 6kbps compression you could clarify what decisions would it be making that would justify the extra complexity? Best Regards Cliff Parris -----Original Message----- From: opus-request at

Hello Paul and Simon, (Sorry - I'm not sure about the social conventions in mailing lists) Both of your answers helped me a lot! So If I understand it correctly, Clang knows what 'mips1' and 'mips5' are - but can't generate code for it? Why is it like that? I actually have a more in general questions about processors... If this is the wrong place for it, please ignore it,

Hi Manoj, I tried a few other options myself: * function 'target' attribute - the list of extensions this supports isn't complete and it doesn't enable the ACLE macros needed for intrinsics * manually defining ACLE macros - this allows intrinsics and is additive but assumes that you're not relying on codegen to emit instructions. I don't think it helps the bug linked

I noticed the following peculiarity with `serialize()' when `ascii = TRUE' is used. In today's (svn r37299) R-devel, I get > set.seed(10) > x <- rnorm(10) > > a <- serialize(x, con = NULL, ascii = TRUE) > b <- unserialize(a) > > identical(x, b) ## FALSE [1] FALSE > x - b [1] -3.469447e-18 2.775558e-17 -4.440892e-16 0.000000e+00

Hi, Below is a document detailing changes we'd like to make to Clang/LLVM to improve the usability of the target options for ARM and AArch64. To keep things simple the proposed changes are listed at the start and you can find the supporting examples at the end of the document. I look forward to your feedback. Thanks, David Spickett. RFC New Clang target feature selection options for

This is strictly a curiosity question. I am aware the R doesn't possess a float data type. I also don't mean to request that such functionality be implemented as I'm sure it would require a large amount of work with potential back compatibility conflicts. But I wanted to know why R has never had a float data type available? Regards, Charles [[alternative HTML version deleted]]

Dear all, This is the first time I am posting to the r-devel list. On StackOverflow, they suggested that the strange behaviour of integrate() was more bug-like. I am providing a short version of the question (full one with plots: https://stackoverflow.com/q/55639401). Suppose one wants integrate a function that is just a product of two density functions (like gamma). The support of the

Full_Name: Hans Peter Wolf Version: 1.2.1 OS: hpux10.20 Submission from: (NULL) (129.70.84.25) dbeta computes a wrong result with parameters (1.3,1) > version platform hppa2.0-hp-hpux10.20 arch hppa2.0 os hpux10.20 system hppa2.0, hpux10.20 status major 1 minor 2.1 year

I have run a few more test at different bitrates and 1.1 is looking even worse in terms of speed compared to previous versions. I have shared a google sheet which has the raw data and charts for 6,16 and 32 kbps. Unfortunately you cannot show proper error bars on Google sheets but the standard deviation is in the data if you want to look. You can see that the profile for 1.1 is a lot different

On Mon, Dec 16, 2013 at 5:03 AM, Stuart Marsden <stuartmarsden at finmars.co.uk> wrote: > I have just started trying Opus with a view to using it in a project. I am > interested in embedded hardware and tried it on the Raspberry Pi using the > raspbian distro. > > The version of libopus in the repos is 0.9.14. I installed this and tried > encoding 2 minutes of speech from a

And for a starker example of this (documented) inconsistency, arithmetic addition is not commutative: > NA + NaN [1] NA > NaN + NA [1] NaN On Mon, Jul 2, 2018 at 5:32 PM, Duncan Murdoch <murdoch.duncan at gmail.com> wrote: > On 02/07/2018 11:25 AM, Jan Gorecki wrote: >> Hi, >> base::mean is not consistent in terms of handling NA/NaN. >> Mean should not

Dear All For my calculations, I am needing to use more floating-point precision than the default one of R. Is that possible? And, if yes, how? Thanks in advance, Paul

Dear R users, I try to compute this summation, http://www.nabble.com/file/p25054272/dd.jpg where f(y|x) = Negative Binomial(y, mu=exp(x' beta), size=1/alp) http://www.nabble.com/file/p25054272/aa.jpg http://www.nabble.com/file/p25054272/cc.jpg In fact, I tried to use "do.call" function to compute each u(y,x) before the summation, but I got an error, "Error in X[i, ]