similar to: small documentation change: maxCol -> max.col in maxCol.Rd?

I've noticed that the max.col function with the default "random" option often gives unexpected results. For instance, in this test, it seems clear what the answer should be: > # second col should always be max > x1 = cbind(1:10, 2:11, -Inf) > > # this works fine > max.col(x1, "first") [1] 2 2 2 2 2 2 2 2 2 2 > > # this gives random answers >

I've noticed that the max.col function with the default "random" option often gives unexpected results. For instance, in this test, it seems clear what the answer should be: > # second col should always be max > x1 = cbind(1:10, 2:11, -Inf) > > # this works fine > max.col(x1, "first") [1] 2 2 2 2 2 2 2 2 2 2 > > # this gives random answers >

Hi everyone, I'm experiencing difficulty getting the results I want when I use a nested for loop. I have a data set to which I perform some calculations, and then try to apply a regression over a rolling window. The code runs, but the regression results I am getting (intercept and slope) are simply the same, repeated again and again in the results matrix. The regression does not seem to be

Hi everyone, I'm trying to calculate correlation coefficients between corresponding columns in two matrices with identical dimensions but different data. The problem is that the matrices contain NAs in different locations. I am using the following code to try to calculate correlations between complete sets of data: #Code start maxcol<-ncol(mat1) for (i in 1:maxcol) {

On Mon, Sep 07, 2020 at 04:46:39PM -0500, Eric Blake wrote: > We have a memory leak when a function with a closure exits early prior > to registering that closure through some path that will guarantee > cleanup. The easiest way to fix it is to guarantee that once a > closure is passed into a public API, it will be cleaned regardless of > whether that API succeeds or fails. But to

Dear Adrian and Ian (and r-helpers), I encountered a curious result in developing an example using the bicreg function in the BMA package: I noticed that pairs of models with equal R^2 and equal numbers of predictors had nevertheless different BIC values. Looking at the bicreg function, the definition of BIC appears to be the usual one, or close to it [bic <- n * log(1 - r2/100) + (size - 1) *

Hello, I think the following qualify as a bug given: x<-c(1,2,3,4,2,4,2,2,4,2,2,2,4,3,2,1) z<-embed(x,4) z [,1] [,2] [,3] [,4] [1,] 4 3 2 1 [2,] 2 4 3 2 [3,] 4 2 4 3 [4,] 2 4 2 4 [5,] 2 2 4 2 [6,] 4 2 2 4 [7,] 2 4 2 2 [8,] 2 2 4 2 [9,] 2 2 2 4 [10,] 4 2 2 2

Hello, I think the following qualify as a bug given: x<-c(1,2,3,4,2,4,2,2,4,2,2,2,4,3,2,1) z<-embed(x,4) z [,1] [,2] [,3] [,4] [1,] 4 3 2 1 [2,] 2 4 3 2 [3,] 4 2 4 3 [4,] 2 4 2 4 [5,] 2 2 4 2 [6,] 4 2 2 4 [7,] 2 4 2 2 [8,] 2 2 4 2 [9,] 2 2 2 4 [10,] 4 2 2 2

Dear R-Developers, I think I found two bugs in max.col(). Ties between zeros are not broken, which might affect simulations. -Inf and Zero can be treated the same, which can give completely wrong results, e.g. when the second max is sought by replacing all maxs by -Inf. To fix max.col I do offer the C-code behind my function rowMax(), which also handles NAs and seems to be faster. However,

The menu directory won't compile with gcc 3.4.0 because gcc complains that "ebp" cannot be used as a constraint. If preserving ebp is necessary then it will have to be done in the assembler code. Gcc 3.3.3 just seems to ignore the constraint. It didn't do anything special to preserve the register. I also noticed that getnumrows returns the contents of 0x484 which is the

I'm not sure I understand the max.col spec or its rationale. In particular: * What is the significance and effect of "assuming that the entries are probabilities", as they do not seem to be limited to the interval [0,1]? * In what contexts is it useful for max.col to consider numbers within a certain tolerance equal? * Why is a fixed relative tolerance of 1e-5 useful? That seems

Hi, I think there's some rounding issue with returning the max column. (running 2.9.0 on an Apple, but my buddy found it on his PC) > x <- matrix(c(1234.568,1234.569,1234.567),1) > max.col(x) [1] 2 > x <- matrix(c(12345.568,12345.569,12345.567),1) > max.col(x) [1] 3 > x <- matrix(c(112345.568,112345.569,112345.567),1) > max.col(x) [1] 3 > max.col(-x) [1]

I noticed a typo in the documentation for the 'rank' function. Specifically, it describes ties.method="first" and contrasts with... ties.method="first", when it should be ties.method="last". Thanks, Jon -------------- next part -------------- Index: src/library/base/man/rank.Rd =================================================================== ---

Dear Sirs, I am trying to compile R v1.2.1 under Digital Unix 4.0D. The configure-script runs without any problems but during 'make' I receive the following error-message: [......] g77 -mieee -g -O2 -c dtrco.f -o dtrco.o g77 -mieee -g -O2 -c dtrsl.f -o dtrsl.o g77 -mieee -g -O2 -c eigen.f -o eigen.o g77 -mieee -g -O2 -c lminfl.f -o lminfl.o ar cr libappl.a Rsock.o approx.o bakslv.o

Hello, I suppose this is a general behavior with external function calls, so I do not post (yet) a specific bug report. Could someone explain this? a <- rep(1, 20) + rnorm(20, mean=0.00001, sd=0.0001) b <- embed(a, 3) # I want to know where the item in column 2 is greated than both col 1 and 3 (peak) test1 <- max.col(b) == 2 # ... or I could use a less optimal code test2 <- apply(b,

We have a memory leak when a function with a closure exits early prior to registering that closure through some path that will guarantee cleanup. The easiest way to fix it is to guarantee that once a closure is passed into a public API, it will be cleaned regardless of whether that API succeeds or fails. But to avoid cleaning the closure more than once, we need to refactor our internal handling,

The help file for "[<-" (and "[[<-" doesn't contain those functions in it's usage section ( .../src/library/base/man/Extract.Rd ). Although that file lists "[<-" and "[[<-" as aliases, it doesn't document them in a formal manner (consequently, the "value" argument is not described in the "arguments" section.)

Hi, A new package Rd2roxygen has been released on CRAN: http://cran.r-project.org/package=Rd2roxygen (source package available; binaries to come) This package can be useful for developers who used to document their functions in the raw Rd files but want to switch to roxygen now using inline roxygen comments (e.g. me). The main functionality of this package is to parse the Rd files under the

Full_Name: Michale Na Li Version: 1.6.0 OS: i386-linux Submission from: (NULL) (140.142.172.141) In src/library/base/man/reshape.Rd, one paranthesis is missing, here is the patch. *** reshape.Rd.old 2002-10-15 23:32:25.000000000 -0700 --- reshape.Rd 2002-10-15 23:32:35.000000000 -0700 *************** *** 12,18 **** idvar = "id", ids = 1:NROW(data), times =

L.S. In the current version of ?p.adjust.Rd, one needs to scroll down to the examples section to find confirmation of one's guess that "fdr" is an alias of "BH". Please find a patch in attachment which mentions this explicitly. Best, Tobias -------------- next part -------------- A non-text attachment was scrubbed... Name: p.adjust.Rd.patch Type: text/x-patch Size: 633