Matrix assigning to double changes

[eddelbuettel]

Related to #562, this seems like a bug:

R> cppFunction("NumericMatrix testmat(int n, double fillme) { NumericMatrix M(n, n); M = fillme; return M; }") 
R> testmat(2L, 3)
     [,1] [,2] [,3]
[1,]    0    0    0
[2,]    0    0    0
[3,]    0    0    0
R> 

I was expecting a 2x2 matrix will with the value 3. No mas.

[thirdwing]

I think something like template <typename T> Matrix& operator=( const T& x) is missing.

This is not hard to fix, since we already have this in Vector. But I think there is something more we need to discuss.

In the Vector class, operator= is not used for filling. Maybe we should keep this consistent in Matrix.

#include<Rcpp.h>

using namespace Rcpp;

//[[Rcpp::export]]
NumericVector testvec(int n, double fillme) {
  NumericVector M(n);
  M = fillme;
  return M;
}

/*
> Rcpp::sourceCpp("test.cpp")
> testvec(2, 3)
[1] 3
*/

[eddelbuettel]

Great comments, and even better catch. That is dicey. Isn't the dimension change a bug?

[thirdwing]

Since we only have Matrix& operator=(const Matrix& other), so I think the compiler will try to convert fillme into a Matrix by calling the ctor Matrix( const int& n).

The we have a 3x3 matrix to assign to M.

[thirdwing]

After our discussion in #565 , I think we need to document this behavior.

[eddelbuettel]

Rcpp-FAQ entry, maybe?

[coatless]

In a section called.... ;-)

[eddelbuettel]

"Gotchas" ;-)

Just kidding. Maybe among the smorgasbord of examples? Making it 3.13 ?

[coatless]

I'm not sure "Examples" portrays the right optics...

"Known Behaviors"? "Known Issues"? "Documented Issues" ?

At this stage, it's semantics for a list of other topics at the top of #506 that need a home as well.

[eddelbuettel]

All other choise are worse, aren't they?

We cannot make Section 4 a new Section 5 as references break. And a new Section 5 'Warts and Other Unpleasant Things' past Section 4 is also weird.

If you feel you cannot morally contribute in Section 3 just enjoy your evening off or do something else.

If you must, "Section 5: Issues" has to be created with a content set of cardinality one. We could however add an entry there for the eternal issue "Rcpp changed the vector I passed by value" with a very short answer "no you didn't" 😀

[coatless]

@eddelbuettel: You know I am going to include that on the PR for the first documented issued.

How would you feel about a subsection within examples? Basically, it's not a moral objection, more so I'm worried about noise around "true" issues. Placing it within the main section of examples means a true issue is displayed directly next to a beginner's section (e.g. 3.12 "Can I use default function parameters with Rcpp?", which then details default parameters).

Recall the entire "corrupting seeds" debacle awhile back... Issues of that magnitude and design choice should be documented somewhere.

[eddelbuettel]

Yeah, that is the problem with "single track" listicles. Maybe "Section 5: Known Issues" really is the best we can do.

[coatless]

An alternative is to place known issues in a separate vignette. However, I feel that is just far too much. Perhaps this is better suited for the later API docs I mentioned?

[eddelbuettel]

I thought about that too, and also think it is too far. A FAQ really is the place.