Re: [R] An R is slow-article

2008-01-10 Thread Tom Backer Johnsen
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 knowledgeable

[R] An R is slow-article

2008-01-09 Thread Gustaf Rydevik
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 knowledgeable people explain why this is so?

Re: [R] An R is slow-article

2008-01-09 Thread Armstrong, Whit
- 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

Re: [R] An R is slow-article

2008-01-09 Thread Barry Rowlingson
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 knowledgeable

Re: [R] An R is slow-article

2008-01-09 Thread Duncan Murdoch
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

Re: [R] An R is slow-article

2008-01-09 Thread Peter Dalgaard
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 knowledgeable

Re: [R] An R is slow-article

2008-01-09 Thread Paul Gilbert
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 arguments a

Re: [R] An R is slow-article

2008-01-09 Thread Marc Schwartz
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 the more

Re: [R] An R is slow-article

2008-01-09 Thread Jeffrey Horner
(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

Re: [R] An R is slow-article

2008-01-09 Thread Alberto Monteiro
[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

Re: [R] An R is slow-article

2008-01-09 Thread Robin Hankin
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

Re: [R] An R is slow-article

2008-01-09 Thread Michael A. Miller
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 Report, IBM,