similar to: qgamma inaccuracy

Full_Name: Version: 2.7.1 (2008-06-23) OS: windows vista Submission from: (NULL) (216.82.144.137) Hello, I have been working with various probability distributions in R, and it seems the gamma distribution is inaccurate for some inputs. For example, qgamma(1e-100, 5e-101, lower.tail=FALSE) gives: 1.0. However, it seems this is incorrect; I think the correct answer should be

Full_Name: Morten Welinder Version: 1.5.1 OS: Solaris Submission from: (NULL) (65.213.85.136) I was having problems with qgamma's precision in the sense that pgamma(qpgamma(x)) was not as close to the identity function as I would like. I was seeing relative errors with random input of about 1e-8. This fits nicely with the code'd EPS2 value of 5e-7. To solve this I added a newton step

I haven't looked inside to see what is causing this, but there's a big discontinuity in qgamma: curve(qgamma(x, shape=19), from=1e-10, to=2e-10) This appears in both R-patched and R-devel. Duncan Murdoch

Hi, Cosmetic. Starting R with e.g. --max-ppsize=-10 produces the following warning: WARNING: '-max-ppsize' value is negative: ignored The name of the option displayed in the warning is incorrect. Could that be fixed? See src/main/CommandLineArgs.c (there are 3 places in that file where the name of this option needs to be adjusted). This is with current R-alpha. Thanks! H. --

Hi, In man page for duplicated: Value: ?duplicated()?: For a vector input, a logical vector of the same length as ?x?. For a data frame, a logical vector with one element for each row. For a matrix or array, a logical array with the same dimensions and dimnames. When 'x' is a matrix or array, the returned value is NOT a logical array: > m <-

I came across this: shouldn't the last value be a more exact zero? It did not do that with 1 - sum( rep(0.1, 10) ) > 1 - cumsum( rep(0.1, 10) ) [1] 9.000000e-01 8.000000e-01 7.000000e-01 6.000000e-01 5.000000e-01 4.000000e-01 3.000000e-01 2.000000e-01 [9] 1.000000e-01 1.110223e-16 > version _ platform

Hello, I need to use the confluent function of second kind, also known as Tricomi function. It is implemented as kummerU() function in fAsianOptions package, but I've found very inaccurate values, comparing with those provided by Mathematica. I think Mathematica values are OK because kummerU values leads to negative probabilities. For example, if you try the kummerU() function example, you

Using a line width > 1 results in not only a thicker line but also some fuzz in the other direction, as shown in this example program. You will see that the thick vertical black lines extend below the gray scale horizontal lines. Does anyone know whether this is intended or is it a bug? The application is for displaying a correlation matrix (here just some random U(0,1)s). Thanks -Frank

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

G'day Duncan, On Tue, 12 Jan 2016 07:32:05 -0500 Duncan Murdoch <murdoch.duncan at gmail.com> wrote: > On 11/01/2016 11:59 PM, Berwin A Turlach wrote: > > G'day all, > > > > In Chapter 1.4 (Writing package vignettes) the Writing R Extensions > > manual states: > > > > By default @code{R CMD build} will run @code{Sweave} on all > >

Full_Name: Vlad Stolin Version: R 2.0.0 OS: Windows 2000 Submission from: (NULL) (204.128.232.211) When generating the sequence using seq() function with non-integer numbers result is somewhat unpredictable. Example: > v1<-seq(1.60,1.90,.05) > v2<-c(1.60,1.65,1.70,1.75,1.80,1.85,1.90) > v1-v2 [1] 0.000000e+00 2.220446e-16 2.220446e-16 0.000000e+00 0.000000e+00 0.000000e+00

Hi all, I'm having some problems with inaccurate sampling rates between sending and receiving party. (Using a simple raw UDP protocol sending packets from speex to speex) Both PC's have their soundcard set to 8 khz, but the samplerate seems to differ slightly between machines. The problem I have is that the sending machine sometimes samples with a slightly lower rate than the player

I'm working on this issue, thank you for reporting it. The short answer is that the callgraph reported by TD is the same as discovered/computed during BU (and BU can't determine the indirect call can only target C2). I've added this example, and a few other related tests, to the DSA's test suite[1] to document this behavior while I'm working out what the best solution is.

Hi, I found the following strange effect with qbinom & partial argument matching p0 <- pbinom(0, size = 3, prob = 0.25) qbinom(p0, size = 3, prob = 0.25) ## 0 o.k. qbinom(p0-0.05, size = 3, prob = 0.25) ## 0 o.k. ## positional matching: qbinom(p0, 3, 0.25) ## 0 o.k. ## partial argument matching: qbinom(p0 , s = 3, p = 0.25) ## 1 ??? qbinom(p0-0.05,

G'day all, In Chapter 1.4 (Writing package vignettes) the Writing R Extensions manual states: By default @code{R CMD build} will run @code{Sweave} on all Sweave vignette source files in @file{vignettes}. If @file{Makefile} is found in the vignette source directory, then @code{R CMD build} will try to run @command{make} after the @code{Sweave} runs, otherwise @code{texi2pdf} is run on

Hello, I have some ugly numbers given by zttest for ztdummy on an AMD64 box running linux-2.6.15 compiled for Athlon64. linux-2.6.15, zaptel/branches/1.2 r900, jiffies ./zttest Opened pseudo zap interface, measuring accuracy... 99.975586% 99.975586% 99.975586% 99.975586% 99.975586% 99.975586% 99.975586% 99.975586% 99.975586% 99.975586% 99.975586% 99.975586% 99.975586% 99.975586% 99.975586%

Hello, I am trying to extract a callgraph using DSA, but the analysis looks quite pessimistic. I use TDD analysis and here is my test code: #include <stdlib.h> typedef void (*tX)(int a, int b); typedef void (*tY)(int a); typedef struct { tX p ; int n; } msg; static void A1(int a) { } static void B2(int a, int b) { } static void C2(int a, int b) { } tY q; static void decode(tX

On two laptops running 32-bit kubuntu, I have found that svd(), invoked within R 2.9.1 as supplied with the current ubuntu package, returns very incorrect results when presented with complex-valued input. One of the laptops is a Dell D620, the other a MacBook Pro. I've also verified the problem on a 32-bit desktop. On these same systems, R compiled from source provides apparently

Hello. I am reading changelogs from rails master git branch from time to time, because I like to know what''s new. But every time, there are some errors. Mainly in version releases dates. For example in actionpack changelog (https://github.com/rails/rails/blob/ 6481bc5f49ef26e8fde68ac964dc984d12f33189/actionpack/CHANGELOG.md) is last released version Rails 3.1.0. We all know, that latest