Skip to content

R-alpha: unif_rand() again

2 messages · Luke Tierney, Peter Dalgaard

#
Peter Dalgaard BSA wrote:

            
...
I'm not sure I see the point of the separate select_rand -- you can
just pass runif as an argument to unif_rand. The original example
needed to use the global variable because a C routine for finding a
zero of a C function was being used and the C function whose root was
to be found needed to get at the S/R function that it was fronting
for. The global variable is needed to pass this info (since you don't
have C closures). Here there isn't any need that I can see, but maybe
I've missed something (wouldn't be the first time :-)).
#
Luke Tierney <luke@stat.umn.edu> writes:
Now what *did* I mean by that?.... Oh, yes. The original point
involved calling R from a C function. I'm .C-ing it in that bit of
code just for testing it. In practice, it might well get called from
another C function doing a simulation. So, since it appears to be
tricky to do the string-to-functionSEXP conversion in C, it might be
easier to explicitly initialize them from R with the "select_rand"
mechanism. Of course, one might also pass the R function directly to
the simulation routine, and have that one set things up.

Come to think of it, I'm not sure that we *want* the S semantics for
this. Consider

f<-function(a) a^2
Phi<-function(z)
{
	f<-function(z) exp(-z^2/2)/sqrt(2*pi)
	.C("integrate", f, -infty, zero)
}
where integrate() needs to call_S. It must be ensured that it passes
the inner 'f'. 

Hmm. That's not really an argument for having a call_S("f",...) rather
than call_S(f,...). It is no different from the work involved in any
other name lookup (including constructions like "x %myop% y" or
"'hello, world!'(5)"); it's just that it seems a bit silly to search
for a function by name when you already know full well what the
address of the function is. Inefficient, but hardly impossible.

Maybe one could set it up so that call_S did the string thing and
call_R the direct function pointer?