Højsgaard
|Cc: rcpp-devel@lists.r-forge.r-project.org
|Subject: Re: [Rcpp-devel] sugar: x+y and y+x gives different results when
|there are NA's in y
|
|You get UB if the first is bigger than the second.
|
|Envoyé de mon iPhone
|
|> Le 22 nov. 2014 à 14:30, Søren Højsgaard a écrit :
|>
|&
omain Francois [mailto:rom...@r-enthusiasts.com]
> |Sent: 22. november 2014 13:25
> |To: Søren Højsgaard
> |Cc: rcpp-devel@lists.r-forge.r-project.org
> |Subject: Re: [Rcpp-devel] sugar: x+y and y+x gives different results when
> |there are NA's in y
> |
> |This has nothing to do with N
OK; thanks! Shall I read this such as "the behaviour is undefined"?
Søren
|-Original Message-
|From: Romain Francois [mailto:rom...@r-enthusiasts.com]
|Sent: 22. november 2014 13:25
|To: Søren Højsgaard
|Cc: rcpp-devel@lists.r-forge.r-project.org
|Subject: Re: [Rcpp-devel] suga
This has nothing to do with NA. It's just about the size difference. sugar does
not make attempt at recycling. Your responsibility.
Romain
> Le 22 nov. 2014 à 11:48, Søren Højsgaard a écrit :
>
> Dear all,
> Came across this:
>
> #include
> using namespace Rcpp;
>
> //[[Rcpp::export]]
> Li
Dear all,
Came across this:
#include
using namespace Rcpp;
//[[Rcpp::export]]
List sumxy(NumericVector x, NumericVector y){
NumericVector xy = x+y;
NumericVector yx = y+x;
return List::create(xy, yx);
}
/*** R
x <- c(1,3,5,7)
y <- c(NA,2,4,6,8)
x+y
y+x
sumxy(x, y)
*/
> x <- c(1,3,5,7)
On Tue, Jan 25, 2011 at 3:23 AM, Romain Francois
wrote:
> I'll have a look at this when I get a chance.
Obviously my proposed "partial fix" is really not satisfactory because it would
involve a lot of vector copying, defeating the purpose of expression templates.
The real issue is that the way R
I'll have a look at this when I get a chance.
Romain
Le 25/01/11 02:58, Dominick Samperi a écrit :
I reported a problem in another thread that I thought only surfaced
under Windows,
but I was wrong (see Subject line). The problem also appears under GCC 4.5+,
and it appears that somebody already
I reported a problem in another thread that I thought only surfaced
under Windows,
but I was wrong (see Subject line). The problem also appears under GCC 4.5+,
and it appears that somebody already noticed problems with this version of GCC
and introduced the compiler define IS_GCC_450_OR_LATER to na
This link explains very clearly why VC++ creates a temporary to initialize
the local reference, complete with a decision graph, and it seems that
the Rcpp expression template code should lead to the "create temporary"
branch: http://msdn.microsoft.com/en-us/library/szywdw8k.aspx
These comments com
Opps, I was too quick to declare victory here. That warning about
temporary reference initialization is not innocuous: crashes still
occur under VC++ (even with the updated RcppCommon.h) but
it is difficult to predict when they will occur. The Extractor.h
work-around fixes the problem for now.
The
To finish up this thread, it turns out that the VC++ problems did
help to reveal an architecture-dependent behavior of Rprintf
(under GCC) that
developers probably should be aware of, and it also points to
a potential problem with the way temporary references are
initialized in the expression templ
It appears that this is a matter of compiler interpretation of the C++
standards,
and it is not easy to see which compiler is correct (g++ or VC++).
When I disable the VC++ work-around I get the following warning from this
compiler about the Plus_Vector_Vector constructor:
c:\w\dev\stats\rbuild\R
Romain,
I found a work-around for the VC++ problem. All I have to do
is make sure the code that is currently ifdef-ed in Extractor.h
is NOT enabled under VC++ (when _MSC_VER is defined).
Currently this code is conditionally compiled with
#ifndef IF_GCC_450_OR_LATER, so the additional condition
tha
So that there is no confusion, I should add that the problems that I report
here do not occur under Linux/g++ or under MinGW/g++ (the supported
environments), where Rcpp/sugar seems to work fine.
On Sat, Jan 15, 2011 at 1:23 PM, Dominick Samperi wrote:
>
>
> On Sat, Jan 15, 2011 at 4:15 AM, Romai
On Sat, Jan 15, 2011 at 4:15 AM, Romain Francois
wrote:
> Le 13/01/11 16:29, Dominick Samperi a écrit :
>
> The template expression code is very interesting, but it
>> does not work as expected under
>> Windows/g++/MinGW/32bit/Rterm.exe. The problem
>> does not appear when I use Rgui.exe, or if I
Le 13/01/11 16:29, Dominick Samperi a écrit :
The template expression code is very interesting, but it
does not work as expected under
Windows/g++/MinGW/32bit/Rterm.exe. The problem
does not appear when I use Rgui.exe, or if I use
64bit Windows!
Consider the following C++ code called using
.Call
The template expression code is very interesting, but it
does not work as expected under
Windows/g++/MinGW/32bit/Rterm.exe. The problem
does not appear when I use Rgui.exe, or if I use
64bit Windows!
Consider the following C++ code called using
.Call('testsugar',1:5,1:5):
RcppExport SEXP testsuga
On 7 January 2011 at 12:54, Romain Francois wrote:
| Le 05/01/11 14:01, Dirk Eddelbuettel a écrit :
| >
| > On 5 January 2011 at 10:55, Cedric Ginestet wrote:
| > | Dear All,
| > |
| > | Here are some simulations that I have run this morning. Romain's
suggestion to
| > | compute xV.size() before
Le 05/01/11 14:01, Dirk Eddelbuettel a écrit :
On 5 January 2011 at 10:55, Cedric Ginestet wrote:
| Dear All,
|
| Here are some simulations that I have run this morning. Romain's suggestion to
| compute xV.size() before the loop and Douglas' idea of using accumulate appear
| to work best. Howeve
On 5 January 2011 at 10:55, Cedric Ginestet wrote:
| Dear All,
|
| Here are some simulations that I have run this morning. Romain's suggestion to
| compute xV.size() before the loop and Douglas' idea of using accumulate appear
| to work best. However, both are substantially slower than the r-base
Dear All,
Here are some simulations that I have run this morning. Romain's
suggestion to compute xV.size() before the loop and Douglas' idea of
using accumulate appear to work best. However, both are substantially
slower than the r-base function.
I have also included two more versions: (i) o
Le 04/01/11 19:09, Douglas Bates a écrit :
On Tue, Jan 4, 2011 at 12:04 PM, Douglas Bates wrote:
On Tue, Jan 4, 2011 at 11:13 AM, Romain Francois
wrote:
Le 04/01/11 17:42, Romain Francois a écrit :
Le 04/01/11 16:35, Andrew Redd a écrit :
Cedric,
This was addressed about 2 weeks ago on t
On Tue, Jan 4, 2011 at 12:04 PM, Douglas Bates wrote:
> On Tue, Jan 4, 2011 at 11:13 AM, Romain Francois
> wrote:
>> Le 04/01/11 17:42, Romain Francois a écrit :
>>>
>>> Le 04/01/11 16:35, Andrew Redd a écrit :
Cedric,
This was addressed about 2 weeks ago on the list, please read t
On Tue, Jan 4, 2011 at 11:13 AM, Romain Francois
wrote:
> Le 04/01/11 17:42, Romain Francois a écrit :
>>
>> Le 04/01/11 16:35, Andrew Redd a écrit :
>>>
>>> Cedric,
>>> This was addressed about 2 weeks ago on the list, please read the
>>> archives. Basic point, Rcpp/sugar will not be faster than
Le 04/01/11 17:42, Romain Francois a écrit :
Le 04/01/11 16:35, Andrew Redd a écrit :
Cedric,
This was addressed about 2 weeks ago on the list, please read the
archives. Basic point, Rcpp/sugar will not be faster than basic
functions in R. Do something more complicated to see improvements. I
wou
Le 04/01/11 16:35, Andrew Redd a écrit :
Cedric,
This was addressed about 2 weeks ago on the list, please read the
archives. Basic point, Rcpp/sugar will not be faster than basic
functions in R. Do something more complicated to see improvements. I
would suggest something that involves lots of
On 4 January 2011 at 15:14, Cedric Ginestet wrote:
| Happy new year to everyone,
|
| I have made a very straightforward comparison of the performance of standard
R,
| Rcpp function and sugar, and found that the latter produces the poorest
| performance. Let me know what you think and how I could
Cedric,
This was addressed about 2 weeks ago on the list, please read the archives.
Basic point, Rcpp/sugar will not be faster than basic functions in R. Do
something more complicated to see improvements. I would suggest something
that involves lots of copies and edits, that will mess with R's m
Happy new year to everyone,
I have made a very straightforward comparison of the performance of
standard R, Rcpp function and sugar, and found that the latter produces
the poorest performance. Let me know what you think and how I could
improve such performance assessment.
###
On Wed, Dec 22, 2010 at 5:33 AM, wrote:
> Hello,
>
> Following Gabor's thread yesterday, I looked into R source code and figure
> that we don't need to test for NA when using numeric vector. See this:
>
> require(inline)
> require(Rcpp)
>
> pl <- cxxfunction( , '
> return List::create(
>
Le mer 22/12/10 13:02, "Gabor Grothendieck" ggrothendi...@gmail.com a écrit:
> On Wed, Dec 22, 2010 at 6:33 AM, i...@r-enthusiasts.com> wrote:
> Also, I'm trying to write the looping internally in
> order to get a better comparison. With the attached file, I
> get:
> The attachment does not see
On Wed, Dec 22, 2010 at 6:33 AM, wrote:
> Also, I'm trying to write the looping internally in order to get a better
> comparison. With the attached file, I get:
The attachment does not seem to have made it through.
--
Statistics & Software Consulting
GKX Group, GKX Associates Inc.
tel: 1-877-
Hello,
Following Gabor's thread yesterday, I looked into R source code and figure that
we don't need to test for NA when using numeric vector. See this:
require(inline)
require(Rcpp)
pl <- cxxfunction( , '
return List::create(
NA_REAL + NA_REAL,
NA_REAL + 1.0,
1
Perfect. You were correct. It was just to do with my compiler. It worked.
For future reference, my compiler's version is:
gcc 4.4.3
Cheers,
Cedric
On 22/12/10 10:49, rom...@r-enthusiasts.com wrote:
Hmm. It works for me :
romain@ /tmp $ Rscript scalar.R
Le chargement a nécessité le package : Rc
Hmm. It works for me :
romain@ /tmp $ Rscript scalar.R
Le chargement a nécessité le package : Rcpp
Le chargement a nécessité le package : methods
Le chargement a nécessité le package : inline
[1] 0.118499288 -1.817607621 -0.222048483 -1.237370127 -0.311005542
[6] -1.171129611 -1.762177277
Dear Rcpp experts,
I've got another problem related to Rcpp Sugar. Basically, I would
like to have the same functionality that you get from R's vectors,
where binary operations with scalars are automatically interpreted as
elementwise operations. See the following code and error message:
###
el-boun...@lists.r-forge.r-project.org] on behalf of Romain Francois
[rom...@r-enthusiasts.com]
Sent: 13 December 2010 10:07
To: rcpp-devel@lists.r-forge.r-project.org
Subject: Re: [Rcpp-devel] Sugar/inline and RTools
Hello,
Le 12/12/10 16:28, Dirk Eddelbuettel a écrit :
Hi Chris,
On 12 December 20
I could get around openmp support lacking in rtools, I guess there will
always be the potential to come across
other similar issues..given the "min" distribution.
Thanks for all suggestions/comments. chris.
From: rcpp-devel-boun...@lists.r-forge.r-project.org
[rcpp-devel-boun...@lists.r-f
Hello,
Le 12/12/10 16:28, Dirk Eddelbuettel a écrit :
Hi Chris,
On 12 December 2010 at 15:03, Wray, Christopher wrote:
| Hi,
| Im using windows7, R2.12, Rtools2.12 and all the latest packages of inline,
| rcpp, etc. Over the last few weeks I have managed to get loads of the
| examples working,
Hi Chris,
On 12 December 2010 at 15:03, Wray, Christopher wrote:
| Hi,
| Im using windows7, R2.12, Rtools2.12 and all the latest packages of inline,
| rcpp, etc. Over the last few weeks I have managed to get loads of the
| examples working, and all makes sense and is pretty clear. I had a couple
Hi,
Im using windows7, R2.12, Rtools2.12 and all the latest packages of inline,
rcpp, etc. Over the last few weeks I have managed to get loads of the examples
working, and all makes sense and is pretty clear. I had a couple of
questions/comments:
1. RTools: On windows, I understand that Rcpp an
Le 01/11/10 16:00, Andrew Redd a écrit :
Doesn't sugar require Rcpp vectors, which encapsulate R SEXP vectors?
If that is the case you really cannot separate them at all since there
is a direct dependency on R.
-Andrew
It is more like both Rcpp vectors and sugar functions both depend on the
Le 01/11/10 15:57, Shane Conway a écrit :
My two cents:
That seems sensible; an alternative view would be to say that sugar is
in the same vein as the rest of Rcpp, might regularly be used in the
same code, and the goal should be to keep everything as simple as
possible (i.e. one library). I, f
Doesn't sugar require Rcpp vectors, which encapsulate R SEXP vectors? If
that is the case you really cannot separate them at all since there is a
direct dependency on R.
-Andrew
On Mon, Nov 1, 2010 at 7:57 AM, Shane Conway wrote:
> My two cents:
>
> That seems sensible; an alternative view wou
Le 01/11/10 06:13, Dominick Samperi a écrit :
Comments on Sugar...
Rcpp sugar seems to be an enhancement for C++ more than an interface
function,
so wouldn't it make sense to maintain it as a separate C++ class library?
not to me. sugar brings (parts of the) R syntax at the C++ level, it
seem
My two cents:
That seems sensible; an alternative view would be to say that sugar is
in the same vein as the rest of Rcpp, might regularly be used in the
same code, and the goal should be to keep everything as simple as
possible (i.e. one library). I, for one, don't see the need to
separate them.
Comments on Sugar...
Rcpp sugar seems to be an enhancement for C++ more than an interface
function,
so wouldn't it make sense to maintain it as a separate C++ class library?
More generally, it would be useful to know what portions of Rcpp can
function without the R engine running. This can be dete
On 8 July 2010 at 14:06, Romain Francois wrote:
| Hello,
|
| Now that we have extended sugar so that it can deal with matrices, e.g :
|
| signature( x = "numeric", y = "numeric" ),
| '
| NumericVector xx(x) ;
|
Hello,
Now that we have extended sugar so that it can deal with matrices, e.g :
signature( x = "numeric", y = "numeric" ),
'
NumericVector xx(x) ;
NumericVector yy(y);
Hi,
I've implemented lazy versions of them in Rcpp::sugar.
Here are some examples:
fx <- cxxfunction( signature( x = "integer" ), '
IntegerVector xx(x) ;
List res = lapply( xx, seq_len );
return res ;
', plugin = "Rcpp" )
checkEquals( fx( 1:10 ), lapply( 1:10, seq_le
50 matches
Mail list logo
