fisher.test seems to use the .C calling convention in a couple of
different places.
for example:
tmp <- .C("fisher_sim", as.integer(nr), as.integer(nc),
as.integer(sr), as.integer(sc), as.integer(n),
as.integer(B), integer(nr * nc), double(n + 1),
integer(nc), results = double(B), PACKAGE =
"stats")$results
perhaps some R experts on the list can tell us whether there is
significant overhead to .C vs .Call.
Does .C really duplicate its arguments? What does RObjToCPtr do?
(line 1682.. in dotcode.c)
/* Convert the arguments for use in foreign */
/* function calls. Note that we copy twice */
/* once here, on the way into the call, and */
/* once below on the way out. */
cargs = (void**)R_alloc(nargs, sizeof(void*));
nargs = 0;
for(pargs = args ; pargs != R_NilValue; pargs = CDR(pargs)) {
#ifdef THROW_REGISTRATION_TYPE_ERROR
if(checkTypes &&
!comparePrimitiveTypes(checkTypes[nargs], CAR(pargs), dup)) {
/* We can loop over all the arguments and report all the
erroneous ones, but then we would also want to avoid
the conversions. Also, in the future, we may just
attempt to coerce the value to the appropriate
type. This is why we pass the checkTypes[nargs] value
to RObjToCPtr(). We just have to sort out the ability
to return the correct value which is complicated by
dup, etc. */
errorcall(call, _("Wrong type for argument %d in call to
%s"),
nargs+1, symName);
}
#endif
cargs[nargs] = RObjToCPtr(CAR(pargs), naok, dup, nargs + 1,
which, symName, argConverters + nargs,
checkTypes ? checkTypes[nargs] : 0,
encname);
#ifdef R_MEMORY_PROFILING
if (TRACE(CAR(pargs)) && dup)
memtrace_report(CAR(pargs), cargs[nargs]);
#endif
nargs++;
}
Thanks,
Whit
> -----Original Message-----
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of Gustaf Rydevik
> Sent: Wednesday, January 09, 2008 10:25 AM
> To: r-help@r-project.org
> Subject: [R] An "R is slow"-article
>
> Hi all,
>
> Reading the wikipedia page on R, I stumbled across the following:
> http://fluff.info/blog/arch/00000172.htm
>
> It does seem interesting that the C execution is that much
> slower from R than from a native C program. Could any of the
> more technically knowledgeable people explain why this is so?
>
> The author also have some thought-provoking opinions on R
> being no-good and that you should write everything in C
> instead (mainly because R is slow and too good at graphics,
> encouraging data snooping). See
> http://fluff.info/blog/arch/00000041.htm
> While I don't agree (granted, I can't really write C), it
> was interesting to read something from a very different
> perspective than I'm used to.
>
> Best regards,
>
> Gustaf
>
> _____
> Department of Epidemiology,
> Swedish Institute for Infectious Disease Control work email:
> gustaf.rydevik at smi dot ki dot se skype:gustaf_rydevik
>
> ______________________________________________
> R-help@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-help
> PLEASE do read the posting guide
> http://www.R-project.org/posting-guide.html
> and provide commented, minimal, self-contained, reproducible code.
>
This e-mail message is intended only for the named recipient(s) above. It may
contain confidential information. If you are not the intended recipient you are
hereby notified that any dissemination, distribution or copying of this e-mail
and any attachment(s) is strictly prohibited. If you have received this e-mail
in error, please immediately notify the sender by replying to this e-mail and
delete the message and any attachment(s) from your system. Thank you.
______________________________________________
R-help@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-help
PLEASE do read the posting guide http://www.R-project.org/posting-guide.html
and provide commented, minimal, self-contained, reproducible code.
