Jeffrey Horner wrote:
> I hazard to say that the author of that blog post isn't using the time
> he saved from writing his analyses in C very efficiently. I wonder how
> long it took him to write it in C in the first place, even to setup the
> testing of C against R, or to write the blog post.
>
> He didn't say.
>
> Jeff
Yes, he did: he said he took the C code out of the fisher.test() R
function and just did a little bit of tweaking. So, it did not took too
long to reuse existing C code someone else wrote and debugged, for
sure... But, as you suggest, what about writing it from scratch in C or
R, that is the real question, of course!
Philippe
> Armstrong, Whit wrote on 01/09/2008 09:49 AM:
>> 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.
>
>
______________________________________________
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.
