search for: subassignment

Valgrind (without gctorture) reports memory misuse: % R --debugger=valgrind --debugger-args="--leak-check=full --num-callers=18" ... > x <- 1:200000 > y <- rep(letters[1:5], length(x) / 5L) > for (i in 1:1000) { + # x[y == 'a'] <- x[y == 'b'] + x <- `[<-`(x, y == 'a', x[y == 'b']) + cat(i, '') + } 1 2 3 4 5 6 7 8 9 10

On an azure centos VM, I can reproduce this bug which reports either: *** caught segfault *** address 0x70000006a, cause 'memory not mapped' (crash) Or incompatible types (from builtin to integer) in subassignment type fix (no crash) Like Gabriel, I could not reproduce the bug on a mac laptop. Both R versions 3.5.1. Travers On Wed, Feb 27, 2019 at 9:08 AM William Dunlap via R-devel <r-devel at r-project.org> wrote: > > Valgrind (without gctorture) reports memory misuse: > > % R --debugg...

The following code crashes after about 300 iterations on my?x86_64-w64-mingw32?machine on R 3.5.2 --vanilla.?? Others have duplicated this (see?https://github.com/tidyverse/magrittr/issues/190?if necessary), but I don't know how machine/OS-dependent it may be.?? If it doesn't crash for you, please try increasing the length of the x vector. Substituting the commented-out line for the one

Hi All: I'm looking to find out a bit more about how subassignment actually works and am hoping someone with knowledge of the details can fill me in (I've looked at the source code, but my knowledge of C is lacking). In the case of vectors, my reading of ?"[" would indicate that for a vector, vec <- 1:25, vec[c(1,5,25)] <- c(101,102,103)is f...

...ata frame to 2s, the second fails to do so. > df1 <- data.frame(a = c(NA, 0, 3, 4)) > df2 <- data.frame(a = c(NA, 0, 0, 4)) > df1[df1 == 0] <- 2 ## Works > df2[df2 == 0] <- 2 Error: NAs are not allowed in subscripted assignments Checking an old news file I see this: o Subassignments involving NAs and with a replacement value of length > 1 are now disallowed. (They were handled inconsistently in R < 2.0.0, see PR#7210.) For data frames they are disallowed altogether, even for logical matrix indices (the only case which used to work). which leaves me to believe that...

Apart from the inconsistencies, there are two clear bugs here: 1) miscalculating the number of values needed, in the matrix case. E.g. > AA[idx, 1] <- B[1:4] Error in "[<-"(`*tmp*`, idx, 1, value = B[1:4]) : number of items to replace is not a multiple of replacement length although only 4 values are replaced by AA[idx, 1] <- B. 2) the behaviour of the 3D case.

I have made the 3-d case do the same as the vector case, which is what the C code clearly intended (a goto label was in the wrong place). This leaves the bigger question of the right thing to do. I note that data frames give an error when any indices are NA. -thomas On Fri, 3 Sep 2004 ripley@stats.ox.ac.uk wrote: > Apart from the inconsistencies, there are two clear bugs here: > > 1)

I have just finished translating R.pot to pt_BR and now I'll start the process of revision and will merge it with the latest SVN version (33261), as I started the translation on 02/06 (SVN 33048). There are some observations I'd like to make regarding the translation process: 1) Sometimes it is not clear in the message whether a given term is referring to an actual

Hi, We sometimes see offers to contribute, asking what needs to be done. If they know C, how about the 111 FIXMEs? But which ones would be most useful to fix? Which are difficult and which are easy? Does R-core have a process to list and prioritise the FIXMEs? ~/R/Rtrunk/src/main$ grep "[^/]FIXME" * | wc -l 111 ~/R/Rtrunk/src/main$ grep -A 1 "[^/]FIXME" * arithmetic.c:/*

Someone has given me a data set that produces a failure with all the hallmarks of a memory overrun in a C routine. I've tried running it under an instrumented version of R with valgrind and don't catch anything. I do get one error message out though: ==642== Warning: set address range perms: large range [0x3901d040, 0x3f2ae7070) (undefined) Can anyone shed light on what this means?

Hi all, This occurred in R-2.11.0 (WinXP). The R-help page of .[ says that: "Character indices can in some circumstances be partially matched (see pmatch) to the names or dimnames of the object being subsetted (but never for subassignment). Unlike S (Becker et al p. 358)), R has never used partial matching when extracting by [, and as from R 2.7.0 partial matching is not by default used by [[ (see argument exact)." My understanding is therefore that .[ should never try partial matching. However: > df = data.frame(a=c(1,2,...

...the Kest function runs OK for most of the different point patterns that I have but for a particular point pattern, which have only 17 points, it runs until the 34th iteration and then I receive this message: Error in "[<-"(`*tmp*`, index, value = NULL) : incompatible types (1000) in subassignment type fix Execution halted Do you have any idea about what could be the cause of this ? Thanks in advance D. ----------------------------------------- Stay ahead of the information curve. Receive EDA news and jobs on your desktop daily. Subscribe today to the EDA CafeNews newslette...

Hello, I just finished installing R-0.64.1 on my linux machine (using kernel 2.0.36 under red hat 5.2, and gcc version egcs-2.91.60 19981201 (egcs-1.1.1 release) ) The two problems I had: 1. ./configure --with-readline --with-x --prefix=/usr/local ran to a point, then gave up with ... checking return type of signal handlers... void checking for working const... yes

Hello, I just finished installing R-0.64.1 on my linux machine (using kernel 2.0.36 under red hat 5.2, and gcc version egcs-2.91.60 19981201 (egcs-1.1.1 release) ) The two problems I had: 1. ./configure --with-readline --with-x --prefix=/usr/local ran to a point, then gave up with ... checking return type of signal handlers... void checking for working const... yes

>>>>> Martin Maechler >>>>> on Wed, 19 Feb 2020 18:06:57 +0100 writes: >>>>> Serguei Sokol >>>>> on Wed, 19 Feb 2020 15:21:21 +0100 writes: >> Hi, >> I was bitten by a little incoherence in dimnames assignment or may be I >> missed some point. >> Here is the case. If I assign row names

Hi, what is meaning this errors !!! Error in names(o.pr)[p.ok] <- names(qs) :   incompatible types (from NULL to character) in subassignment type fix In addition: Warning message: In Ops.factor(from, (0:(length.out - 1)) * by) :   + not meaningful for factors thank you very much [[alternative HTML version deleted]]

Browse[1]> j <- c(1,2,NA) Browse[1]> j[j==1][-1] [1] NA Browse[1]> j[j==1][-2] [1] 1 Browse[1]> j[j==1][-2] <- 2 Error during wrapup: NAs are not allowed in subscripted assignments As far as I can see, I have no NA in the lhs (not after the second subscript anyway). Besides, I have a single value on the rhs, so it should be allowed to have NAs in the lhs, according to

I found a bug in one of the fourteen speed patches I posted, namely in patch-vec-subset. I've fixed this (I now see one does need to duplicate index vectors sometimes, though one can avoid it most of the time). I also split this patch in two, since it really has two different and independent parts. The patch-vec-subset patch now has only some straightforward (locally-checkable) speedups for

Hello, I am inexperienced in C program compilation and I receive the following error during the compilation of R (version 0.61.2) for Solaris 2.6. I have installed the gcc 2.8.0 version. >> gcc -o R.binary arithmetic.o array.o attrib.o bind.o builtin.o character.o >> coerce.o colors.o complex.o context.o cov.o cum.o dataframe.o debug.o >> deparse.o deriv.o

...pairlists. Thanks, Michael On Wed, Oct 12, 2016 at 9:40 AM, Michael Lawrence <michafla at gene.com> wrote: > The coercion is probably the most viable workaround for now, as it's > consistent with what happens internally for calls. All pairlists/calls > are converted to list for subassignment, but only calls are converted > back. My guess is that the intent was for users to move from using a > pairlist to the "new" (almost 20 years ago) list. In my opinion, > consistency trumps "convenience" in this case. If others agree, I'll > change it to also coer...