Re: [Rd] C API to get numrow of data frame
The safest way is to check the length of the row.names attribute, e.g.
length(getAttrib(df, R_RowNamesSymbol)).
This protects you from both data.frames with zero columns, as well as
corrupted data.frames containing columns with different lengths, since
by definition the number of rows in a data.frame is defined by its
row.names attribute. However, R will internally un-collapse a
collapsed row.names on this getAttrib call, which is probably
undesired for very large data.frames.
One way of getting around this is calling .row_names_info from R, e.g.
(modulo my errors):
int df_nrows(SEXP s) {
if (!Rf_inherits(s, "data.frame")) Rf_error("expecting a data.frame");
SEXP two = PROTECT(Rf_ScalarInteger(2));
SEXP call = PROTECT( Rf_lang3(
Rf_install(".row_names_info"),
s,
two
) );
SEXP result = PROTECT(Rf_eval(call, R_BaseEnv));
int output = INTEGER(result)[0];
UNPROTECT(3);
return output;
}
More ideally (?), such a function could be added to util.c and
exported by R, e.g. (again, modulo my errors):
int df_nrows(SEXP s) {
if (!inherits(s, "data.frame")) error("expecting a data.frame");
SEXP t = getAttrib0(s, R_RowNamesSymbol);
if (isInteger(t) && INTEGER(t)[0] == NA_INTEGER && LENGTH(t) == 2)
return abs(INTEGER(t)[1]);
else
return LENGTH(t);
}
or even incorporated into the already available 'nrows' function.
Although there is probably someone out there depending on 'nrows'
returning the number of columns for their data.frame...
Cheers,
Kevin
On Mon, Mar 31, 2014 at 6:27 PM, Murray Stokely wrote:
> I didn't look at the names because I believe that would be incorrect
> if the row names were stored internally in the compact form.
>
> See ?.set_row_names (hat tip, Tim Hesterberg who showed me this years ago) :
>
> 'row.names' can be stored internally in compact form.
> '.set_row_names(n)' generates that form for automatic row names of
> length 'n', to be assigned to 'attr(, "row.names")'.
> '.row_names_info' gives information on the internal form of the
> row names for a data frame: for details of what information see
> the argument 'type'.
>
> The function I wrote obviously doesn't work for 0 row or 0 column
> data.frames, you need to check for that.
>
> On Mon, Mar 31, 2014 at 6:12 PM, Gábor Csárdi wrote:
>> I think it is actually better to check the length of the row names. In case
>> the data frame has zero columns. (FIXME, of course.)
>>
>> Gabor
>>
>>
>> On Mon, Mar 31, 2014 at 8:04 PM, Murray Stokely wrote:
>>>
>>> The simplest case would be:
>>>
>>>int num_rows = Rf_length(VECTOR_ELT(dataframe, 0));
>>>int num_columns = Rf_length(dataframe);
>>>
>>> There may be edge cases for which this doesn't work; would need to
>>> look into how the dim primitive is implemented to be sure.
>>>
>>>- Murray
>>>
>>>
>>> On Mon, Mar 31, 2014 at 4:40 PM, Sandip Nandi
>>> wrote:
>>> > Hi ,
>>> >
>>> > Is there any C API to the R API nrow of dataframe ?
>>> >
>>> > x<- data.frame()
>>> > n<- nrow(x)
>>> > print(n)
>>> > 0
>>> >
>>> >
>>> > Example :
>>> > My C function which deals with data frame looks like and I don't to send
>>> > the number of rows of data frame .I want to detect it from the function
>>> > itself, my function take data frame as argument and do some on it. I
>>> > want
>>> > API equivalent to nrow. I tried Rf_nrows,Rf_ncols . No much help.
>>> >
>>> > SEXP writeRR(SEXP dataframe) {
>>> >
>>> > }
>>> >
>>> >
>>> > Any help is very appreciated.
>>> >
>>> > Thanks,
>>> > Sandip
>>> >
>>> > [[alternative HTML version deleted]]
>>> >
>>> > __
>>> > R-devel@r-project.org mailing list
>>> > https://stat.ethz.ch/mailman/listinfo/r-devel
>>>
>>> __
>>> R-devel@r-project.org mailing list
>>> https://stat.ethz.ch/mailman/listinfo/r-devel
>>
>>
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] C API to get numrow of data frame
I didn't look at the names because I believe that would be incorrect
if the row names were stored internally in the compact form.
See ?.set_row_names (hat tip, Tim Hesterberg who showed me this years ago) :
'row.names' can be stored internally in compact form.
'.set_row_names(n)' generates that form for automatic row names of
length 'n', to be assigned to 'attr(, "row.names")'.
'.row_names_info' gives information on the internal form of the
row names for a data frame: for details of what information see
the argument 'type'.
The function I wrote obviously doesn't work for 0 row or 0 column
data.frames, you need to check for that.
On Mon, Mar 31, 2014 at 6:12 PM, Gábor Csárdi wrote:
> I think it is actually better to check the length of the row names. In case
> the data frame has zero columns. (FIXME, of course.)
>
> Gabor
>
>
> On Mon, Mar 31, 2014 at 8:04 PM, Murray Stokely wrote:
>>
>> The simplest case would be:
>>
>>int num_rows = Rf_length(VECTOR_ELT(dataframe, 0));
>>int num_columns = Rf_length(dataframe);
>>
>> There may be edge cases for which this doesn't work; would need to
>> look into how the dim primitive is implemented to be sure.
>>
>>- Murray
>>
>>
>> On Mon, Mar 31, 2014 at 4:40 PM, Sandip Nandi
>> wrote:
>> > Hi ,
>> >
>> > Is there any C API to the R API nrow of dataframe ?
>> >
>> > x<- data.frame()
>> > n<- nrow(x)
>> > print(n)
>> > 0
>> >
>> >
>> > Example :
>> > My C function which deals with data frame looks like and I don't to send
>> > the number of rows of data frame .I want to detect it from the function
>> > itself, my function take data frame as argument and do some on it. I
>> > want
>> > API equivalent to nrow. I tried Rf_nrows,Rf_ncols . No much help.
>> >
>> > SEXP writeRR(SEXP dataframe) {
>> >
>> > }
>> >
>> >
>> > Any help is very appreciated.
>> >
>> > Thanks,
>> > Sandip
>> >
>> > [[alternative HTML version deleted]]
>> >
>> > __
>> > R-devel@r-project.org mailing list
>> > https://stat.ethz.ch/mailman/listinfo/r-devel
>>
>> __
>> R-devel@r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-devel
>
>
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] C API to get numrow of data frame
The Rf_length(dataframe) will provide the length of row names . So it
should be checked first. I found one edge case now
My dataframe has 0 rows and 0 columns
int num_rows = Rf_length(VECTOR_ELT(dataframe, 0)); > returns 1
,in stead of 0 . Not sure why.
Thanks
On Mon, Mar 31, 2014 at 6:12 PM, Gábor Csárdi wrote:
> I think it is actually better to check the length of the row names. In
> case the data frame has zero columns. (FIXME, of course.)
>
> Gabor
>
>
> On Mon, Mar 31, 2014 at 8:04 PM, Murray Stokely wrote:
>
>> The simplest case would be:
>>
>>int num_rows = Rf_length(VECTOR_ELT(dataframe, 0));
>>int num_columns = Rf_length(dataframe);
>>
>> There may be edge cases for which this doesn't work; would need to
>> look into how the dim primitive is implemented to be sure.
>>
>>- Murray
>>
>>
>> On Mon, Mar 31, 2014 at 4:40 PM, Sandip Nandi
>> wrote:
>> > Hi ,
>> >
>> > Is there any C API to the R API nrow of dataframe ?
>> >
>> > x<- data.frame()
>> > n<- nrow(x)
>> > print(n)
>> > 0
>> >
>> >
>> > Example :
>> > My C function which deals with data frame looks like and I don't to send
>> > the number of rows of data frame .I want to detect it from the function
>> > itself, my function take data frame as argument and do some on it. I
>> want
>> > API equivalent to nrow. I tried Rf_nrows,Rf_ncols . No much help.
>> >
>> > SEXP writeRR(SEXP dataframe) {
>> >
>> > }
>> >
>> >
>> > Any help is very appreciated.
>> >
>> > Thanks,
>> > Sandip
>> >
>> > [[alternative HTML version deleted]]
>> >
>> > __
>> > R-devel@r-project.org mailing list
>> > https://stat.ethz.ch/mailman/listinfo/r-devel
>>
>> __
>> R-devel@r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-devel
>>
>
>
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] C API to get numrow of data frame
I think it is actually better to check the length of the row names. In case
the data frame has zero columns. (FIXME, of course.)
Gabor
On Mon, Mar 31, 2014 at 8:04 PM, Murray Stokely wrote:
> The simplest case would be:
>
>int num_rows = Rf_length(VECTOR_ELT(dataframe, 0));
>int num_columns = Rf_length(dataframe);
>
> There may be edge cases for which this doesn't work; would need to
> look into how the dim primitive is implemented to be sure.
>
>- Murray
>
>
> On Mon, Mar 31, 2014 at 4:40 PM, Sandip Nandi
> wrote:
> > Hi ,
> >
> > Is there any C API to the R API nrow of dataframe ?
> >
> > x<- data.frame()
> > n<- nrow(x)
> > print(n)
> > 0
> >
> >
> > Example :
> > My C function which deals with data frame looks like and I don't to send
> > the number of rows of data frame .I want to detect it from the function
> > itself, my function take data frame as argument and do some on it. I want
> > API equivalent to nrow. I tried Rf_nrows,Rf_ncols . No much help.
> >
> > SEXP writeRR(SEXP dataframe) {
> >
> > }
> >
> >
> > Any help is very appreciated.
> >
> > Thanks,
> > Sandip
> >
> > [[alternative HTML version deleted]]
> >
> > __
> > R-devel@r-project.org mailing list
> > https://stat.ethz.ch/mailman/listinfo/r-devel
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] C API to get numrow of data frame
Hi Murray,
Thanks a lot . For things to work Its good enough . Its working
Thanks,
Sandip
On Mon, Mar 31, 2014 at 5:04 PM, Murray Stokely wrote:
> The simplest case would be:
>
>int num_rows = Rf_length(VECTOR_ELT(dataframe, 0));
>int num_columns = Rf_length(dataframe);
>
> There may be edge cases for which this doesn't work; would need to
> look into how the dim primitive is implemented to be sure.
>
>- Murray
>
>
> On Mon, Mar 31, 2014 at 4:40 PM, Sandip Nandi
> wrote:
> > Hi ,
> >
> > Is there any C API to the R API nrow of dataframe ?
> >
> > x<- data.frame()
> > n<- nrow(x)
> > print(n)
> > 0
> >
> >
> > Example :
> > My C function which deals with data frame looks like and I don't to send
> > the number of rows of data frame .I want to detect it from the function
> > itself, my function take data frame as argument and do some on it. I want
> > API equivalent to nrow. I tried Rf_nrows,Rf_ncols . No much help.
> >
> > SEXP writeRR(SEXP dataframe) {
> >
> > }
> >
> >
> > Any help is very appreciated.
> >
> > Thanks,
> > Sandip
> >
> > [[alternative HTML version deleted]]
> >
> > __
> > R-devel@r-project.org mailing list
> > https://stat.ethz.ch/mailman/listinfo/r-devel
>
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] C API to get numrow of data frame
The simplest case would be:
int num_rows = Rf_length(VECTOR_ELT(dataframe, 0));
int num_columns = Rf_length(dataframe);
There may be edge cases for which this doesn't work; would need to
look into how the dim primitive is implemented to be sure.
- Murray
On Mon, Mar 31, 2014 at 4:40 PM, Sandip Nandi wrote:
> Hi ,
>
> Is there any C API to the R API nrow of dataframe ?
>
> x<- data.frame()
> n<- nrow(x)
> print(n)
> 0
>
>
> Example :
> My C function which deals with data frame looks like and I don't to send
> the number of rows of data frame .I want to detect it from the function
> itself, my function take data frame as argument and do some on it. I want
> API equivalent to nrow. I tried Rf_nrows,Rf_ncols . No much help.
>
> SEXP writeRR(SEXP dataframe) {
>
> }
>
>
> Any help is very appreciated.
>
> Thanks,
> Sandip
>
> [[alternative HTML version deleted]]
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] C API to get numrow of data frame
Hi ,
Is there any C API to the R API nrow of dataframe ?
x<- data.frame()
n<- nrow(x)
print(n)
0
Example :
My C function which deals with data frame looks like and I don't to send
the number of rows of data frame .I want to detect it from the function
itself, my function take data frame as argument and do some on it. I want
API equivalent to nrow. I tried Rf_nrows,Rf_ncols . No much help.
SEXP writeRR(SEXP dataframe) {
}
Any help is very appreciated.
Thanks,
Sandip
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] rgl question
On 31/03/2014 12:56 PM, Dominick Samperi wrote: Thanks for the comment. No, there were no such prior calls, unless rgl.lines() itself sets lty to dashed? Here is a simple session run under Windows: library(rgl) x <- 1:20 y <- 1:20 z <- 1:20 rgl.lines(x,y,z) # displays dashed line lines3d(x,y,z) # displays solid line Sorry, what I said was true, but wasn't helpful. The real explanation is that rgl.lines corresponds to segments3d, not to lines3d. It pairs up the points and draws line segments, it doesn't join the points. Use rgl.linestrips (the OpenGL terminology) if you want the equivalent of lines3d but with the persistant material properties. I had forgotten that, because I never use the rgl.* functions. I would say "neither should you", but there might be some good reason to do so. Duncan Murdoch I'm using R 3.1.0 alpha On Mon, Mar 31, 2014 at 5:44 AM, Duncan Murdoch wrote: > On 30/03/2014, 9:20 PM, Dominick Samperi wrote: >> >> Hello, >> >> If I call lines3d(x,y,z) I get lines connecting each point, but >> when I call rgl.lines(x,y,z) I get dashed lines, and adding >> something like type='l' leads to an error message. The >> docs seem to suggest that rgl.lines() calls lines3d(), so >> I would expect the result to be the same. >> >> Any tips would be appreciated. > > > The difference is in how they use the material properties: rgl.lines sets > them permanently, lines3d restores the original value after the call. So > I'd guess your call to rgl.lines followed a call to another rgl.* function > that set the lty property to dashed. > > Duncan Murdoch __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] rgl question
Thanks for the comment. No, there were no such prior calls, unless rgl.lines() itself sets lty to dashed? Here is a simple session run under Windows: library(rgl) x <- 1:20 y <- 1:20 z <- 1:20 rgl.lines(x,y,z) # displays dashed line lines3d(x,y,z) # displays solid line I'm using R 3.1.0 alpha On Mon, Mar 31, 2014 at 5:44 AM, Duncan Murdoch wrote: > On 30/03/2014, 9:20 PM, Dominick Samperi wrote: >> >> Hello, >> >> If I call lines3d(x,y,z) I get lines connecting each point, but >> when I call rgl.lines(x,y,z) I get dashed lines, and adding >> something like type='l' leads to an error message. The >> docs seem to suggest that rgl.lines() calls lines3d(), so >> I would expect the result to be the same. >> >> Any tips would be appreciated. > > > The difference is in how they use the material properties: rgl.lines sets > them permanently, lines3d restores the original value after the call. So > I'd guess your call to rgl.lines followed a call to another rgl.* function > that set the lty property to dashed. > > Duncan Murdoch __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] internal string comparison (Scollate)
Hello,
The use case I have might involve sorting many small such STRSXP vectors.
If I have Scollate, I don’t need to materialize the vectors and I can use the
sorting algorithm I choose.
Here is some made up data:
df <- data.frame(
x = sample( 1:10, 1000, replace = TRUE),
y = sample( 1:100, 100, replace = TRUE),
z = replicate( 1, paste( sample(letters, sample(1:100, size = 1), replace
= TRUE ), collapse = "" ) ),
stringsAsFactors = FALSE
)
For which I’d like something like what order( df$x, df$y, df$z ) gives me.
For example:
> system.time( res1 <- order( df$x, df$y, df$z) )
utilisateur système écoulé
0.017 0.000 0.017
> system.time( res2 <- dplyr::order_( df$x, df$y, df$z ) )
utilisateur système écoulé
0.005 0.000 0.005
> identical( res1, res2 )
[1] TRUE
The way dplyr::order_ is implemented I don’t need to materialize 500 STRSXP
vectors and call order or sort on them ( 492 == nrow( unique( df[, c("x", "y" )
] ) ) )
I just need to be able to compare two scalars together (either two ints, two
doubles, or two CHARSXP SEXP). We already have special code to handle what it
means to compare int, double etc in the R world with NA and NaN, etc ...
Scollate would give a way to compare two CHARSXP SEXP, the way R would. Of
course one has to be careful how it is called, I have read the source.
Materialising temporary values into an R vector may be the R way of doing
things, but sometimes it is a waste of both memory and time. Yes, this is about
performance. We are often asked to choose between performance and correctness
when in fact we can have both.
Romain
Le 27 mars 2014 à 22:12, Duncan Murdoch a écrit :
> On 14-03-27 3:01 PM, Kevin Ushey wrote:
>> I too think it would be useful if R exported some version of its
>> string sorting routines, since sorting strings while respecting
>> locale, and doing so in a portable fashion while respecting the user's
>> environment, is not trivial. R holds a fast, portable, well-tested
>> solution, and I think package developers would be very appreciative if
>> some portion of this was exposed at the C level.
>
> It does. You can put your strings in an R STRSXP vector, and call the R sort
> function on it.
>
> The usual objection to constructing an R expression and evaluating it is that
> it is slow, but if you are talking about sorting, the time spent in the sort
> is likely to dominate the time spent in the setup.
>
>>
>> If not `Scollate`, then perhaps other candidates could be the more
>> generic `sortVector`, or the more string-specific (and NA-respecting)
>> `scmp`.
>
> Evaluating an R expression gives you sortVector.
>
> I can see an argument for Scollate being useful (sorting isn't the only
> reason to compare strings), but I can see arguments against exposing it too.
> Take a look at the source: it needs to be used carefully. In particular, it
> can return a 0 for unequal strings, and users are likely to get messed up by
> that, or to submit bogus bug reports. And it's not impossible to work
> around: if you can collect the universe of strings to compare in advance,
> then just use order() to convert them to integer values, and compare those.
>
> Duncan Murdoch
>
>>
>> I understand that the volunteers at R Core have limited time and
>> resources, and exposing an API imposes additional maintenance burdens
>> on an already thinly stretched team, but this is a situation where the
>> R users and package authors alike could benefit. Or, if there are
>> other reasons why exporting such routines is not possible nor
>> recommended, it would be very informative to know why.
>>
>> Thanks,
>> Kevin
>>
>> On Thu, Mar 27, 2014 at 11:08 AM, Dirk Eddelbuettel wrote:
>>>
>>> On 26 March 2014 at 19:09, Romain François wrote:
>>> | That's one part of the problem. Indeed I'd rather use something rather
>>> than
>>> | copy and paste it and run the risk of being outdated. The answer to that
>>> is
>>>
>>> We all would. But "they" won't let us by refusing to create more API access
>>> points.
>>>
>>> | testing though. I can develop a test suite that can let me know I'm out of
>>>
>>> Correct.
>>>
>>> | date and I need to copy and paste some new code, etc ... Done that
>>> before, this
>>> | is tedious, but so what.
>>> |
>>> | The other part of the problem (the real part of the problem actually) is
>>> that,
>>> | at least when R is built with ICU support, Scollate will depend on a the
>>> | collator pointer in util.c
>>> | https://github.com/wch/r-source/blob/trunk/src/main/util.c#L1777
>>> |
>>> | And this can be controlled by the base::icuSetCollate function. Of course
>>> the
>>> | collator pointer is not public.
>>>
>>> So the next (and even less pleasant) answer is to build a new package which
>>> links to, (or worse yet, embeds) libicu.
>>>
>>> As you want ICU behaviour, you will need ICU code.
>>>
>>> Dirk
>>>
>>> --
>>> Dirk Eddelbuettel | e.
Re: [Rd] CXX_STD and configure.ac in packages
On 03/31/2014 04:30 AM, Romain François wrote:
Le 31 mars 2014 à 12:20, Martyn Plummer a écrit :
On Mon, 2014-03-31 at 07:09 +, Martyn Plummer wrote:
Hi Martin,
Thanks for the patch. I have applied it. I also added CXX1X and friends to the
list of approved variables for R CMD config.
So you can now query the existence of C++11 support with `R CMD config CXX1X`
(It is empty if C++11 support is not available)
and then take appropriate action in your configure script if, in Dirk's words,
you want to do the configure dance.
Thanks, this is what I was looking for.
The philosophy underlying C++ support in R is that there are only two standards
- C++98 and C++11 - and that
you should write to one of those standards.
A should add a clarification. The way I wrote this makes it sound like
an even-handed choice, but only C++98 has cross-platform support. If you
use C++11 then many users will not currently be able to use your code.
Yes, the Writing R Extensions section at first seduced me into thinking that I
could get broad support for C++11 with a simple macro, but obviously that can
only come from the underlying compilers and R is making no guarantees about these.
OTOH, if nobody goes there, the need for C++11 might not be perceived as
important by people who take care of cross platform support.
Probably not Martin’s fight. One can do the gymnastics to get an unordered_map
with C++98 (through boost, tr1, etc ...), but C++11 brings a great combination
of new features that make it a better language, and I agree that it is almost a
new language. And once you start using it, it is hard to look back.
Nobody should be writing new code that uses TR1 extensions now: they are
superseded by the new standard.
For me unordered_map is a small part of a large mostly C code base; using it
instead of map has substantial benefits, but restricting package use to C++11
isn't really on the table in this particular case.
I'll take Martyn's philosophical statement that for R there are only two
standards -- C++98 and C++11, with attendant trade-offs -- as a guiding
principle and as a pragmatic solution avoid my complicated unordered_map
configure dance for now.
Thanks all for the various inputs.
Martin Morgan
The map and unordered_map classes are a corner case, as they offer the same
functionality but latter has much better
complexity guarantees, so it is tempting to use it when available. But from a
global perspective you should think of
C++98 and C++11 as two different languages.
Martyn
From: r-devel-boun...@r-project.org [r-devel-boun...@r-project.org] on behalf
of Romain Francois [rom...@r-enthusiasts.com]
Sent: 31 March 2014 08:22
To: Martin Morgan
Cc: R-devel
Subject: Re: [Rd] CXX_STD and configure.ac in packages
Hi,
My advice would be to use SystemRequirements: C++11
As is definitely a part of C++11, assuming this version of the
standard gives it to you. Your package may not compile on platforms where a C++11
compiler is not available, but perhaps if this becomes a pattern, then such compilers
will start to be available, as in the current version of OSX and recent enough
versions of various linux distributions.
The subset of feature that the version of gcc gives you with Rtools might be
enough.
Alternatively, if you use Rcpp, you can use the RCPP_UNORDERED_MAP macro which
will expand to either unordered_map or tr1::unordered_map, all the condition
compiling is done in Rcpp.
Romain
Le 30 mars 2014 à 21:50, Martin Morgan a écrit :
In C++ code for use in a R-3.1.0 package, my specific problem is that I would like to use
if it is available, or if not, or if
all else fails.
I (think I) can accomplish this with configure.ac as
AC_INIT("DESCRIPTION")
CXX=`"${R_HOME}/bin/R" CMD config CXX`
CXXFLAGS=`"${R_HOME}/bin/R" CMD config CXXFLAGS`
AC_CONFIG_HEADERS([src/config.h])
AC_LANG(C++)
AC_CHECK_HEADERS([unordered_map tr1/unordered_map])
AC_OUTPUT
Use of configure.ac does not seem to be entirely consistent with section 1.2.4
of Writing R Extensions, where one is advised that to use C++(11? see below)
code one should
CXX_STD = CXX11
in Makevars(.win). My code does not require a compiler that supports the full
C++11 feature set. In addition, I do not understand the logic of setting a
variable that influences compiler flags in Makevars -- configure.ac will see a
compiler with inaccurate flags.
Is use of configure.ac orthogonal to setting CXX_STD=CXX11?
Some minor typos:
/R-3-1-branch$ svn diff
Index: doc/manual/R-exts.texi
===
--- doc/manual/R-exts.texi(revision 65339)
+++ doc/manual/R-exts.texi(working copy)
@@ -2250,7 +2250,7 @@
@subsection Using C++11 code
@R{} can be built without a C++ compiler although one is available
-(but not necessarily installed) or all known @R{} platforms.
+(but not necessarily installed) on all known @R{}
Re: [Rd] CXX_STD and configure.ac in packages
Le 31 mars 2014 à 12:20, Martyn Plummer a écrit :
> On Mon, 2014-03-31 at 07:09 +, Martyn Plummer wrote:
>> Hi Martin,
>>
>> Thanks for the patch. I have applied it. I also added CXX1X and friends to
>> the list of approved variables for R CMD config.
>> So you can now query the existence of C++11 support with `R CMD config
>> CXX1X` (It is empty if C++11 support is not available)
>> and then take appropriate action in your configure script if, in Dirk's
>> words, you want to do the configure dance.
>>
>> The philosophy underlying C++ support in R is that there are only two
>> standards - C++98 and C++11 - and that
>> you should write to one of those standards.
>
> A should add a clarification. The way I wrote this makes it sound like
> an even-handed choice, but only C++98 has cross-platform support. If you
> use C++11 then many users will not currently be able to use your code.
OTOH, if nobody goes there, the need for C++11 might not be perceived as
important by people who take care of cross platform support.
Probably not Martin’s fight. One can do the gymnastics to get an unordered_map
with C++98 (through boost, tr1, etc ...), but C++11 brings a great combination
of new features that make it a better language, and I agree that it is almost a
new language. And once you start using it, it is hard to look back.
>> Nobody should be writing new code that uses TR1 extensions now: they are
>> superseded by the new standard.
>>
>> The map and unordered_map classes are a corner case, as they offer the same
>> functionality but latter has much better
>> complexity guarantees, so it is tempting to use it when available. But from
>> a global perspective you should think of
>> C++98 and C++11 as two different languages.
>>
>> Martyn
>>
>>
>> From: r-devel-boun...@r-project.org [r-devel-boun...@r-project.org] on
>> behalf of Romain Francois [rom...@r-enthusiasts.com]
>> Sent: 31 March 2014 08:22
>> To: Martin Morgan
>> Cc: R-devel
>> Subject: Re: [Rd] CXX_STD and configure.ac in packages
>>
>> Hi,
>>
>> My advice would be to use SystemRequirements: C++11
>>
>> As is definitely a part of C++11, assuming this version of
>> the standard gives it to you. Your package may not compile on platforms
>> where a C++11 compiler is not available, but perhaps if this becomes a
>> pattern, then such compilers will start to be available, as in the current
>> version of OSX and recent enough versions of various linux distributions.
>>
>> The subset of feature that the version of gcc gives you with Rtools might be
>> enough.
>>
>> Alternatively, if you use Rcpp, you can use the RCPP_UNORDERED_MAP macro
>> which will expand to either unordered_map or tr1::unordered_map, all the
>> condition compiling is done in Rcpp.
>>
>> Romain
>>
>> Le 30 mars 2014 à 21:50, Martin Morgan a écrit :
>>
>>> In C++ code for use in a R-3.1.0 package, my specific problem is that I
>>> would like to use if it is available, or
>>> if not, or if all else fails.
>>>
>>> I (think I) can accomplish this with configure.ac as
>>>
>>> AC_INIT("DESCRIPTION")
>>>
>>> CXX=`"${R_HOME}/bin/R" CMD config CXX`
>>> CXXFLAGS=`"${R_HOME}/bin/R" CMD config CXXFLAGS`
>>>
>>> AC_CONFIG_HEADERS([src/config.h])
>>> AC_LANG(C++)
>>> AC_CHECK_HEADERS([unordered_map tr1/unordered_map])
>>> AC_OUTPUT
>>>
>>> Use of configure.ac does not seem to be entirely consistent with section
>>> 1.2.4 of Writing R Extensions, where one is advised that to use C++(11? see
>>> below) code one should
>>>
>>> CXX_STD = CXX11
>>>
>>> in Makevars(.win). My code does not require a compiler that supports the
>>> full C++11 feature set. In addition, I do not understand the logic of
>>> setting a variable that influences compiler flags in Makevars --
>>> configure.ac will see a compiler with inaccurate flags.
>>>
>>> Is use of configure.ac orthogonal to setting CXX_STD=CXX11?
>>>
>>> Some minor typos:
>>>
>>> /R-3-1-branch$ svn diff
>>> Index: doc/manual/R-exts.texi
>>> ===
>>> --- doc/manual/R-exts.texi(revision 65339)
>>> +++ doc/manual/R-exts.texi(working copy)
>>> @@ -2250,7 +2250,7 @@
>>> @subsection Using C++11 code
>>>
>>> @R{} can be built without a C++ compiler although one is available
>>> -(but not necessarily installed) or all known @R{} platforms.
>>> +(but not necessarily installed) on all known @R{} platforms.
>>> For full portability across platforms, all
>>> that can be assumed is approximate support for the C++98 standard (the
>>> widely used @command{g++} deviates considerably from the standard).
>>> @@ -2272,7 +2272,7 @@
>>> support a flag @option{-std=c++0x}, but the latter only provides partial
>>> support for the C++11 standard.
>>>
>>> -In order to use C++ code in a package, the package's @file{Makevars}
>>> +In order to use C++11 code in a package, the package's @file{Makevars}
>>> file (or @file{M
Re: [Rd] CXX_STD and configure.ac in packages
On Mon, 2014-03-31 at 07:09 +, Martyn Plummer wrote:
> Hi Martin,
>
> Thanks for the patch. I have applied it. I also added CXX1X and friends to
> the list of approved variables for R CMD config.
> So you can now query the existence of C++11 support with `R CMD config CXX1X`
> (It is empty if C++11 support is not available)
> and then take appropriate action in your configure script if, in Dirk's
> words, you want to do the configure dance.
>
> The philosophy underlying C++ support in R is that there are only two
> standards - C++98 and C++11 - and that
> you should write to one of those standards.
A should add a clarification. The way I wrote this makes it sound like
an even-handed choice, but only C++98 has cross-platform support. If you
use C++11 then many users will not currently be able to use your code.
> Nobody should be writing new code that uses TR1 extensions now: they are
> superseded by the new standard.
>
> The map and unordered_map classes are a corner case, as they offer the same
> functionality but latter has much better
> complexity guarantees, so it is tempting to use it when available. But from
> a global perspective you should think of
> C++98 and C++11 as two different languages.
>
> Martyn
>
>
>
> From: r-devel-boun...@r-project.org [r-devel-boun...@r-project.org] on behalf
> of Romain Francois [rom...@r-enthusiasts.com]
> Sent: 31 March 2014 08:22
> To: Martin Morgan
> Cc: R-devel
> Subject: Re: [Rd] CXX_STD and configure.ac in packages
>
> Hi,
>
> My advice would be to use SystemRequirements: C++11
>
> As is definitely a part of C++11, assuming this version of
> the standard gives it to you. Your package may not compile on platforms where
> a C++11 compiler is not available, but perhaps if this becomes a pattern,
> then such compilers will start to be available, as in the current version of
> OSX and recent enough versions of various linux distributions.
>
> The subset of feature that the version of gcc gives you with Rtools might be
> enough.
>
> Alternatively, if you use Rcpp, you can use the RCPP_UNORDERED_MAP macro
> which will expand to either unordered_map or tr1::unordered_map, all the
> condition compiling is done in Rcpp.
>
> Romain
>
> Le 30 mars 2014 à 21:50, Martin Morgan a écrit :
>
> > In C++ code for use in a R-3.1.0 package, my specific problem is that I
> > would like to use if it is available, or
> > if not, or if all else fails.
> >
> > I (think I) can accomplish this with configure.ac as
> >
> > AC_INIT("DESCRIPTION")
> >
> > CXX=`"${R_HOME}/bin/R" CMD config CXX`
> > CXXFLAGS=`"${R_HOME}/bin/R" CMD config CXXFLAGS`
> >
> > AC_CONFIG_HEADERS([src/config.h])
> > AC_LANG(C++)
> > AC_CHECK_HEADERS([unordered_map tr1/unordered_map])
> > AC_OUTPUT
> >
> > Use of configure.ac does not seem to be entirely consistent with section
> > 1.2.4 of Writing R Extensions, where one is advised that to use C++(11? see
> > below) code one should
> >
> >CXX_STD = CXX11
> >
> > in Makevars(.win). My code does not require a compiler that supports the
> > full C++11 feature set. In addition, I do not understand the logic of
> > setting a variable that influences compiler flags in Makevars --
> > configure.ac will see a compiler with inaccurate flags.
> >
> > Is use of configure.ac orthogonal to setting CXX_STD=CXX11?
> >
> > Some minor typos:
> >
> > /R-3-1-branch$ svn diff
> > Index: doc/manual/R-exts.texi
> > ===
> > --- doc/manual/R-exts.texi(revision 65339)
> > +++ doc/manual/R-exts.texi(working copy)
> > @@ -2250,7 +2250,7 @@
> > @subsection Using C++11 code
> >
> > @R{} can be built without a C++ compiler although one is available
> > -(but not necessarily installed) or all known @R{} platforms.
> > +(but not necessarily installed) on all known @R{} platforms.
> > For full portability across platforms, all
> > that can be assumed is approximate support for the C++98 standard (the
> > widely used @command{g++} deviates considerably from the standard).
> > @@ -2272,7 +2272,7 @@
> > support a flag @option{-std=c++0x}, but the latter only provides partial
> > support for the C++11 standard.
> >
> > -In order to use C++ code in a package, the package's @file{Makevars}
> > +In order to use C++11 code in a package, the package's @file{Makevars}
> > file (or @file{Makevars.win} on Windows) should include the line
> >
> > @example
> > @@ -2329,7 +2329,7 @@
> > anything other than the GNU version of C++98 and GNU extensions (which
> > include TR1). The default compiler on Windows is GCC 4.6.x and supports
> > the @option{-std=c++0x} flag and some C++11 features (see
> > -@uref{http://gcc.gnu.org/gcc-4.6/cxx0x_status.html}. On these
> > +@uref{http://gcc.gnu.org/gcc-4.6/cxx0x_status.html}). On these
> > platforms, it is necessary to select a different compiler for C++11, as
> > described above, @emph{via} personal @file{Make
Re: [Rd] rgl question
On 30/03/2014, 9:20 PM, Dominick Samperi wrote: Hello, If I call lines3d(x,y,z) I get lines connecting each point, but when I call rgl.lines(x,y,z) I get dashed lines, and adding something like type='l' leads to an error message. The docs seem to suggest that rgl.lines() calls lines3d(), so I would expect the result to be the same. Any tips would be appreciated. The difference is in how they use the material properties: rgl.lines sets them permanently, lines3d restores the original value after the call. So I'd guess your call to rgl.lines followed a call to another rgl.* function that set the lty property to dashed. Duncan Murdoch __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] CXX_STD and configure.ac in packages
Hi Martin,
Thanks for the patch. I have applied it. I also added CXX1X and friends to the
list of approved variables for R CMD config.
So you can now query the existence of C++11 support with `R CMD config CXX1X`
(It is empty if C++11 support is not available)
and then take appropriate action in your configure script if, in Dirk's words,
you want to do the configure dance.
The philosophy underlying C++ support in R is that there are only two standards
- C++98 and C++11 - and that
you should write to one of those standards. Nobody should be writing new code
that uses TR1 extensions now: they are
superseded by the new standard.
The map and unordered_map classes are a corner case, as they offer the same
functionality but latter has much better
complexity guarantees, so it is tempting to use it when available. But from a
global perspective you should think of
C++98 and C++11 as two different languages.
Martyn
From: r-devel-boun...@r-project.org [r-devel-boun...@r-project.org] on behalf
of Romain Francois [rom...@r-enthusiasts.com]
Sent: 31 March 2014 08:22
To: Martin Morgan
Cc: R-devel
Subject: Re: [Rd] CXX_STD and configure.ac in packages
Hi,
My advice would be to use SystemRequirements: C++11
As is definitely a part of C++11, assuming this version of the
standard gives it to you. Your package may not compile on platforms where a
C++11 compiler is not available, but perhaps if this becomes a pattern, then
such compilers will start to be available, as in the current version of OSX and
recent enough versions of various linux distributions.
The subset of feature that the version of gcc gives you with Rtools might be
enough.
Alternatively, if you use Rcpp, you can use the RCPP_UNORDERED_MAP macro which
will expand to either unordered_map or tr1::unordered_map, all the condition
compiling is done in Rcpp.
Romain
Le 30 mars 2014 à 21:50, Martin Morgan a écrit :
> In C++ code for use in a R-3.1.0 package, my specific problem is that I would
> like to use if it is available, or if
> not, or if all else fails.
>
> I (think I) can accomplish this with configure.ac as
>
> AC_INIT("DESCRIPTION")
>
> CXX=`"${R_HOME}/bin/R" CMD config CXX`
> CXXFLAGS=`"${R_HOME}/bin/R" CMD config CXXFLAGS`
>
> AC_CONFIG_HEADERS([src/config.h])
> AC_LANG(C++)
> AC_CHECK_HEADERS([unordered_map tr1/unordered_map])
> AC_OUTPUT
>
> Use of configure.ac does not seem to be entirely consistent with section
> 1.2.4 of Writing R Extensions, where one is advised that to use C++(11? see
> below) code one should
>
>CXX_STD = CXX11
>
> in Makevars(.win). My code does not require a compiler that supports the full
> C++11 feature set. In addition, I do not understand the logic of setting a
> variable that influences compiler flags in Makevars -- configure.ac will see
> a compiler with inaccurate flags.
>
> Is use of configure.ac orthogonal to setting CXX_STD=CXX11?
>
> Some minor typos:
>
> /R-3-1-branch$ svn diff
> Index: doc/manual/R-exts.texi
> ===
> --- doc/manual/R-exts.texi(revision 65339)
> +++ doc/manual/R-exts.texi(working copy)
> @@ -2250,7 +2250,7 @@
> @subsection Using C++11 code
>
> @R{} can be built without a C++ compiler although one is available
> -(but not necessarily installed) or all known @R{} platforms.
> +(but not necessarily installed) on all known @R{} platforms.
> For full portability across platforms, all
> that can be assumed is approximate support for the C++98 standard (the
> widely used @command{g++} deviates considerably from the standard).
> @@ -2272,7 +2272,7 @@
> support a flag @option{-std=c++0x}, but the latter only provides partial
> support for the C++11 standard.
>
> -In order to use C++ code in a package, the package's @file{Makevars}
> +In order to use C++11 code in a package, the package's @file{Makevars}
> file (or @file{Makevars.win} on Windows) should include the line
>
> @example
> @@ -2329,7 +2329,7 @@
> anything other than the GNU version of C++98 and GNU extensions (which
> include TR1). The default compiler on Windows is GCC 4.6.x and supports
> the @option{-std=c++0x} flag and some C++11 features (see
> -@uref{http://gcc.gnu.org/gcc-4.6/cxx0x_status.html}. On these
> +@uref{http://gcc.gnu.org/gcc-4.6/cxx0x_status.html}). On these
> platforms, it is necessary to select a different compiler for C++11, as
> described above, @emph{via} personal @file{Makevars} files. For
> example, on OS X 10.7 or later one could select @command{clang++}.
>
> --
> Computational Biology / Fred Hutchinson Cancer Research Center
> 1100 Fairview Ave. N.
> PO Box 19024 Seattle, WA 98109
>
> Location: Arnold Building M1 B861
> Phone: (206) 667-2793
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
__
R-devel@r-project.org mailing list
https://
