Gustaf Rydevik wrote:
> Hi all,
>
> Reading the wikipedia page on R, I stumbled across the following:
> http://fluff.info/blog/arch/0172.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
> knowled
> "Paul" == Paul Gilbert <[EMAIL PROTECTED]> writes:
> Gustaf Rydevik wrote:
>> The author also have some thought-provoking opinions on R
>> being no-good and that you should write everything in C
> People used to say assembler, that's progress.
>From the FORTRAN Preliminary
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.
>
[article: http://fluff.info/blog/arch/0172.htm ]
Duncan Murdoch wrote:
>
> If I followed Blair's advice and did everything in C, then
> development would take much longer, the code would be much buggier
> (even his example has bugs, and he admits it!!) and all those cases
> where R is fast
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
Armstron
Barry Rowlingson wrote:
> Gustaf Rydevik wrote:
>> Hi all,
>>
>> Reading the wikipedia page on R, I stumbled across the following:
>> http://fluff.info/blog/arch/0172.htm
>>
>> It does seem interesting that the C execution is that much slower from
>> R than from a native C program. Could any of
Gustaf Rydevik wrote:
> Hi all,
>
> Reading the wikipedia page on R, I stumbled across the following:
> http://fluff.info/blog/arch/0172.htm
>
There are certainly situations where one would want to consider faster
solutions than interpreted languages but, having been through these
argument
Gustaf Rydevik wrote:
> Hi all,
>
> Reading the wikipedia page on R, I stumbled across the following:
> http://fluff.info/blog/arch/0172.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
> knowledge
Hello Gustaf, List.
Thanks Gustaf for your post!
well I am working pretty intensively with fisher.test() right now, as
some of you will know.
The comparison is not fair: R's fisher.test() does a whole
bunch of error checking and testing for the size of the
input matrix and assessing of other a
On 1/9/2008 10:25 AM, Gustaf Rydevik wrote:
> Hi all,
>
> Reading the wikipedia page on R, I stumbled across the following:
> http://fluff.info/blog/arch/0172.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
Gustaf Rydevik wrote:
> Hi all,
>
> Reading the wikipedia page on R, I stumbled across the following:
> http://fluff.info/blog/arch/0172.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
> knowled
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),
12 matches
Mail list logo
