I noticed this in current intermediate patch version:> runif(0,0,4095)numeric(0)> round(runif(0,0,4095))[1] NA I don't like it, but maybe it is the way it is supposed to be. I would prefer for it to stay numeric(0). I notice also> ceiling(runif(0,0,4095))numeric(0)> floor(runif(0,0,4095))numeric(0) which leads me to thing round() is not working right. I have some code like this: do.sim<-function(nnoise, nsignal, jump) { ntotal<-nsignal+nnoise x<-numeric(ntotal) y<-numeric(ntotal) #generate noise dots nx1<-round(runif(nnoise,0,4095)) nx2<-round(runif(nnoise,0,4095)) ny1<-round(runif(nnoise,0,4095)) ny2<-round(runif(nnoise,0,4095)) #generate signal dots sx1<-round(runif(nsignal,0,4095)) ... and I need to do do.sim(0,1000,10). But that gives me NAs which are a problem later. (in particular, I can't do if(rr<rbest) if rr is computed from an NA.) BTW I think it is a ghastly waste of resources to do round(runif(nnoise,0,4095)) but I couldn't think of a better way to get ints between 0 and 4095. (It's a waste because the random number generator makes unsigned long ints to begin with, then they are divided by 2^32 to get a double between 0 and 1, and now I am undoing that!) I guess there is sample(,replace=true), which seems even worse for wasted resources. Maybe not. Thanks for any help. Bill Simpson -.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.- r-devel mailing list -- Read http://www.ci.tuwien.ac.at/~hornik/R/R-FAQ.html Send "info", "help", or "[un]subscribe" (in the "body", not the subject !) To: r-devel-request@stat.math.ethz.ch _._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._
Bill Simpson <wsimpson@uwinnipeg.ca> writes:> I noticed this in current intermediate patch version: > > runif(0,0,4095) > numeric(0) > > round(runif(0,0,4095)) > [1] NA > > I don't like it, but maybe it is the way it is supposed to be. I would > prefer for it to stay numeric(0). > > I notice also > > ceiling(runif(0,0,4095)) > numeric(0) > > floor(runif(0,0,4095)) > numeric(0) > which leads me to thing round() is not working right.You're right, but it's not all that easily fixed. The problem is that round() unlike the other two isn't a unary operation (it has a digits argument) and the automatic logic for binary functions is that length(f(a,b)) = max(length(a),length(b)). There are several of these anomalies, e.g.:> log(numeric(0))numeric(0)> log(numeric(0),10)[1] NA> log10(numeric(0))[1] NA> pt(numeric(0),15)[1] NA> choose(numeric(0),5)[1] NA whereas Splus has> log(numeric(0))numeric(0)> log(numeric(0),10)[1] NA> log10(numeric(0))[1] NA> pt(numeric(0),15)numeric(0) # choose doesn't exist...> round(numeric(0))numeric(0) I.e. it seems to special-case *some* functions.... We probably should have a special version of math2() which said that the first argument was more important than the other.> BTW I think it is a ghastly waste of resources to do > round(runif(nnoise,0,4095)) > but I couldn't think of a better way to get ints between 0 and 4095. > (It's a waste because the random number generator makes unsigned long ints > to begin with, then they are divided by 2^32 to get a double between 0 > and 1, and now I am undoing that!)Compared to all the other inefficiencies going on, I don't think this is worth worrying about (unless nnoise is *very* large). If you really need this to be efficient, you could make a clone of runif in .C callable code, and replace the floatingpoint (l / 2.^32) by a shift operation (l >> 18 or thereabouts).> I guess there is sample(,replace=true), which seems even worse for > wasted resources. Maybe not.Most likely it is... -- O__ ---- Peter Dalgaard Blegdamsvej 3 c/ /'_ --- Dept. of Biostatistics 2200 Cph. N (*) \(*) -- University of Copenhagen Denmark Ph: (+45) 35327918 ~~~~~~~~~~ - (p.dalgaard@biostat.ku.dk) FAX: (+45) 35327907 -.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.- r-devel mailing list -- Read http://www.ci.tuwien.ac.at/~hornik/R/R-FAQ.html Send "info", "help", or "[un]subscribe" (in the "body", not the subject !) To: r-devel-request@stat.math.ethz.ch _._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._