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

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

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 ,

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, 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,

>>>>> 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

>>>>> 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 >>

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.

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

Hello, I'm running a samba 3.0.14a server in production on a fedora core 3 (kernel 2.6.9-1.667smp) with a least 250 clients (XP Pro SP2) (up to 400 sometimes). A few days ago, a problem appeared with a soft that we are using for a long time. (Petit Robert, a french dictionnary). When someone launch the dictionnary, many clients are freezed when they try to access to the "start

given what ?identical says, i find the following odd: x = 1:10 y = 1:10 all.equal(x,y) [1] TRUE identical(x,y) [1] TRUE y[11] = 11 y = y[1:10] all.equal(x,y) [1] TRUE identical(x,y) [1] FALSE y [1] 1 2 3 4 5 6 7 8 9 10 length(y) [1] 10 looks like a bug. platform i686-pc-linux-gnu arch i686 os linux-gnu system

playing with 'names<-', i observed the following: x = 1 names(x) # NULL 'names<-'(x, 'foo') # c(foo=1) names(x) # NULL where 'names<-' has a functional flavour (does not change x), but: x = 1:2 names(x) # NULL 'names<-'(x, 'foo') # c(foo=1, 2) names(x) # "foo" NA