similar to: incoherent treatment of NULL

i wonder about the following examples showing incoherence in how type conversions are done in r: x = TRUE x[2] = as.raw(1) # Error in x[2] = as.raw(1) : # incompatible types (from raw to logical) in subassignment type fix it seems that there is an attempt to coerce the raw value to logical here, which fails, even though as.logical(as.raw(1)) # TRUE likewise, x[2]

i wonder about the following examples showing incoherence in how type conversions are done in r: x = TRUE x[2] = as.raw(1) # Error in x[2] = as.raw(1) : # incompatible types (from raw to logical) in subassignment type fix it seems that there is an attempt to coerce the raw value to logical here, which fails, even though as.logical(as.raw(1)) # TRUE likewise, x[2]

the man page for relational operators (see, e.g., ?'<') says: " Binary operators which allow the comparison of values in atomic vectors. Arguments: x, y: atomic vectors, symbols, calls, or other objects for which methods have been written. " it is somewhat surprizing that the following works: '<'(1) # logical(0) '<'() #

the man page for relational operators (see, e.g., ?'<') says: " Binary operators which allow the comparison of values in atomic vectors. Arguments: x, y: atomic vectors, symbols, calls, or other objects for which methods have been written. " it is somewhat surprizing that the following works: '<'(1) # logical(0) '<'() #

Dear list, On a follow up from my previous email, I am now trying to allocate vectors of length larger than 32-bit in C. >From the R internals documentation, I read that: "The sxpinfo header is defined as a 32-bit C structure..." and "A SEXPREC is a C structure containing the 32-bit header..." The question is: does the INTSXP allow vectors larger than 32-bit? A test

Tested in R 2.8.1 Windows > ff <- formals(function(x)1) > ff1 <- as.list(function(x)1)[1] # ff1 acts the same as ff in the examples below, but is a list rather than a pairlist > dput( ff , control=c("warnIncomplete")) list(x = ) This string is not parsable, but dput does not give a warning as specified. > dput( ff ,

I haven' t touched R for some 18 months, and so I have no idea if this is a recent problems or not; but it certainly did not segfault two years ago. Since it has been crashing (segfault) under 'make check-all' for over a month, I reckon I'll have to look at it myself, to have it fixed. I have been having the ' --enable-memory-profiling --enable-strict-barrier

Hi, Again, sorry for the length of this post. Once I get my new office I will get a website set up on my work machine and will simply post a link to the log since I doubt many people are truly interested in these logs. To further analyze what is happening, I added my own routine in main.c called DEBUG_SET_NAMED and then redefined the SET_NAMED macro to use it and then rebuilt R. I

Hi all, Why is the object size of an empty vector 40 bytes? (At least in 64-bit R.) object.size(integer(0)) # 40 bytes Reading R internals, it looks like it should be: * 4 bytes: sxpinfo header (= 32 bits) * 8 bytes: pointer to attributes * 8 bytes: pointer to next node * 8 bytes: pointer to previous node * 4 bytes: length * 4 bytes: true length = 36 bytes Where are the extra 4 bytes coming

>>>>> William Dunlap >>>>> on Fri, 21 Feb 2020 14:05:49 -0800 writes: > If we change the behavior NULL--[[--assignment from > `[[<-`(NULL, 1, "a" ) # gives "a" (*not* a list) > to > `[[<-`(NULL, 1, "a" ) # gives list("a") > then we have more consistency there *and* your bug

m = matrix(1:4, 2) apply(m, 1, cat, '\n') # 1 2 # 3 4 # NULL why the null? vQ

On 2nd thought, I think a better fix to the segfault is something like this: --- a/src/main/memory.c +++ b/src/main/memory.c @@ -3444,6 +3444,8 @@ R_xlen_t (XTRUELENGTH)(SEXP x) { return XTRUELENGTH(CHK2(x)); } int (IS_LONG_VEC)(SEXP x) { return IS_LONG_VEC(CHK2(x)); } const char *(R_CHAR)(SEXP x) { + if(!x) + error("de-referncing null. Check the validity of your data.");

Hi, How do I tell an if statement to generate two seperate outputs. E.g If X>5 I want to create df1 and df2: if (X>5) {df1<-c(4,5,6,7,8) AND df2<-c(9,10,11,12,13)} Thanks, James -- View this message in context: http://www.nabble.com/If-statement-generates-two-outputs-tp22650844p22650844.html Sent from the R help mailing list archive at Nabble.com.

Hi, everyone. I'm trying to debug an R-module, written in C, and I'm using gdb for this. How can I print "standard" R objects from within C code? BTW, I'm familiar with the advice to use R_PV given in Writing R Extensions, but it's not working for me. E.g., I get (gdb) p R_PV(x) $1 = void and yet (gdb) p *x $2 = {sxpinfo = {type = 16, obj = 0, named = 0, gp = 0,

>>>>> Martin Maechler >>>>> on Sat, 22 Feb 2020 20:20:49 +0100 writes: >>>>> William Dunlap >>>>> on Fri, 21 Feb 2020 14:05:49 -0800 writes: >> If we change the behavior NULL--[[--assignment from >> `[[<-`(NULL, 1, "a" ) # gives "a" (*not* a list) >> to >>

Vectorize is defined to return a function that acts as if 'mapply' was called. So we have: > mapply(dput,1:2) # mapply form 1L # calls dput on each element of 1:2 2L [1] 1 2 > Vectorize(dput)(1:2) # Vectorize form 1L # same behavior 2L [1] 1 2 Same thing with a named argument: >

Full_Name: David States Version: 2.6.0 OS: Windows XP64 Submission from: (NULL) (141.211.38.9) # The pair of commands # # dput(object, "file.dput") # object = dget("file.dput") # # should be a no op, but this is not working correctly for all objects. # # Simple example: # # make a simple object of class "hclust" cl = hclust(dist(matrix(nrow=4,ncol=4, c(1:16)))) #

Is this not supposed to work? > dput(BOD, file = "/BOD.R") > source("/BOD.R") Error in attributes(.Data) <- c(attributes(.Data), attrib) : row names must be 'character' or 'integer', not 'double' > dput(iris, file = "/iris.R") > source("/iris.R") Error in attributes(.Data) <- c(attributes(.Data), attrib) :

I was wondering why the following doesn't work: > a=c(1,2) > names(a)=c("one","two") > a one two 1 2 > > names(a[2]) [1] "two" > > names(a[2])="too" > names(a) [1] "one" "two" > a one two 1 2 I must not be understanding some basic concept here. Why doesn't the 2nd name change to

I was wondering why the following doesn't work: > a=c(1,2) > names(a)=c("one","two") > a one two 1 2 > > names(a[2]) [1] "two" > > names(a[2])="too" > names(a) [1] "one" "two" > a one two 1 2 I must not be understanding some basic concept here. Why doesn't the 2nd name change to