Re: [Rcpp-devel] trans() changed in latest RcppArmadillo
On 29 May 2011 at 21:26, Savitsky, Terrance wrote: | Hello, After upgrading to the 0.2.21 release of RcppArmadillo, my previously | working code (across many functions) ceased working (on a Windows XP | installation). I re-installed the previous version (0.2.20) from CRAN (via a | server location not yet updated to 0.2.21); didn?t fix it. The timing may be | a coincidence, though reading the post on trans() encourages me to make this | post. While I use ?trans? across my functions, it is not applied on | complex-valued matrices; only real-valued. So the prior post wouldn?t explain | my issue. As should be clear from the NEWS file I posted, 0.2.20 and 0.2.21 are both using pre-releases of Armadillo 2.0.0 --- so you get the 'new' trans() and other behaviour in both cases. Conrad's 1.99.2 in 0.2.20 brought a lot of changes. Hence you want to download 0.2.19 which uses Armadillo 1.2.0. Actual bug reports with replicable code would help us address any underlying issues. Dirk -- Gauss once played himself in a zero-sum game and won $50. -- #11 at http://www.gaussfacts.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
Re: [Rcpp-devel] trans() changed in latest RcppArmadillo
On 30 May 2011, Terrance Savitsky wrote: > Hello, After upgrading to the 0.2.21 release of RcppArmadillo, my > previously working code (across many functions) ceased working (on a > Windows XP installation). I re-installed the previous version (0.2.20) > from CRAN (via a server location not yet updated to 0.2.21); didn't fix it. > The timing may be a coincidence, though reading the post on > trans() encourages me to make this post. While I use 'trans' across my > functions, it is not applied on complex-valued matrices; only > real-valued. So the prior post wouldn't explain my issue. Hi, I'm the main author of Armadillo. I'm interested in hearing about all regressions -- can you provide more details ? There have been a lot of changes between Armadillo 1.2 and the latest beta (1.99.3). I'd like to shake out all known bugs before releasing 2.0. Cheers, Conrad -- Dr Conrad Sanderson : Sr Research Scientist : NICTA : http://arma.sf.net/cs ___ 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
[Rcpp-devel] RcppArmadillo fails on FreeBSD
I tried RcppArmadillo_0.2.21.tar.gz with R-devel from today on FreeBSD 9.0-CURRENT (amd64). The build fails with the following messages: -- #R CMD INSTALL RcppArmadillo_0.2.21.tar.gz * installing to library '/usr/local/lib/R/library' * installing *source* package 'RcppArmadillo' ... ** libs g++45 -I/usr/local/lib/R/include -I"/usr/local/lib/R/library/Rcpp/include" -I../inst/include -fpic -O2 -pipe -Wl,-rpath=/usr/local/lib/gcc45 -fno-strict-aliasing -c RcppArmadillo.cpp -o RcppArmadillo.o In file included from ../inst/include/armadillo:113:0, from ../inst/include/RcppArmadilloForward.h:36, from ../inst/include/RcppArmadillo.h:25, from RcppArmadillo.cpp:22: ../inst/include/armadillo_bits/format_wrap.hpp: In function 'std::string arma::arma_boost::str(const arma::arma_boost::basic_format&)': ../inst/include/armadillo_bits/format_wrap.hpp:146:25: error: 'snprintf' is not a member of 'std' ../inst/include/armadillo_bits/format_wrap.hpp: In function 'std::string arma::arma_boost::str(const arma::arma_boost::basic_formatT2>, T3>&)': ../inst/include/armadillo_bits/format_wrap.hpp:198:25: error: 'snprintf' is not a member of 'std' ../inst/include/armadillo_bits/format_wrap.hpp: In function 'std::string arma::arma_boost::str(const arma::arma_boost::basic_formatT2>, T3>, T4>&)': ../inst/include/armadillo_bits/format_wrap.hpp:250:25: error: 'snprintf' is not a member of 'std' ../inst/include/armadillo_bits/format_wrap.hpp: In function 'std::string arma::arma_boost::str(const arma::arma_boost::basic_formatT2>, T3>, T4>, T5>&)': ../inst/include/armadillo_bits/format_wrap.hpp:302:25: error: 'snprintf' is not a member of 'std' ../inst/include/armadillo_bits/format_wrap.hpp: In function 'std::string arma::arma_boost::str(const arma::arma_boost::basic_formatT2>, T3>, T4>, T5>, T6>&)': ../inst/include/armadillo_bits/format_wrap.hpp:354:25: error: 'snprintf' is not a member of 'std' In file included from ../inst/include/armadillo:113:0, from ../inst/include/RcppArmadilloForward.h:36, from ../inst/include/RcppArmadillo.h:25, from RcppArmadillo.cpp:22: ../inst/include/armadillo_bits/format_wrap.hpp: In function 'std::string arma::arma_boost::str(const arma::arma_boost::basic_formatT2>, T3>, T4>, T5>, T6>, T7>&)': ../inst/include/armadillo_bits/format_wrap.hpp:406:25: error: 'snprintf' is not a member of 'std' *** Error code 1 Stop in /tmp/RtmpXKyP4Y/R.INSTALL4dde5c9e/RcppArmadillo/src. ERROR: compilation failed for package 'RcppArmadillo' * removing '/usr/local/lib/R/library/RcppArmadillo' -- Obviously there is something wrong with 'snprintf'. The appended patch avoids the breakage. On the other hand the is a definition on FreeBSD for 'snprintf' in libc's stdio (/usr/src/lib/libc/stdio/snprintf.c). There is a short hint in the manpage: SYNOPSIS #define _WITH_DPRINTF #include int snprintf(char * restrict str, size_t size, const char * restrict format, ...); If this is the same function as meant in 'RcppArmadilloConfig.h' is there any way to integrate it into the package? Please let me know if I can test something. Many thanks in advance, Rainer Hurling --- inst/include/RcppArmadilloConfig.h.origin 2011-05-27 17:18:47.0 +0200 +++ inst/include/RcppArmadilloConfig.h 2011-05-30 13:53:25.0 +0200 @@ -37,7 +37,7 @@ /* TODO: we might need to undef this on other platforms as well */ -#if defined(__GNUC__) && defined(_WIN64) +#if defined(__GNUC__) && defined(_WIN64) || defined(__FreeBSD__) #undef ARMA_HAVE_STD_SNPRINTF #endif ___ 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
Re: [Rcpp-devel] RcppArmadillo fails on FreeBSD
On 30 May 2011 at 15:43, Rainer Hurling wrote: | I tried RcppArmadillo_0.2.21.tar.gz with R-devel from today on FreeBSD | 9.0-CURRENT (amd64). The build fails with the following messages: | | -- | #R CMD INSTALL RcppArmadillo_0.2.21.tar.gz | * installing to library '/usr/local/lib/R/library' | * installing *source* package 'RcppArmadillo' ... | ** libs | g++45 -I/usr/local/lib/R/include | -I"/usr/local/lib/R/library/Rcpp/include" -I../inst/include -fpic -O2 | -pipe -Wl,-rpath=/usr/local/lib/gcc45 -fno-strict-aliasing -c | RcppArmadillo.cpp -o RcppArmadillo.o | In file included from ../inst/include/armadillo:113:0, | from ../inst/include/RcppArmadilloForward.h:36, | from ../inst/include/RcppArmadillo.h:25, | from RcppArmadillo.cpp:22: | ../inst/include/armadillo_bits/format_wrap.hpp: In function 'std::string | arma::arma_boost::str(const | arma::arma_boost::basic_format&)': | ../inst/include/armadillo_bits/format_wrap.hpp:146:25: error: 'snprintf' | is not a member of 'std' | ../inst/include/armadillo_bits/format_wrap.hpp: In function 'std::string | arma::arma_boost::str(const | arma::arma_boost::basic_format, T3>&)': | ../inst/include/armadillo_bits/format_wrap.hpp:198:25: error: 'snprintf' | is not a member of 'std' | ../inst/include/armadillo_bits/format_wrap.hpp: In function 'std::string | arma::arma_boost::str(const | arma::arma_boost::basic_format, T3>, T4>&)': | ../inst/include/armadillo_bits/format_wrap.hpp:250:25: error: 'snprintf' | is not a member of 'std' | ../inst/include/armadillo_bits/format_wrap.hpp: In function 'std::string | arma::arma_boost::str(const | arma::arma_boost::basic_format, T3>, T4>, T5>&)': | ../inst/include/armadillo_bits/format_wrap.hpp:302:25: error: 'snprintf' | is not a member of 'std' | ../inst/include/armadillo_bits/format_wrap.hpp: In function 'std::string | arma::arma_boost::str(const | arma::arma_boost::basic_format, T3>, T4>, T5>, T6>&)': | ../inst/include/armadillo_bits/format_wrap.hpp:354:25: error: 'snprintf' | is not a member of 'std' | In file included from ../inst/include/armadillo:113:0, | from ../inst/include/RcppArmadilloForward.h:36, | from ../inst/include/RcppArmadillo.h:25, | from RcppArmadillo.cpp:22: | ../inst/include/armadillo_bits/format_wrap.hpp: In function 'std::string | arma::arma_boost::str(const | arma::arma_boost::basic_format, T3>, T4>, T5>, T6>, T7>&)': | ../inst/include/armadillo_bits/format_wrap.hpp:406:25: error: 'snprintf' | is not a member of 'std' | *** Error code 1 | Stop in /tmp/RtmpXKyP4Y/R.INSTALL4dde5c9e/RcppArmadillo/src. | ERROR: compilation failed for package 'RcppArmadillo' | * removing '/usr/local/lib/R/library/RcppArmadillo' | -- | | | Obviously there is something wrong with 'snprintf'. The appended patch | avoids the breakage. | | On the other hand the is a definition on FreeBSD for 'snprintf' in | libc's stdio (/usr/src/lib/libc/stdio/snprintf.c). There is a short hint | in the manpage: | | SYNOPSIS |#define _WITH_DPRINTF |#include | int | snprintf(char * restrict str, size_t size, |const char * restrict format, ...); | | If this is the same function as meant in 'RcppArmadilloConfig.h' is | there any way to integrate it into the package? Please let me know if I | can test something. I do not understand what you are asking: "as meant in RcppArmadilloConfig" ? Neither Romain, Doug nor I use a *BSD variant (if we ignore OS X as a BSD-derivative). So nothing in RcppArmadillo explicitly enables or disables *BSD. You have to tell us what works or doesn't. We cannot test or develop changes for *BSD. | Many thanks in advance, | Rainer Hurling | | -- | --- inst/include/RcppArmadilloConfig.h.origin 2011-05-27 17:18:47.0 +0200 | +++ inst/include/RcppArmadilloConfig.h2011-05-30 13:53:25.0 +0200 | @@ -37,7 +37,7 @@ | | | /* TODO: we might need to undef this on other platforms as well */ | -#if defined(__GNUC__) && defined(_WIN64) | +#if defined(__GNUC__) && defined(_WIN64) || defined(__FreeBSD__) | #undef ARMA_HAVE_STD_SNPRINTF | #endif That patch looks fine to me and would presumabky play nicely with Armadillo as the change would be solely at our level. I'll apply it it now, so 0.2.22 will have it. Dirk -- Gauss once played himself in a zero-sum game and won $50. -- #11 at http://www.gaussfacts.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
Re: [Rcpp-devel] RcppArmadillo fails on FreeBSD
On 30.05.2011 16:24 (UTC+1), Dirk Eddelbuettel wrote: On 30 May 2011 at 15:43, Rainer Hurling wrote: | I tried RcppArmadillo_0.2.21.tar.gz with R-devel from today on FreeBSD | 9.0-CURRENT (amd64). The build fails with the following messages: | | -- | #R CMD INSTALL RcppArmadillo_0.2.21.tar.gz | * installing to library '/usr/local/lib/R/library' | * installing *source* package 'RcppArmadillo' ... | ** libs | g++45 -I/usr/local/lib/R/include | -I"/usr/local/lib/R/library/Rcpp/include" -I../inst/include -fpic -O2 | -pipe -Wl,-rpath=/usr/local/lib/gcc45 -fno-strict-aliasing -c | RcppArmadillo.cpp -o RcppArmadillo.o | In file included from ../inst/include/armadillo:113:0, | from ../inst/include/RcppArmadilloForward.h:36, | from ../inst/include/RcppArmadillo.h:25, | from RcppArmadillo.cpp:22: | ../inst/include/armadillo_bits/format_wrap.hpp: In function 'std::string | arma::arma_boost::str(const | arma::arma_boost::basic_format&)': | ../inst/include/armadillo_bits/format_wrap.hpp:146:25: error: 'snprintf' | is not a member of 'std' | ../inst/include/armadillo_bits/format_wrap.hpp: In function 'std::string | arma::arma_boost::str(const | arma::arma_boost::basic_format, T3>&)': | ../inst/include/armadillo_bits/format_wrap.hpp:198:25: error: 'snprintf' | is not a member of 'std' | ../inst/include/armadillo_bits/format_wrap.hpp: In function 'std::string | arma::arma_boost::str(const | arma::arma_boost::basic_format, T3>, T4>&)': | ../inst/include/armadillo_bits/format_wrap.hpp:250:25: error: 'snprintf' | is not a member of 'std' | ../inst/include/armadillo_bits/format_wrap.hpp: In function 'std::string | arma::arma_boost::str(const | arma::arma_boost::basic_format, T3>, T4>, T5>&)': | ../inst/include/armadillo_bits/format_wrap.hpp:302:25: error: 'snprintf' | is not a member of 'std' | ../inst/include/armadillo_bits/format_wrap.hpp: In function 'std::string | arma::arma_boost::str(const | arma::arma_boost::basic_format, T3>, T4>, T5>, T6>&)': | ../inst/include/armadillo_bits/format_wrap.hpp:354:25: error: 'snprintf' | is not a member of 'std' | In file included from ../inst/include/armadillo:113:0, | from ../inst/include/RcppArmadilloForward.h:36, | from ../inst/include/RcppArmadillo.h:25, | from RcppArmadillo.cpp:22: | ../inst/include/armadillo_bits/format_wrap.hpp: In function 'std::string | arma::arma_boost::str(const | arma::arma_boost::basic_format, T3>, T4>, T5>, T6>, T7>&)': | ../inst/include/armadillo_bits/format_wrap.hpp:406:25: error: 'snprintf' | is not a member of 'std' | *** Error code 1 | Stop in /tmp/RtmpXKyP4Y/R.INSTALL4dde5c9e/RcppArmadillo/src. | ERROR: compilation failed for package 'RcppArmadillo' | * removing '/usr/local/lib/R/library/RcppArmadillo' | -- | | | Obviously there is something wrong with 'snprintf'. The appended patch | avoids the breakage. | | On the other hand the is a definition on FreeBSD for 'snprintf' in | libc's stdio (/usr/src/lib/libc/stdio/snprintf.c). There is a short hint | in the manpage: | | SYNOPSIS |#define _WITH_DPRINTF |#include | int | snprintf(char * restrict str, size_t size, |const char * restrict format, ...); | | If this is the same function as meant in 'RcppArmadilloConfig.h' is | there any way to integrate it into the package? Please let me know if I | can test something. I do not understand what you are asking: "as meant in RcppArmadilloConfig" ? Neither Romain, Doug nor I use a *BSD variant (if we ignore OS X as a BSD-derivative). So nothing in RcppArmadillo explicitly enables or disables *BSD. Thanks for answering. Sorry for my bad english and the misunderstanding. I am not a developer so the following is just a wild guess: In FreeBSD there is a function snprintf in stdio of libc. I was wondering if this could be the function, which RcppArmadillo would expect to find (on linux etc.) at std:snprintf? If yes, is there some chance to use this type of snprintf on FreeBSD systems? Or is my below patch ok and there is no problem not using snprintf (on FreeBSD) at all? Hope this is not totally nonsense. You have to tell us what works or doesn't. We cannot test or develop changes for *BSD. | Many thanks in advance, | Rainer Hurling | | -- | --- inst/include/RcppArmadilloConfig.h.origin 2011-05-27 17:18:47.0 +0200 | +++ inst/include/RcppArmadilloConfig.h2011-05-30 13:53:25.0 +0200 | @@ -37,7 +37,7 @@ | | | /* TODO: we might need to undef this on other platforms as well */ | -#if defined(__GNUC__)&& defined(_WIN64) | +#if defined(__GNUC__)&& defined(_WIN64) || defined(__FreeBSD__) | #undef ARMA_HAVE_STD_SNPRINTF | #endif That patch looks fine to me and would presumabky play nicely with Armadillo as the change would be so
Re: [Rcpp-devel] trans() changed in latest RcppArmadillo
Hello Dr. Sanderson. Thank you, so much, for your work; along with the work of Dirk and Romain, your tools make it possible for me to have impact I otherwise would never achieve. Anyway, I separately tested my (typical) use of trans() in a simple code and received no problems. I have various Rcpp-written functions that perform Bayesian regression modeling; so I'm simulating samples from a set of conditional distributions. Until last night, I'd used these functions for some months on a particular dataset without incident (though I've intermittently tuned them for speed and functionality). Anyway, further analysis suggests that I'm experiencing numerical instability not previously an issue. I noted that Armadillo included some changes for faster inverse computation on small size matrices. Was there an algorithm change that might allow such instability? I intend to test by replacing inv() with pinv(). Thanks, Terrance -Original Message- From: Conrad Sand [mailto:conradsand.r...@gmail.com] Sent: Monday, May 30, 2011 6:34 AM To: rcpp-de...@r-forge.wu-wien.ac.at Cc: Savitsky, Terrance Subject: Re: trans() changed in latest RcppArmadillo On 30 May 2011, Terrance Savitsky wrote: > Hello, After upgrading to the 0.2.21 release of RcppArmadillo, my > previously working code (across many functions) ceased working (on a > Windows XP installation). I re-installed the previous version (0.2.20) > from CRAN (via a server location not yet updated to 0.2.21); didn't fix it. > The timing may be a coincidence, though reading the post on > trans() encourages me to make this post. While I use 'trans' across my > functions, it is not applied on complex-valued matrices; only > real-valued. So the prior post wouldn't explain my issue. Hi, I'm the main author of Armadillo. I'm interested in hearing about all regressions -- can you provide more details ? There have been a lot of changes between Armadillo 1.2 and the latest beta (1.99.3). I'd like to shake out all known bugs before releasing 2.0. Cheers, Conrad -- Dr Conrad Sanderson : Sr Research Scientist : NICTA : http://arma.sf.net/cs __ This email message is for the sole use of the intended recipient(s) and may contain confidential information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. ___ 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
Re: [Rcpp-devel] RcppArmadillo fails on FreeBSD
On 30 May 2011 at 17:21, Rainer Hurling wrote:
| > I do not understand what you are asking: "as meant in RcppArmadilloConfig" ?
| > Neither Romain, Doug nor I use a *BSD variant (if we ignore OS X as a
BSD-derivative).
| > So nothing in RcppArmadillo explicitly enables or disables *BSD.
|
| Thanks for answering. Sorry for my bad english and the misunderstanding.
| I am not a developer so the following is just a wild guess:
|
| In FreeBSD there is a function snprintf in stdio of libc. I was
| wondering if this could be the function, which RcppArmadillo would
| expect to find (on linux etc.) at std:snprintf?
|
| If yes, is there some chance to use this type of snprintf on FreeBSD
| systems? Or is my below patch ok and there is no problem not using
| snprintf (on FreeBSD) at all?
|
| Hope this is not totally nonsense.
Between you and me, somebody is confused.
snprintf is a standard C library function going (IIRC) back to Kernighan and
Ritchie. My system's manual page shows
int snprintf(char *str, size_t size, const char *format, ...);
which is the same as what you quoted:
int snprintf(char * restrict str, size_t size, const char * restrict
format, ...);
apart from the sole difference of 'restrict' which I've never seen before.
So per se, we should not need anything special to use snprintf. Can you try
something like this on your box, please?
edd@max:/tmp$ gcc -Wall -o rainer rainer.c
edd@max:/tmp$ ./rainer
Char vector is now [Hello, world]
edd@max:/tmp$ cat rainer.c
#include
int main(void) {
char foo[32];
snprintf(foo, 31, "Hello, world");
printf("Char vector is now [%s]\n", foo);
return(0);
}
edd@max:/tmp$
We may have turned snprintf off for you by accident, but following your patch
we should now be good.
Unless I am totally undercaffeinated and missing something here.
Dirk
| > You have to tell us what works or doesn't. We cannot test or develop changes
| > for *BSD.
| >
| > | Many thanks in advance,
| > | Rainer Hurling
| > |
| > | --
| > | --- inst/include/RcppArmadilloConfig.h.origin 2011-05-27
17:18:47.0 +0200
| > | +++ inst/include/RcppArmadilloConfig.h2011-05-30 13:53:25.0
+0200
| > | @@ -37,7 +37,7 @@
| > |
| > |
| > | /* TODO: we might need to undef this on other platforms as well */
| > | -#if defined(__GNUC__)&& defined(_WIN64)
| > | +#if defined(__GNUC__)&& defined(_WIN64) || defined(__FreeBSD__)
| > | #undef ARMA_HAVE_STD_SNPRINTF
| > | #endif
| >
| > That patch looks fine to me and would presumabky play nicely with Armadillo
| > as the change would be solely at our level.
| >
| > I'll apply it it now, so 0.2.22 will have it.
|
| Thanks for including the patch,
| Rainer
|
| > Dirk
--
Gauss once played himself in a zero-sum game and won $50.
-- #11 at http://www.gaussfacts.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
Re: [Rcpp-devel] trans() changed in latest RcppArmadillo
Dr. Sanderson, I've been able to verify that my issue resides in the inv() function (that I typically apply to small p x p matrices, where p = 3 - 10). In particular, the new version/algorithm induces numerical instability. I've not yet tested that the results of the inv() computation are generally accurate, only that they are not numerically robust in comparison to 0.2.19. I'm up against a deadline, so I switched back to 0.2.19, which resolves my problem, for now, but will provide a reproducible example when finished with my work. Terrance -Original Message- From: Conrad Sand [mailto:conradsand.r...@gmail.com] Sent: Monday, May 30, 2011 6:34 AM To: rcpp-de...@r-forge.wu-wien.ac.at Cc: Savitsky, Terrance Subject: Re: trans() changed in latest RcppArmadillo On 30 May 2011, Terrance Savitsky wrote: > Hello, After upgrading to the 0.2.21 release of RcppArmadillo, my > previously working code (across many functions) ceased working (on a > Windows XP installation). I re-installed the previous version (0.2.20) > from CRAN (via a server location not yet updated to 0.2.21); didn't fix it. > The timing may be a coincidence, though reading the post on > trans() encourages me to make this post. While I use 'trans' across my > functions, it is not applied on complex-valued matrices; only > real-valued. So the prior post wouldn't explain my issue. Hi, I'm the main author of Armadillo. I'm interested in hearing about all regressions -- can you provide more details ? There have been a lot of changes between Armadillo 1.2 and the latest beta (1.99.3). I'd like to shake out all known bugs before releasing 2.0. Cheers, Conrad -- Dr Conrad Sanderson : Sr Research Scientist : NICTA : http://arma.sf.net/cs __ This email message is for the sole use of the intended recipient(s) and may contain confidential information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. ___ 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
Re: [Rcpp-devel] package .onLoad multiple modules
Le 30/05/11 01:56, baptiste auguie a écrit :
Thanks, that is helpful. I think I have nailed down the problem.
I defined a wrapper at R level that used a C++ function from a module
named "cd",
circular_dichroism_spectrum<- function( ... ){
[...] # some argument processing
res<- cd$circular_dichroism_spectrum(...) # calling the C++ function
return(res)
}
Now, with loadRcppModules(), no "cd" module is created, as far as I
can tell, and invoking circular_dichroism_spectrum() is calling the
C++ function directly; a segfault results because some of the
arguments differ between the C++ function and its R wrapper.
I see two options:
- choose a different name for the R and C++ functions
- manage some kind of namespace masking the C++ function from the
top-level, like cd$ did before. Is there a way to do this in the
loadRcppModules() approach?
Not currently. functions and classes are directly exposed in the
namespace. I guess we could add an argument to control that.
In the meantime, I'd use your first option.
Best regards,
baptiste
On 30 May 2011 11:11, Dirk Eddelbuettel wrote:
On 30 May 2011 at 10:29, baptiste auguie wrote:
| Hi,
|
| On 30 May 2011 04:28, Dirk Eddelbuettel wrote:
|>
|> On 29 May 2011 at 18:56, baptiste auguie wrote:
|> | Dear list,
|> |
|> | [Disclaimer: I am not very familiar with Rcpp/C++, and probably
|> | haven't followed all the relevant discussions on this list.]
|> |
|> | I'm trying to tidy up two packages on r-forge [*] before submitting
|> | them to CRAN. In "cda/zzz.r", I have the following code,
|> |
|> | NAMESPACE<- environment()
|> | cda<- new( "Module" )
|> | cdatests<- new( "Module" )
|> | cd<- new( "Module" )
|> | linear<- new( "Module" )
|> | array<- new( "Module" )
|> |
|> | .onLoad<- function(libname, pkgname){
|> | unlockBinding( "cda" , NAMESPACE )
|> | unlockBinding( "cdatests" , NAMESPACE )
|> | unlockBinding( "cd" , NAMESPACE )
|> | unlockBinding( "linear" , NAMESPACE )
|> | assign( "cda", Module( "cda" ), NAMESPACE )
|> | assign( "cdatests", Module( "cdatests" ), NAMESPACE )
|> | assign( "cd", Module( "cd" ), NAMESPACE )
|> | assign( "linear", Module( "linear" ), NAMESPACE )
|> | lockBinding( "cda", NAMESPACE )
|> | lockBinding( "cdatests", NAMESPACE )
|> | lockBinding( "cd", NAMESPACE )
|> | lockBinding( "linear", NAMESPACE )
|> |
|> | unlockBinding( "array" , NAMESPACE )
|> | assign( "array", Module( "array" ), NAMESPACE )
|> | lockBinding( "array", NAMESPACE )
|> |
|> | }
|> |
|> | It seems to work, but is there something I can/should do to make this
|> | a wee cleaner?
|>
|> Have another look at the Rcpp-modules vignette, and/or the third set of
|> slides ("Advanced Rcpp") from our class in April -- you no longer need the
|> unlockBinding / lockBinding business as Romain internalized that. The
|> skeleton-generated packages now just do this in zzz.R:
|>
|>.onLoad<- function(pkgname, libname){
|>loadRcppModules()
|>}
|>
|> using a 'RcppModules: cda, cdatests, cd, linear, array' declaration in
|> DESCRIPTION.
|
| Strange, this does not seem to work for me.
|
| If I use the following zzz.r, (with RcppModules listed in DESCRIPTION)
|
| .onLoad<- function(libname, pkgname){
|loadRcppModules()
| }
|
| I get a segfault whenever I use a c++ function,
|
| *** caught segfault ***
| address 0x0, cause 'memory not mapped'
|
| Traceback:
| 1: .External(list(name = "InternalFunction_invoke", address =
|, dll = list(name = "Rcpp", path =
|
"/Library/Frameworks/R.framework/Versions/2.13/Resources/library/Rcpp/libs/x86_64/Rcpp.so",
| dynamicLookup = TRUE, handle =,
| info =), numParameters = -1L),, ...)
| 2: circular_dichroism_spectrum(clust, gold, n = 1.33, N = 36, progress =
FALSE)
| 3: onecluster()
|
| Is there another step I'm missing?
My first instinct is to check the unitTest, so look at what is different in
test run from
inst/unitTests/runit.Module.client.package.R
using
inst/unitTests/testRcppModule/
That should still work on your platform and you should be able to go from there.
Dirk
--
Gauss once played himself in a zero-sum game and won $50.
-- #11 at http://www.gaussfacts.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
--
Romain Francois
Professional R Enthusiast
+33(0) 6 28 91 30 30
http://romainfrancois.blog.free.fr
http://romain-francois.com
|- http://bit.ly/hdKhCy : Rcpp article in JSS
|- http://bit.ly/elZJRJ : Montpellier Comedie Club - Avril 2011
`- http://bit.ly/fhqbRC : Rcpp workshop in Chicago on April 28th
___
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
Re: [Rcpp-devel] Error: .onLoad failed in loadNamespace()
Le 28/05/11 04:04, Dirk Eddelbuettel a écrit : Hi Laurent, On 27 May 2011 at 17:17, Laurent Gatto wrote: | Dear all, | | A basic packages with Rcpp modules produces the warning described | below, that I would ideally, with your help, get rid of. | | Rscript -e "require(Rcpp); Rcpp.package.skeleton(module=FALSE)" | R CMD check anRpackage | | produces obvious warnings related to badly formatted documentation and | license. However | | Rscript -e "require(Rcpp); Rcpp.package.skeleton(module=TRUE)" | R CMD check anRpackage | | produces this additional warning that puzzles me: | | [ ...checker output... ] | * checking whether the name space can be loaded with stated | dependencies ... WARNING | Error: .onLoad failed in loadNamespace() for ‘anRpackage’, details: | call: value[[3L]](cond) | error: failed to load module yada from package anRpackage | Execution halted | | A namespace must be able to be loaded with just the base namespace | loaded: otherwise if the namespace gets loaded by a saved object, the | session will be unable to start. | | Probably some imports need to be declared in the NAMESPACE file. | [ ...checker output...] | | I suspect this may be related to the yada module not being exposed and | thus not available when the package is loaded. Any further explanation | or hints would however be warmly appreciated. I think you are pretty close. As I recall, this 'warning' has been a bit of a wart that won't quite go away. I just checked again what we do in the unit tests in file runit.Module.client.package.R: we build a package (ie create a tar.gz) and then install from it. That also triggers the warning, but passes it. Romain may have more details about how this is related to module initialization and startup. Dirk I'll have a go at installing a fresher R-devel and see what the next move is. My guess is that R checks are tighter now. | | sessionInfo() is appended below. | | Thank you very much in advance. | | Best wishes, | | Laurent | | |> sessionInfo() | R version 2.14.0 Under development (unstable) (2011-05-04 r55760) | Platform: x86_64-unknown-linux-gnu (64-bit) | | locale: | [1] LC_CTYPE=en_GB.utf8 LC_NUMERIC=C | [3] LC_TIME=en_GB.utf8LC_COLLATE=en_GB.utf8 | [5] LC_MONETARY=C LC_MESSAGES=en_GB.utf8 | [7] LC_PAPER=en_GB.utf8 LC_NAME=C | [9] LC_ADDRESS=C LC_TELEPHONE=C | [11] LC_MEASUREMENT=en_GB.utf8 LC_IDENTIFICATION=C | | attached base packages: | [1] stats graphics grDevices utils datasets methods base | | other attached packages: | [1] Rcpp_0.9.4.1 -- Romain Francois Professional R Enthusiast +33(0) 6 28 91 30 30 http://romainfrancois.blog.free.fr http://romain-francois.com |- http://bit.ly/hdKhCy : Rcpp article in JSS |- http://bit.ly/elZJRJ : Montpellier Comedie Club - Avril 2011 `- http://bit.ly/fhqbRC : Rcpp workshop in Chicago on April 28th ___ 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
Re: [Rcpp-devel] package .onLoad multiple modules
Hi,
On 31 May 2011 07:55, Romain Francois wrote:
> Le 30/05/11 01:56, baptiste auguie a écrit :
>>
>> Thanks, that is helpful. I think I have nailed down the problem.
>>
>> I defined a wrapper at R level that used a C++ function from a module
>> named "cd",
>>
>> circular_dichroism_spectrum<- function( ... ){
>>
>> [...] # some argument processing
>>
>> res<- cd$circular_dichroism_spectrum(...) # calling the C++ function
>>
>> return(res)
>> }
>>
>> Now, with loadRcppModules(), no "cd" module is created, as far as I
>> can tell, and invoking circular_dichroism_spectrum() is calling the
>> C++ function directly; a segfault results because some of the
>> arguments differ between the C++ function and its R wrapper.
>>
>> I see two options:
>>
>> - choose a different name for the R and C++ functions
>>
>> - manage some kind of namespace masking the C++ function from the
>> top-level, like cd$ did before. Is there a way to do this in the
>> loadRcppModules() approach?
>
> Not currently. functions and classes are directly exposed in the namespace.
> I guess we could add an argument to control that.
>
> In the meantime, I'd use your first option.
I'd prefer not having to change names, so I'll probably stick to the
old lockBinding() approach for now, if that's not deprecated.
Best,
baptiste
>
>> Best regards,
>>
>> baptiste
>>
>>
>> On 30 May 2011 11:11, Dirk Eddelbuettel wrote:
>>>
>>> On 30 May 2011 at 10:29, baptiste auguie wrote:
>>> | Hi,
>>> |
>>> | On 30 May 2011 04:28, Dirk Eddelbuettel wrote:
>>> |>
>>> |> On 29 May 2011 at 18:56, baptiste auguie wrote:
>>> |> | Dear list,
>>> |> |
>>> |> | [Disclaimer: I am not very familiar with Rcpp/C++, and probably
>>> |> | haven't followed all the relevant discussions on this list.]
>>> |> |
>>> |> | I'm trying to tidy up two packages on r-forge [*] before submitting
>>> |> | them to CRAN. In "cda/zzz.r", I have the following code,
>>> |> |
>>> |> | NAMESPACE<- environment()
>>> |> | cda<- new( "Module" )
>>> |> | cdatests<- new( "Module" )
>>> |> | cd<- new( "Module" )
>>> |> | linear<- new( "Module" )
>>> |> | array<- new( "Module" )
>>> |> |
>>> |> | .onLoad<- function(libname, pkgname){
>>> |> | unlockBinding( "cda" , NAMESPACE )
>>> |> | unlockBinding( "cdatests" , NAMESPACE )
>>> |> | unlockBinding( "cd" , NAMESPACE )
>>> |> | unlockBinding( "linear" , NAMESPACE )
>>> |> | assign( "cda", Module( "cda" ), NAMESPACE )
>>> |> | assign( "cdatests", Module( "cdatests" ), NAMESPACE )
>>> |> | assign( "cd", Module( "cd" ), NAMESPACE )
>>> |> | assign( "linear", Module( "linear" ), NAMESPACE )
>>> |> | lockBinding( "cda", NAMESPACE )
>>> |> | lockBinding( "cdatests", NAMESPACE )
>>> |> | lockBinding( "cd", NAMESPACE )
>>> |> | lockBinding( "linear", NAMESPACE )
>>> |> |
>>> |> | unlockBinding( "array" , NAMESPACE )
>>> |> | assign( "array", Module( "array" ), NAMESPACE )
>>> |> | lockBinding( "array", NAMESPACE )
>>> |> |
>>> |> | }
>>> |> |
>>> |> | It seems to work, but is there something I can/should do to make
>>> this
>>> |> | a wee cleaner?
>>> |>
>>> |> Have another look at the Rcpp-modules vignette, and/or the third set
>>> of
>>> |> slides ("Advanced Rcpp") from our class in April -- you no longer
>>> need the
>>> |> unlockBinding / lockBinding business as Romain internalized that. The
>>> |> skeleton-generated packages now just do this in zzz.R:
>>> |>
>>> |> .onLoad<- function(pkgname, libname){
>>> |> loadRcppModules()
>>> |> }
>>> |>
>>> |> using a 'RcppModules: cda, cdatests, cd, linear, array' declaration
>>> in
>>> |> DESCRIPTION.
>>> |
>>> | Strange, this does not seem to work for me.
>>> |
>>> | If I use the following zzz.r, (with RcppModules listed in DESCRIPTION)
>>> |
>>> | .onLoad<- function(libname, pkgname){
>>> | loadRcppModules()
>>> | }
>>> |
>>> | I get a segfault whenever I use a c++ function,
>>> |
>>> | *** caught segfault ***
>>> | address 0x0, cause 'memory not mapped'
>>> |
>>> | Traceback:
>>> | 1: .External(list(name = "InternalFunction_invoke", address =
>>> |, dll = list(name = "Rcpp", path =
>>> |
>>> "/Library/Frameworks/R.framework/Versions/2.13/Resources/library/Rcpp/libs/x86_64/Rcpp.so",
>>> | dynamicLookup = TRUE, handle =,
>>> | info =), numParameters = -1L),>> | 0x103011050>, ...)
>>> | 2: circular_dichroism_spectrum(clust, gold, n = 1.33, N = 36, progress
>>> = FALSE)
>>> | 3: onecluster()
>>> |
>>> | Is there another step I'm missing?
>>>
>>> My first instinct is to check the unitTest, so look at what is different
>>> in
>>> test run from
>>>
>>> inst/unitTests/runit.Module.client.package.R
>>>
>>> using
>>>
>>> inst/unitTests/testRcppModule/
>>>
>>> That should still work on your platform and you should be able to go from
>>> there.
>>>
>>> Dirk
>>>
>>> --
>>> Gauss once played himself in a zero-sum game and won $50.
>>> -- #11 at http://www.gaussfacts.com
>>>
>> __
Re: [Rcpp-devel] trans() changed in latest RcppArmadillo
I was a bit optimistic yesterday; I have not yet been able to produce a minimal example but it seems trans/strans was not the end of the story in my code. Something else was broken with the change to 0.2.21.Thankfully the end results are very visibly wrong. Best regards, Baptiste On 31 May 2011 07:02, Savitsky, Terrance wrote: > Dr. Sanderson, I've been able to verify that my issue resides in the > inv() function (that I typically apply to small p x p matrices, where p > = 3 - 10). In particular, the new version/algorithm induces numerical > instability. I've not yet tested that the results of the inv() > computation are generally accurate, only that they are not numerically > robust in comparison to 0.2.19. I'm up against a deadline, so I > switched back to 0.2.19, which resolves my problem, for now, but will > provide a reproducible example when finished with my work. > > Terrance > > -Original Message- > From: Conrad Sand [mailto:conradsand.r...@gmail.com] > Sent: Monday, May 30, 2011 6:34 AM > To: rcpp-de...@r-forge.wu-wien.ac.at > Cc: Savitsky, Terrance > Subject: Re: trans() changed in latest RcppArmadillo > > On 30 May 2011, Terrance Savitsky wrote: >> Hello, After upgrading to the 0.2.21 release of RcppArmadillo, my >> previously working code (across many functions) ceased working (on a >> Windows XP installation). I re-installed the previous version > (0.2.20) >> from CRAN (via a server location not yet updated to 0.2.21); didn't > fix it. >> The timing may be a coincidence, though reading the post on >> trans() encourages me to make this post. While I use 'trans' across > my >> functions, it is not applied on complex-valued matrices; only >> real-valued. So the prior post wouldn't explain my issue. > > Hi, I'm the main author of Armadillo. > > I'm interested in hearing about all regressions -- can you provide > more details ? > > There have been a lot of changes between Armadillo 1.2 and the latest > beta (1.99.3). I'd like to shake out all known bugs before releasing > 2.0. > > > Cheers, > Conrad > > -- > Dr Conrad Sanderson : Sr Research Scientist : NICTA : > http://arma.sf.net/cs > > __ > > This email message is for the sole use of the intended recipient(s) and > may contain confidential information. Any unauthorized review, use, > disclosure or distribution is prohibited. If you are not the intended > recipient, please contact the sender by reply email and destroy all copies > of the original message. > > ___ > 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 > ___ 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
Re: [Rcpp-devel] trans() changed in latest RcppArmadillo
After a couple hours switching back and forth between versions, I found a problem with the scalar product of complex vectors. Here is a minimal example, library(inline) require( RcppArmadillo ) ## let's calculate this product c(-1-1i, 1-1i) %*% c(1i, -1i) ## 0-2i ## trans() with v0.2.19 fx <- cxxfunction( signature() , ' arma::cx_colvec A = " (-1,-1)(+1,-1) ;", B = "(+0,1) (+0,-1) ;" ; arma::cx_colvec res = trans(A) * B; return wrap( res ) ; ', plugin = "RcppArmadillo" ) fx() ## 0-2i ## strans() with v0.2.21 fx <- cxxfunction( signature() , ' arma::cx_colvec A = " (-1,-1)(+1,-1) ;", B = "(+0,1) (+0,-1) ;" ; arma::cx_colvec res = strans(A) *B; return wrap( res ) ; ', plugin = "RcppArmadillo" ) fx() ## 1-1i Best regards, baptiste On 31 May 2011 10:01, baptiste auguie wrote: > I was a bit optimistic yesterday; I have not yet been able to produce > a minimal example but it seems trans/strans was not the end of the > story in my code. Something else was broken with the change to > 0.2.21.Thankfully the end results are very visibly wrong. > > Best regards, > > Baptiste > > On 31 May 2011 07:02, Savitsky, Terrance wrote: >> Dr. Sanderson, I've been able to verify that my issue resides in the >> inv() function (that I typically apply to small p x p matrices, where p >> = 3 - 10). In particular, the new version/algorithm induces numerical >> instability. I've not yet tested that the results of the inv() >> computation are generally accurate, only that they are not numerically >> robust in comparison to 0.2.19. I'm up against a deadline, so I >> switched back to 0.2.19, which resolves my problem, for now, but will >> provide a reproducible example when finished with my work. >> >> Terrance >> >> -Original Message- >> From: Conrad Sand [mailto:conradsand.r...@gmail.com] >> Sent: Monday, May 30, 2011 6:34 AM >> To: rcpp-de...@r-forge.wu-wien.ac.at >> Cc: Savitsky, Terrance >> Subject: Re: trans() changed in latest RcppArmadillo >> >> On 30 May 2011, Terrance Savitsky wrote: >>> Hello, After upgrading to the 0.2.21 release of RcppArmadillo, my >>> previously working code (across many functions) ceased working (on a >>> Windows XP installation). I re-installed the previous version >> (0.2.20) >>> from CRAN (via a server location not yet updated to 0.2.21); didn't >> fix it. >>> The timing may be a coincidence, though reading the post on >>> trans() encourages me to make this post. While I use 'trans' across >> my >>> functions, it is not applied on complex-valued matrices; only >>> real-valued. So the prior post wouldn't explain my issue. >> >> Hi, I'm the main author of Armadillo. >> >> I'm interested in hearing about all regressions -- can you provide >> more details ? >> >> There have been a lot of changes between Armadillo 1.2 and the latest >> beta (1.99.3). I'd like to shake out all known bugs before releasing >> 2.0. >> >> >> Cheers, >> Conrad >> >> -- >> Dr Conrad Sanderson : Sr Research Scientist : NICTA : >> http://arma.sf.net/cs >> >> __ >> >> This email message is for the sole use of the intended recipient(s) and >> may contain confidential information. Any unauthorized review, use, >> disclosure or distribution is prohibited. If you are not the intended >> recipient, please contact the sender by reply email and destroy all copies >> of the original message. >> >> ___ >> 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 >> > ___ 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
Re: [Rcpp-devel] trans() changed in latest RcppArmadillo
Sorry, I had too many spaces in the vectors. The conclusion is the same though. library(inline) require( RcppArmadillo ) ## let's calculate this product c(-1-1i, 1-1i) %*% c(1i, -1i) ## 0-2i ## trans() with v0.2.19 fx <- cxxfunction( signature() , ' arma::cx_colvec A = "(-1,-1) (+1,-1);", B = "(+0,1) (+0,-1);" ; arma::cx_colvec res = trans(A) * B; return wrap( res ) ; ', plugin = "RcppArmadillo" ) fx() ## 0-2i ## strans() with v0.2.21 fx <- cxxfunction( signature() , ' arma::cx_colvec A = "(-1,-1) (+1,-1);", B = "(+0,1) (+0,-1);" ; arma::cx_colvec res = strans(A) * B; return wrap( res ) ; ', plugin = "RcppArmadillo" ) fx() ## 1-1i On 31 May 2011 11:42, baptiste auguie wrote: > After a couple hours switching back and forth between versions, I > found a problem with the scalar product of complex vectors. Here is a > minimal example, > > library(inline) > require( RcppArmadillo ) > > ## let's calculate this product > c(-1-1i, 1-1i) %*% c(1i, -1i) > ## 0-2i > > ## trans() with v0.2.19 > fx <- cxxfunction( signature() , ' > arma::cx_colvec A = " (-1,-1) (+1,-1) ;", B = "(+0,1) (+0,-1) ;" ; > arma::cx_colvec res = trans(A) * B; > > return wrap( res ) ; > ', plugin = "RcppArmadillo" ) > > fx() > ## 0-2i > > ## strans() with v0.2.21 > fx <- cxxfunction( signature() , ' > arma::cx_colvec A = " (-1,-1) (+1,-1) ;", B = "(+0,1) (+0,-1) ;" ; > arma::cx_colvec res = strans(A) *B; > > return wrap( res ) ; > ', plugin = "RcppArmadillo" ) > > fx() > ## 1-1i > > Best regards, > > baptiste > > > > On 31 May 2011 10:01, baptiste auguie wrote: >> I was a bit optimistic yesterday; I have not yet been able to produce >> a minimal example but it seems trans/strans was not the end of the >> story in my code. Something else was broken with the change to >> 0.2.21.Thankfully the end results are very visibly wrong. >> >> Best regards, >> >> Baptiste >> >> On 31 May 2011 07:02, Savitsky, Terrance wrote: >>> Dr. Sanderson, I've been able to verify that my issue resides in the >>> inv() function (that I typically apply to small p x p matrices, where p >>> = 3 - 10). In particular, the new version/algorithm induces numerical >>> instability. I've not yet tested that the results of the inv() >>> computation are generally accurate, only that they are not numerically >>> robust in comparison to 0.2.19. I'm up against a deadline, so I >>> switched back to 0.2.19, which resolves my problem, for now, but will >>> provide a reproducible example when finished with my work. >>> >>> Terrance >>> >>> -Original Message- >>> From: Conrad Sand [mailto:conradsand.r...@gmail.com] >>> Sent: Monday, May 30, 2011 6:34 AM >>> To: rcpp-de...@r-forge.wu-wien.ac.at >>> Cc: Savitsky, Terrance >>> Subject: Re: trans() changed in latest RcppArmadillo >>> >>> On 30 May 2011, Terrance Savitsky wrote: Hello, After upgrading to the 0.2.21 release of RcppArmadillo, my previously working code (across many functions) ceased working (on a Windows XP installation). I re-installed the previous version >>> (0.2.20) from CRAN (via a server location not yet updated to 0.2.21); didn't >>> fix it. The timing may be a coincidence, though reading the post on trans() encourages me to make this post. While I use 'trans' across >>> my functions, it is not applied on complex-valued matrices; only real-valued. So the prior post wouldn't explain my issue. >>> >>> Hi, I'm the main author of Armadillo. >>> >>> I'm interested in hearing about all regressions -- can you provide >>> more details ? >>> >>> There have been a lot of changes between Armadillo 1.2 and the latest >>> beta (1.99.3). I'd like to shake out all known bugs before releasing >>> 2.0. >>> >>> >>> Cheers, >>> Conrad >>> >>> -- >>> Dr Conrad Sanderson : Sr Research Scientist : NICTA : >>> http://arma.sf.net/cs >>> >>> __ >>> >>> This email message is for the sole use of the intended recipient(s) and >>> may contain confidential information. Any unauthorized review, use, >>> disclosure or distribution is prohibited. If you are not the intended >>> recipient, please contact the sender by reply email and destroy all copies >>> of the original message. >>> >>> ___ >>> 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 >>> >> > ___ 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
Re: [Rcpp-devel] trans() changed in latest RcppArmadillo
On 31 May 2011 05:02, Savitsky, Terrance wrote: > Dr. Sanderson, I've been able to verify that my issue resides in the > inv() function (that I typically apply to small p x p matrices, where p > = 3 - 10). In particular, the new version/algorithm induces numerical > instability. This is a bit strange, as the underlying algorithm for inv() hasn't changed. For matrix sizes <= 4x4, a fast version is used (and has been since the early days of Armadillo). For sizes >= 5x5, Lapack is used. Can you provide an example matrix which provides different results with the new Armadillo ? btw, in the new Armadillo the solve() function now calls inv() for matrix sizes <= 4x4. Otherwise it uses Lapack. > I've not yet tested that the results of the inv() computation are > generally accurate, only that they are not numerically robust > in comparison to 0.2.19. I'm up against a deadline, so I switched > back to 0.2.19, which resolves my problem, for now, but will provide > a reproducible example when finished with my work. That would be great -- as the issue affects you, it's likely to affect other people. Cheers, Conrad -- Dr Conrad Sanderson : Sr Research Scientist : NICTA : http://arma.sf.net/cs ___ 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
Re: [Rcpp-devel] trans() changed in latest RcppArmadillo
Hi Baptiste, Thanks for the bug report. I'll take a look at the underlying issues. On 31 May 2011 09:48, baptiste auguie wrote: > Sorry, I had too many spaces in the vectors. The conclusion is the same > though. > > library(inline) > require( RcppArmadillo ) > > ## let's calculate this product > c(-1-1i, 1-1i) %*% c(1i, -1i) > ## 0-2i > > ## trans() with v0.2.19 > fx <- cxxfunction( signature() , ' > arma::cx_colvec A = "(-1,-1) (+1,-1);", B = "(+0,1) (+0,-1);" ; > arma::cx_colvec res = trans(A) * B; > > return wrap( res ) ; > ', plugin = "RcppArmadillo" ) > > fx() > ## 0-2i > > ## strans() with v0.2.21 > fx <- cxxfunction( signature() , ' > arma::cx_colvec A = "(-1,-1) (+1,-1);", B = "(+0,1) (+0,-1);" ; > arma::cx_colvec res = strans(A) * B; > return wrap( res ) ; > ', plugin = "RcppArmadillo" ) > > fx() > ## 1-1i ___ 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
