On 30 November 2012 at 07:57, Gabor Grothendieck wrote:
| to wrestle with SEXPs. If the alternative is to work with SEXPs
| directly then the alternative certainly is painful but if the
| alternative is to use .C (and that may not be a feasible alternative
| in some or many cases due to its rest
On Fri, Nov 30, 2012 at 1:34 AM, Walter Mascarenhas
wrote:
> listening to criticism is a good way to keep a balanced view of things.
Just to be clear I don't regard my comments as criticism of Rcpp. I
was commenting on the document for which comments had been solicited.
Rcpp is much more general
On 30 November 2012 at 06:37, Dirk Eddelbuettel wrote:
| Here is Simon Urnbanked on May 26, but I don't right now find this on gmane
Jeebus: "Simon Urbanek", of course. I should really stop with this thread...
Dirk
--
Dirk Eddelbuettel | e...@debian.org | http://dirk.eddelbuettel.com
_
On 30 November 2012 at 15:52, Darren Cook wrote:
| > Rcpp is a worthwhile effort and your work is admirable, but
| > it is not perfect. ... (if you care about that, of course).
|
| I think Dirk's point was that this is an interesting topic, but this
| list is the wrong place for discussing it.
> Rcpp is a worthwhile effort and your work is admirable, but
> it is not perfect. ... (if you care about that, of course).
I think Dirk's point was that this is an interesting topic, but this
list is the wrong place for discussing it.
(Dirk, I couldn't track down the r-devel discussion you ment
I don't mean to come down hard on you personally, but consider that
listening to criticism is a good way to keep a balanced view of things.
It is natural for you to defend rcpp and your views on R and C++,
However I do believe Gabor points are also relevant, in the same
way that Knuth, Linus
On 29 November 2012 at 19:08, Gabor Grothendieck wrote:
| That is only the case if you don't know C or C++ . Many people who
| are using these interfaces already know C and in that case the .C
| interface is trivial (its just a simple interface) whereas Rcpp is a
| new environment you have to le
On Thu, Nov 29, 2012 at 10:37 AM, Hadley Wickham wrote:
>> Nice document but it would be good to distinguish between the C
>> interfaces -- the .C interface may not be fully general; however, it
>> is adequate for a lot of numerical work such as writing the objective
>> function and gradient in op
> > Nice document but it would be good to distinguish between the C
> > interfaces -- the .C interface may not be fully general; however, it
> > is adequate for a lot of numerical work such as writing the objective
> > function and gradient in optimization routines and is not painful at
> > all.
>
> Nice document but it would be good to distinguish between the C
> interfaces -- the .C interface may not be fully general; however, it
> is adequate for a lot of numerical work such as writing the objective
> function and gradient in optimization routines and is not painful at
> all.
I guess my
Gabor makes my (minor) point with greater eloquence. I certainly am not
arguing against the value of Rcpp, and I agree completely with Hadley on
the inconsistencies if we're talking about .Call and SEXP, etc...
> Nice document but it would be good to distinguish between the C
> interfaces -- the
On Thu, Nov 29, 2012 at 8:34 AM, Hadley Wickham wrote:
>> I've printed this out and will sit down with it sometime in the next week.
>> One (personal opinion) edit -- the following:
>>
>> " It is possible to write high performance code in C or Fortran. This
>> might produce faster code than C++ (b
On 29 November 2012 at 15:05, Romain Francois wrote:
| In my view people should want to "write performance code" not "write C
| code" or "write C++ code", and Rcpp is a very good candidate for this.
Very nicely put. We really don't need to diss or put down other languages
all of which are viabl
On 29 November 2012 at 07:46, Hadley Wickham wrote:
| Sure - I've attached a rough pdf version made with pandoc.
That is kind and helpful, but makes work for me :-/ as the list runs with the
mailman defaults which have the (IMHO) sensible 40k limit.
Can you edit the wiki version of the book t
Le 29/11/12 15:00, Hadley Wickham a écrit :
I'm not sure I'd go quite this far in ragging on the C API. For someone who
wants to write plain-vanilla C code (without C++) working on vectors and
matrices, it really seems acceptable to me. If someone doesn't have at
least some basic technical abil
> I'm not sure I'd go quite this far in ragging on the C API. For someone who
> wants to write plain-vanilla C code (without C++) working on vectors and
> matrices, it really seems acceptable to me. If someone doesn't have at
> least some basic technical ability, they shouldn't be writing C or C+
I'm not sure I'd go quite this far in ragging on the C API. For someone
who wants to write plain-vanilla C code (without C++) working on vectors
and matrices, it really seems acceptable to me. If someone doesn't have at
least some basic technical ability, they shouldn't be writing C or C++
code,
> I've printed this out and will sit down with it sometime in the next week.
> One (personal opinion) edit -- the following:
>
> " It is possible to write high performance code in C or Fortran. This
> might produce faster code than C++ (but probably not), but it will
> take you much much longer to
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 28/11/12 18:41, Hadley Wickham wrote:
This is exactly what was missing: the vignettes are perfect - they contain
everything one needs,
but it is easy to get lost in them if one does not understand the basics. And
the basics are C++
for R users a
Hi all,
I've been working on a beginners guide to Rcpp at
https://github.com/hadley/devtools/wiki/Rcpp. The aim is to help R
programmers get the basics of C++ so that they can start to write
efficiently code as quickly and easily as possible.
I'd love your feedback - what have I missed? what is
20 matches
Mail list logo
