Skip to content

numeric(0) -> NA

2 messages · Bill Simpson, Peter Dalgaard

#
I noticed this in current intermediate patch version:
numeric(0)
[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
numeric(0)
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:
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.:
numeric(0)
[1] NA
[1] NA
[1] NA
[1] NA

whereas Splus has
numeric(0)
[1] NA
[1] NA
numeric(0)
# choose doesn't exist...
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.
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).
Most likely it is...