On 19 February 2013 at 12:26, Gong-Yi Liao wrote:
|
| I read the 'Limitation' part of RppCNPy package's document
| (RcppCNPy-intro) and found:
|
| "So until R switches to allowing -std=c++0x on CRAN packages, users will
| need to rebuild both Rcpp and RcppCNPy with the switch enabled."
|
| Does that means putting '-std=c++11' in CXXFLAGS while building
| RcppCNPy will not work ? ( I have build Rcpp with -std=c++11 without any
| problem)
Ouch. Forget about that one. You are quite right. The full context is:
\subsection{Integer support}
Support for integer data types is conditional on use of the \code{-std=c++0x}
compiler extension. Only the newer standard supports the \code{long long int}
type needed to represent \code{int64} data on a 32-bit OS. So until \R
switches to allowing \code{-std=c++0x} on CRAN packages, users will need to
rebuild both \pkg{Rcpp} and \pkg{RcppCNPy} with the switch enabled. As shown
in the previous examples, integers also transparently convert to float types.
So you are caught between a rock and a hard place. If the build currently
fails with -std=c++0x (or -std=c++11) you will need to debug it. I believe
this worked at some point --- I did a few quick releases last summer but
removed integer support relatively early on.
As the paragraph states, NumPy uses 64bit ints, and we only get those
(portably) in R via long long int, which in turn requires the currently
unsupported (at CRAN) C++11 switch.
| The reason I need to have '-std=c++0x' (or c++11) is loading the integer
| data in np.array, I have done some simple experiment:
|
| === In Python ==
| In [1]: x = pylab.randn(100, 3)
| In [2]: y = pylab.poisson(lam=3.5, size=200]
| In [3]: numpy.save('test.npy', [x, y])
|
|
| == In R (RcppCNPy is build without '-std=c++0x' )====
| > library(RcppCNPy)
| > z <- load('test.npy')
| Error in npyLoad("test.npy") : littleEndian error
|
| So, I thought that rebuilding RcppCNPy with '-std=c++0x' can help me to
| read the integer data restored in a .npy file.
|
| Is there any way to process the integer data restored in .npy file other
| than
| ==== In Python =====
| In [1]: y = pylab.double(poission(lam=3.5, size=200)
| In [2]: numpy.save('test.npy', [x, y])
|
| ?
I don't think so / I don't know. I really needed float / double support, so
I made that work. For the rest you are on your own. If I get some time I
will take a look, but I can't promise anything.
If you are on a 64-bit OS you may get by with long int but this will not, I
fear, extend to 32-bit and is hence not something I can put into a CRAN
release.
Sorry!
Dirk
|
| Gong.
|
|
| On 02/19/2013 11:57 AM, Dirk Eddelbuettel wrote:
| > On 19 February 2013 at 11:47, Gong-Yi Liao wrote:
| > | * installing *source* package ‘RcppCNPy’ ...
| > | ** package ‘RcppCNPy’ successfully unpacked and MD5 sums checked
| > | ** libs
| > | g++ -I/usr/share/R/include -DNDEBUG
| > | -I"/usr/local/lib/R/site-library/Rcpp/include" -fpic -std=c++11 -O2
| > | -pipe -g -c cnpy.cpp -o cnpy.o
| >
| > Please remove the -std=c++11 from your CXXFLAGS (or however it crept in).
| >
| > CRAN does not accept it, the package is maintained and supported as a CRAN
| > package. If you need extensions (such as the C++11 support) you are
| > currently on your own.
| >
| > | It seems that this problem is caused by some function defined
| > | in"codecvt.h".
| > | Does anyone have encountered similar problem ?
| >
| > It may be a simple matter of include file order. I don't know.
| >
| > Dirk
| >
|
|
| --
| Gong-Yi Liao
| Department of Statistics
| University of Connecticut
|
--
Dirk Eddelbuettel | e...@debian.org | http://dirk.eddelbuettel.com
_______________________________________________
Rcpp-devel mailing list
Rcpp-devel@lists.r-forge.r-project.org
https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel
