Le 18/11/12 16:12, Hadley Wickham a écrit :
microbenchmark(
pdist1(0.5, ys),
pdist2(0.5, ys),
pdist3(0.5, ys)
)
# 10-fold slower?? Maybe it's because I'm using a double instead of
# a numeric vector?
That's weird. Not sure where the ineffiency is. Some hunting.
My guess is that sugar pow needs a refresh.
Ok, thanks.
I've been looking. I don't know what we do wrong. Expression templates
are a complicated beast.
cppFunction('
NumericVector pdist4(NumericVector x, NumericVector ys) {
return pow((x - ys), 2);
}
')
all.equal(pdist1(0.5, ys), pdist4(0.5, ys))
# Is this a bug in sugar? Should recycle to length of longest vector.
# Let's try flipping the order of operations:
There's no recycling. We pick the size of "x" and consider that y is of the
same length. Something worth mentionning in documentation. Recycling would
add some expense.
I think that should be called in large bold print somewhere! If you
don't do it automatically - could it at least be an error when the
sizes don't match? That doesn't seem like it should be an expensive
operation.
I'll look into it.
I would prefer to keep it that way and document it that vector should have
the same size, ... rather than introduce the extra cost of recyling.
I might also be nice to have some capabilities for explicit recycling.
I don't know if it would be possible to get it to work, but it would
be nice to have some sort of declarative syntax like:
recycle(x, y, z);
Hadley
In a way, we can already use sugar rep_len.
rep_len( x, 30 )
will recycle x into a vector of length 30, lazily.
--
Romain Francois
Professional R Enthusiast
+33(0) 6 28 91 30 30
R Graph Gallery: http://gallery.r-enthusiasts.com
`- http://bit.ly/SweN1Z : SuperStorm Sandy
blog: http://romainfrancois.blog.free.fr
|- http://bit.ly/RE6sYH : OOP with Rcpp modules
`- http://bit.ly/Thw7IK : Rcpp modules more flexible
_______________________________________________
Rcpp-devel mailing list
[email protected]
https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel