[Rcpp-devel] can one modify array in R memory from C++ without copying it?

[Dirk Eddelbuettel]

Darren,

On 6 November 2011 at 16:16, Darren Cook wrote:
| > If you feel really strongly about you could consider a patch that makes this
| > non-R behaviour you suggest an option.  To most of us who use Rcpp between R
| > and C++ it really is a feature.
| 
| Hello Dirk,
| Yes, I'm used to the implicit conversions from other scripting
| languages. Rcpp is at the join of languages with different philosophies:
| dynamically-typed R and statically-typed C++. But more than that: in R a
| very succinct script is regarded as a thing of beauty; in C++ explicitly
| describing conversions is regarded as good form by the experts.

Yes.
 
| This creates some interesting challenges for Rcpp!

Really?  

I think we support writing R code like you would otherwise, and the same for
C++ which one writes like C++ code. 

We simply make it easier to combine the two via Rcpp.
 
| Darren
| 
| P.S. As a realistic example of how implicit conversions turn into bugs:
| A developer tests with nice clean csv data, let's say it is stock OHLCV
| data, where the values are always integers. An integer vector is passed
| into Rcpp code, it modifies memory directly in some subtle way (e.g.
| adjusting values down based on data age).
| 
| He tests on years worth of data and thousands of symbols and is feeling
| very confident. Backtesting on the overall system shows it is making 10%
| a year.
| 
| This goes into production but one day the program giving the data
| changes and now has ".000000" on the end of all the integers.
| 
| R now treats it as doubles, Rcpp does an implicit conversion, is no
| longer using a pointer and the values no longer get adjusted.
| The data still looks plausible, it just hasn't been modified. The next
| step, machine learning, goes with this data, and makes different
| purchase recommendations. The system is making only 5% a year, but
| because it is still making money no-one even realizes something has
| broken.
| 
| Yes, better programmers would have validated their input data better,
| would have had more checks, and would have realized the potential for
| error. Real programmers on the other hand are human, make mistakes, and
| have deadlines.

Nice story. Can't wait for the movie version...

And that's why code gets tested.  Relying on your input data to be
transformed in place is NOT the paradigm commonly used either as you more
often have inputs a, b, c, .... for a function f() returning x, y, z, ...

In any way, it is moot.  You still haven't shown a bug---beyond the design
mistaken of assuming inputs were suitable for IntegerVector (or Matrix) when
that should have be Numeric all along.

This is blown way out of proportion.  As I said, the behaviour is documented,
and the corner case gets mentioned in all our talks too (see the Google Tech
Talk video for example).

Dirk
 

-- 
"Outside of a dog, a book is a man's best friend. Inside of a dog, it is too
dark to read." -- Groucho Marx