particular GCC release (GCC 4.3.6) and GNU is not going to release any newer version of GCC 4.3 or earlier series. However I provided a two line patch attached in the email. The compiler being affected is that particular GCC 4.3.6.Best,Yan Zhou--- /home/zhou/R/x86_64-pc-linux-gnu-library/3.1/Rcpp/include
type and the
input argument is the *this, which is not converted.
Best,
Yan Zhou
On Feb 20, 2013, at 2:11 AM, Dirk Eddelbuettel wrote:
>
> On 20 February 2013 at 01:48, Yan Zhou wrote:
> |
> | On Feb 20, 2013, at 1:46 AM, Dirk Eddelbuettel wrote:
> |
> | >
> | >
On Feb 20, 2013, at 1:46 AM, Dirk Eddelbuettel wrote:
>
> On 20 February 2013 at 01:15, Yan Zhou wrote:
> | Hi Dirk,
>
> I see nothing Rcpp-specific here. It's more about how to avoid ambiguity
> within C++. Might make a good question for the C++ tag on StackOver
Hi Dirk,
It is actually a problem with Rcpp, though unrelated to Ken's original question
anymore, below is an example reproduce the problem.
#include
class Wrapper
{
public :
Wrapper (double x) : x_(x) {}
template operator T () const {return x_;}
operator int () const {retur
The most inefficient part I see is the creation of a new NumericVector inside
the inner most loop. You copied each column n times, of which n-1 times are
unnecessary.
Yan Zhou
On Feb 19, 2013, at 11:02 PM, Dirk Eddelbuettel wrote:
>
> Ken,
>
> On 19 February 2013 at 22:35,
just increase the seed in every iteration dependent on the iteration and the number of random numbers to generate. > > Best Simon > > > > > On Feb 11, 2013, at 2:16 PM, Chris Jefferson <ch...@bubblescope.net> wrote: > >> On 11/02/13 10:23, c s wrote: >
It seems to me that XPtr is like an ownership pointer. It is much like unique_ptr. What you need here is a non-owning reference pointer, like weak_ptr.Have you triedXPtr A::getPtr(){ return(XPtr(this, false));}With the optional argument, a finalizer is not set and the gc will not delete the C++ o
I don't think it is that simple. Boost.Random depends on a lot of things. Pull
in Boost.Random means pull in Boost.TypeTraits, Boost.MPL and a lot of other
things. There is tool for extract part of Boost, BCP. I tried to incorporate
Boost.Random into my own library once. But the truth is that pu
ndom header?Best SimonOn Feb 9, 2013, at 5:42 PM, Yan Zhou <zhou...@me.com> wrote: This really is a BIG topic and worth a few more comments. Note that I wrote a few related posts on RNGs at the Rcpp Gallery, see for example http://gallery.rcpp.org/articles/timing-normal-rngs/ which compares the
xactly the same programming environment
Yan Zhou
On Feb 10, 2013, at 8:50 AM, Simon Zehnder wrote:
> Dear Yan, dear Dirk,
>
> thank you for these very precise answers! I think at the beginning I'll fall
> back to the R RNG. I will test if it is faster to create an Armadillo
&
This really is a BIG topic and worth a few more comments. Note that I wrote a few related posts on RNGs at the Rcpp Gallery, see for example http://gallery.rcpp.org/articles/timing-normal-rngs/ which compares the RNGs from R, C++11 and Boost. Simon just added Armadillo to the list, we can add ev
s RNG, which I believe by default
is Mersenne Twister. See doc of Rcpp sugar. Also you can access Rmath directly.
To have Armadillo randn use MT19937 is not easy. Since it use srand() for seed,
I guess it also use C rand(), whose quality is quite questionable.
Best
Yan Zhou
On Feb 9, 2013, at
This morning I was frustrated by a compilation error, below is a scratch of the problem// MyClass1.htemplate class MyClass {/*...*/};#include namespace Rcpp {template inline SEXP wrap(const MyClass1 &object) {/* ... */}}#include //...// MyClass2.h Similar to MyClass1.h// some.cpp#include "MyClass1
been there so long that I totally forget that)Sorry for all the noise on the list.Best,Yan ZhouOn Feb 04, 2013, at 07:33 PM, Yan Zhou wrote:Hi Dirk,Many thanks for the reply.Actually it turned out it is a problem that OpenMP assumes full control of the master thread (It appears I was not the only
06:37 PM, Dirk Eddelbuettel wrote: On 4 February 2013 at 17:47, Yan Zhou wrote: | I have a C++ library for parallel implementation of Sequential Monte Carlo | algorithms. It can use some different programming models, OpenMP, Intel TBB, | Intel Cilk, C++11 , and others. Everything worked fine so far.
Please ignore my last message. The problem has been solved (a stupid bug as always).Best,YanOn Feb 04, 2013, at 05:47 PM, Yan Zhou wrote:Hi all, My problem is not strictly related to Rcpp. However I hope someone with expertise in both C++ and R can help.I have a C++ library for parallel
Hi all, My problem is not strictly related to Rcpp. However I hope someone with expertise in both C++ and R can help.I have a C++ library for parallel implementation of Sequential Monte Carlo algorithms. It can use some different programming models, OpenMP, Intel TBB, Intel Cilk, C++11 , and others
> >> Hi Yan, >> >> do you know if one can also write a C++ objective function in NLOpt, that works with Armadillo Objects? >> >> Best >> >> Simon >> >> On Feb 3, 2013, at 12:50 PM, Yan Zhou <zhou...@me.com> wrote: >> &g
Opt, that
> works with Armadillo Objects?
>
> Best
>
> Simon
>
> On Feb 3, 2013, at 12:50 PM, Yan Zhou wrote:
>
>> I good numerical optimization library I used before is NLOpt, for non-linear
>> optimization. http://ab-initio.mit.edu/wiki/index.php/
I good numerical optimization library I used before is NLOpt, for non-linear
optimization. http://ab-initio.mit.edu/wiki/index.php/NLopt
You can use it just like and C/C++ library in your own code or you can use its
own R interface as an R package.
Best,
Yan
On Feb 3, 2013, at 11:47 AM, Simon
>From your original message you said the error message is the compiler does not
>recognize the headers. Have you tried to also add the -I flag?
Yan
On Jan 21, 2013, at 7:05 AM, Kevin Ushey wrote:
> Hi Won-min,
>
> 1) There shouldn't be a space between -L and the directory containing your
>
On Jan 15, 2013, at 03:38 PM, John Merrill wrote:You're confusing a data frame object with the data.frame coercion function. Data frames themselves are fast to access. The coercion function is not. Ah, I see what you mean.On Tue, Jan 15, 2013 at 7:36 AM, Yan Zhou <zhou...@me.com>
I am curious what usage of data.frame give you the conclusion that it is slow. You must know that data.frame IS a list of variables, which can be vectors (though not always) and can only be faster than a list of lists.Best,YanOn Jan 15, 2013, at 03:20 PM, John Merrill wrote:It appears that DataFra
On Jan 6, 2013, at 2:50 AM, Paul Johnson wrote:
> I received a big pile of Rcpp code from some folks and am using it as
> a way to learn about Armadillo and Rcpp.
>
> From gazing at the code, and guessing about style and usage, I some
> ways to make a program run faster. But it is all by guess
objects that linked libRcpp.a (as you have to built them with icpc). So building R with icpc is perhaps your only choice, not just the easiest way.YanOn Jan 02, 2013, at 07:48 AM, Yan Zhou wrote:The easiest way is to build R yourself with intel icpc. Below is the script I used to build R on Linux with
The easiest way is to build R yourself with intel icpc. Below is the script I used to build R on Linux with intel compilers. I assume you also has intel ifort installed (otherwise you can use gfortran). Intel C++ is not much faster than latest g++ for much optimization. But considering you are usin
the test succeed as long as clock_gettime was declared in the
header.
I think you shall report a bug to relevant R list.
Whether it is wise to having Rcpp link explicitly to librt is for Dirk and
others to decide, considering this should be linked by R if it exists (I guess
it is used for syst
R with profiling, which is the default?)
Anyway, as Dirk said, linking to librt is harmless on Linux nonetheless, so
that is perhaps the easiest 'fix'.
Best,
Yan Zhou
On Dec 24, 2012, at 1:11 PM, Dirk Eddelbuettel wrote:
>
> On 23 December 2012 at 18:31, Martin Morgan wrote:
-lrt is required on Linux. On other platform it will generate an error instead
since librt is Linux specific.
Yan
On Dec 24, 2012, at 10:31 AM, Martin Morgan wrote:
> When trying to install Rcpp 0.10.2 with
>
> $ R --version
> R Under development (unstable) (2012-12-18 r61372) -- "Unsuffered
I am not sure about the R-forge build, but at least the CRAN Mac binaries (R
and packages) are built with toolchains no longer exists in recent Mac OS X
(such as 10.8.2, well there are ways to get them though not from Apple). That
may cause issues I guess.
Best,
Yan
On Dec 21, 2012, at 8:26 A
You really are not reading the list as close as you should be. If you want
advice, then take it when people give it to you or stop asking.
AFAIK, your code does not involve manually allocated memory, all memories are
managed by RAII objects, I don't see where the question of "freeing memory"
co
You cannot expect C++ to magically make your code faster. If speed is of
concern, you need profiling to find the bottleneck instead of blind guessing. I
am not quite sure how to profile an Rcpp R program. Maybe someone else can help.
But my intuition is that your program simply need that much ti
), but sometimes other compilers can help us found some bug. Every
compiler accept some ill formed code, but it is very unlikely that they all
accept the same ill formed code.
Best,
Yan Zhou
On Dec 3, 2012, at 12:46 PM, Romain Francois wrote:
> Le 03/12/12 13:41, Dirk Eddelbuettel a éc
#if CLANG_VERSION >= 3
-// #define IS_CLANG_300_OR_LATER
-// #endif
-// #endif
-
-// This definition was contributed by Yan Zhou
-#ifdef __clang__
-#if !__has_include()
-#undef HAS_TR1
-#undef HAS_TR1_UNORDERED_MAP
+// Check C++0x features
+#if defined(__INTEL_COMPILER)
lar
>
>builds on Windows using the win-builder service
>
> and we probably should also try to build and test many of the 90 packages
> depending on Rcpp.
>
> Could you shoulder some of that testing ? Just doing a compile is nowhere
> close enough, especially for something mo
who are eager to
use C++11, so there is no reason to merge them any time soon unless we
are sure they don't introduce new problems. I have tested the build and
installation under the compilers and platform I mentioned yesterday.Best,Yan Zhou
// -*- mode: C++; c-indent-level: 4; c-basic-offs
You haven't link to BLAS, and thus there are undefined reference to dgemm etcOn Dec 02, 2012, at 01:35 PM, Howard Zail wrote:I am trying to build a package with RcppArmadillo code and using the new attributes-type methodology. When I compile using sourceCpp() the functions compile and work. Howe
s a Monte Carlo simulation and the 90% of
time it was computing some likelihood.
Best,
Yan
On Dec 1, 2012, at 3:23 PM, Dirk Eddelbuettel wrote:
>
> Hi Yan,
>
> Thanks for such a detailed response -- much appreciated. Your patch is in SVN
> now, by the way.
>
> On 1 De
ever
they need them. And if later we find that some compilers version are not
properly tested by the above code, we only need to fix it in RcppCommon.h
without any change to other parts of the library.
Best,
Yan Zhou
>
> Dirk
>
> |
> |
> | Best,
> |
> | Yan Zhou
>
Dear Dirk,
Sorry, in may last email I attached an incorrect diff file. Here is the
corrected one.
RcppCommon.h.diff
Description: Binary data
Best,
Yan Zhou
On Dec 1, 2012, at 12:44 PM, Yan Zhou wrote:
> Dear Dirk,
>
> In addition to my last email which provides a path for cla
C++98 and C++11 modes.
RcppCommon.h.diff
Description: Binary data
Best,
Yan Zhou
On Dec 1, 2012, at 12:12 PM, Yan Zhou wrote:
> Hi Dirk,
>
> Rcpp cannot be compiled with clang++ with libc++, even clang++ provides very
> good standard conforming in both C++98 and C++11 mo
is patch only affects
clang++ with libc++ situation. Using clang++ with libstdc++ the situation will
be exactly the same as before.
At the end of the email is the path, it is also attached as a diff file
Best,
Yan Zhou
RcppCommon.h.diff
Description: Binary data
--- Rcpp/inst/include/RcppCommon.h
On Dec 26, 2011, at 1:11 AM, Dirk Eddelbuettel wrote:
>
> On 26 December 2011 at 00:44, Yan Zhou wrote:
> | I guess many are moving towards llvm-gcc and clang. In fact r itself now
> compiles with clang and passes make check successfully on Lion, Xcode 4.2.
> Also clang is
I guess many are moving towards llvm-gcc and clang. In fact r itself now
compiles with clang and passes make check successfully on Lion, Xcode 4.2. Also
clang is now the default compiler. Llvm-gcc/g++ are going to be dropped in a
not too long time. gcc4.2 has already been dropped in xcode 4.2
44 matches
Mail list logo
