Re: [Rd] using C code to create data frame but always return as list
sorry, i am make mistake,it indeed return a data frame ,please ignore this
question
On Tuesday, June 24, 2014 2:57 PM, Yu Gong wrote:
there is my code, expect return value is a data frame but R say it is list:
SEXP Julia_R_MD_NA_DataFrame(jl_value_t* Var)
{
SEXP ans,names,rownames;
char evalcmd[4096];
int i;
const char* dfname="DataFrameName0tmp";
jl_set_global(jl_main_module, jl_symbol(dfname), (jl_value_t*)Var);
//Get Frame cols
sprintf(evalcmd,"size(%s,2)",dfname);
jl_value_t* cols=jl_eval_string(evalcmd);
int collen=jl_unbox_long(cols);
jl_value_t* eachcolvector;
//Create VECSXP
//Create SEXP for Each Column and assign
PROTECT(ans=allocVector(VECSXP,collen));
for (i=0;iname));
}
setAttrib(ans,R_NamesSymbol,names);
UNPROTECT(1);
}
//set row names
sprintf(evalcmd,"size(%s,1)",dfname);
jl_value_t* rows=jl_eval_string(evalcmd);
int rowlen=jl_unbox_long(rows);
PROTECT(rownames=allocVector(INTSXP,rowlen));
for (i=0;i__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Unfixed bugs in latest R-patched
It's hardly fair to call these "unfixed bugs". Most of them are better described as "unreported bugs", or, after this posting, "bugs reported with insufficient detail". We can't fix them if we don't know what they are, and it's not easy to determine that for most of the items below. Duncan Murdoch On 23/06/2014, 5:24 PM, Radford Neal wrote: > A new version of pqR is now available at pqR-project.org, which fixes > several bugs that are also present in the latest R Core patch release > (r66002). A number of bugs found previously during pqR development > are also unfixed in the latest R Core release. Here is the list of > these bugs that are unfixed in r66002 (including documentation > deficiencies), taken from the pqR bug fix and documentation update > sections of the pqR NEWS file (pqR-project.org/NEWS.txt): > > o The documentation for c now says how the names for the result are > determined, including previously missing information on the > use.names argument, and on the role of the names of arguments in > the call of c. This documentation is missing in R-2.15.0 and > R-3.1.0. > > o The documentaton for diag now documents that a diagonal matrix is > always created with type double or complex, and that the names of > an extracted diagonal vector are taken from a names attribute (if > present), if not from the row and column names. This information > is absent in the documentation in R-2.15.1 and R-3.1.0. > > o Incorrect information regarding the pointer protection stack was > removed from help(Memory). This incorrect information is present > in R-2.15.0 and R-3.1.0 as well. > > o There is now information in help(Arithmetic) regarding what > happens when the operands of an arithmetic operation are NA or > NaN, including the arbitrary nature of the result when one > operand is NA and the other is NaN. There is no discussion of > this issue in the documentation for R-2.15.0 and R-3.1.0. > > o Fixed lack of protection bugs in the equal and greater functions > in sort.c. These bugs are also present in R-2.15.0 and R-3.1.0. > > o Fixed lack of protection bugs in the D function in deriv.c. > These bugs are also present in R-2.15.0 and R-3.1.0. > > o Fixed argument error-checking bugs in getGraphicsEventEnv and > setGraphicsEventEnv (also present in R-2.15.0 and R-3.1.0). > > o Fixed the following bug (also present in R-2.15.0 and R-3.0.2): > > x <- t(5) > print (x %*% c(3,4)) > print (crossprod(5,c(3,4))) > > The call of crossprod produced an error, whereas the > corresponding use of %*% does not. > > In pqR-2013-12-29, this bug also affected the expression t(5) %*% > c(3,4), since it is converted to the equivalent of > crossprod(5,c(3,4)). > > o Fixed a problem in R_AllocStringBuffer that could result in a > crash due to an invalid memory access. (This bug is also present > in R-2.15.0 and R-3.0.2.) > > o The documentation for aperm now says that the default method does > not copy attributes (other than dimensions and dimnames). > Previously, it incorrecty said it did (as is the case also in > R-2.15.0 and R-3.0.2). > > o Fixed the following bug (also present in R-2.15.0 and R-3.0.2): > > v <- c(1,2) > m <- matrix(c(3,4),1,2) > print(t(m)%*%v) > print(crossprod(m,v)) > > in which crossprod gave an error rather than produce the answer > for the corresponding use of %*%. > > o Raising -Inf to a large value (eg, (-Inf)^(1e16)) no longer > produces an incomprehensible warning. As before, the value > returned is Inf, because (due to their limited-precision > floating-point representation) all such large numbers are even > integers. > > o Fixed a bug (also present in R-2.15.0 and R-3.0.1) illustrated by > the following code: > > > a <- list(x=c(1,2),y=c(3,4)) > > b <- as.pairlist(a) > > b$x[1] <- 9 > > print(a) > $x > [1] 9 2 > > $y > [1] 3 4 > > The value printed for a has a$x[1] changed to 9, when it should > still be 1. See pqR issue #14. > > o Fixed several bugs (also present in R-2.15.0 and R-3.0.1) > illustrated by the code below (see pqR issue #16): > > v <- c(10,20,30) > v[[2]] <- NULL# wrong error message > > x <- pairlist(list(1,2)) > x[[c(1,2)]] <- NULL # wrongly gives an error, referring to misuse ># of the internal SET_VECTOR_ELT procedure > > v<-list(1) > v[[quote(abc)]] <- 2 # internal error, this time for SET_STRING_ELT > > a <- pairlist(10,20,30,40,50,60) > dim(a) <- c(2,3) >
Re: [Rd] using C code to create data frame but always return as list
Hi,
Can you give us what str on the returned object gives you?
I think you need :
SET_OBJECT(and, 1) ;
at the end.
Romain
Le 24 juin 2014 à 08:57, Yu Gong a écrit :
> there is my code, expect return value is a data frame but R say it is list:
>
> SEXP Julia_R_MD_NA_DataFrame(jl_value_t* Var)
> {
> SEXP ans,names,rownames;
> char evalcmd[4096];
> int i;
> const char* dfname="DataFrameName0tmp";
> jl_set_global(jl_main_module, jl_symbol(dfname), (jl_value_t*)Var);
> //Get Frame cols
> sprintf(evalcmd,"size(%s,2)",dfname);
> jl_value_t* cols=jl_eval_string(evalcmd);
> int collen=jl_unbox_long(cols);
> jl_value_t* eachcolvector;
> //Create VECSXP
>
> //Create SEXP for Each Column and assign
> PROTECT(ans=allocVector(VECSXP,collen));
> for (i=0;i {
> sprintf(evalcmd,"%s[%d]",dfname,i+1);
> eachcolvector=jl_eval_string(evalcmd);
> SET_VECTOR_ELT(ans,i,Julia_R_MD_NA(eachcolvector));
> }
> //set names attribute
> sprintf(evalcmd,"names(%s)",dfname);
> jl_value_t* ret=jl_eval_string(evalcmd);
> jl_value_t* onesymbol;
> if (jl_is_array(ret))
> {
> PROTECT(names=allocVector(STRSXP,collen));
> for (i=0;i {
>onesymbol=jl_arrayref((jl_array_t*)ret,i);
>if (jl_is_symbol(onesymbol))
> SET_STRING_ELT(names,i,mkChar(((jl_sym_t*)onesymbol)->name));
> }
> setAttrib(ans,R_NamesSymbol,names);
> UNPROTECT(1);
> }
> //set row names
> sprintf(evalcmd,"size(%s,1)",dfname);
> jl_value_t* rows=jl_eval_string(evalcmd);
> int rowlen=jl_unbox_long(rows);
> PROTECT(rownames=allocVector(INTSXP,rowlen));
> for (i=0;i INTEGER(rownames)[i]=i+1;
> setAttrib(ans,R_RowNamesSymbol,rownames);
> UNPROTECT(1);
> //set class as data frame
> setAttrib(ans,R_ClassSymbol,mkString("data.frame"));
> UNPROTECT(1);
> return ans;
> }
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Unfixed bugs in latest R-patched
On Tue, Jun 24, 2014 at 09:20:30AM +0200, Duncan Murdoch wrote: > It's hardly fair to call these "unfixed bugs". Most of them are better > described as "unreported bugs", or, after this posting, "bugs reported > with insufficient detail". We can't fix them if we don't know what they > are, and it's not easy to determine that for most of the items below. I think most of them are pretty clear. For the ones referring to lack of protection or argument error checking code, I suggesting doing a "diff" on the source files to find where I made changes. If your complaint is that your time is more valuable than my time, so I should be producing a nice patch for you, then I don't agree. I went to the effort of verifing that the bugs are still present in r66002. That's as much as I'm willing to do. It's up to you what you do. Radford Neal > On 23/06/2014, 5:24 PM, Radford Neal wrote: > > A new version of pqR is now available at pqR-project.org, which fixes > > several bugs that are also present in the latest R Core patch release > > (r66002). A number of bugs found previously during pqR development > > are also unfixed in the latest R Core release. Here is the list of > > these bugs that are unfixed in r66002 (including documentation > > deficiencies), taken from the pqR bug fix and documentation update > > sections of the pqR NEWS file (pqR-project.org/NEWS.txt): > > > > o The documentation for c now says how the names for the result are > > determined, including previously missing information on the > > use.names argument, and on the role of the names of arguments in > > the call of c. This documentation is missing in R-2.15.0 and > > R-3.1.0. > > > > o The documentaton for diag now documents that a diagonal matrix is > > always created with type double or complex, and that the names of > > an extracted diagonal vector are taken from a names attribute (if > > present), if not from the row and column names. This information > > is absent in the documentation in R-2.15.1 and R-3.1.0. > > > > o Incorrect information regarding the pointer protection stack was > > removed from help(Memory). This incorrect information is present > > in R-2.15.0 and R-3.1.0 as well. > > > > o There is now information in help(Arithmetic) regarding what > > happens when the operands of an arithmetic operation are NA or > > NaN, including the arbitrary nature of the result when one > > operand is NA and the other is NaN. There is no discussion of > > this issue in the documentation for R-2.15.0 and R-3.1.0. > > > > o Fixed lack of protection bugs in the equal and greater functions > > in sort.c. These bugs are also present in R-2.15.0 and R-3.1.0. > > > > o Fixed lack of protection bugs in the D function in deriv.c. > > These bugs are also present in R-2.15.0 and R-3.1.0. > > > > o Fixed argument error-checking bugs in getGraphicsEventEnv and > > setGraphicsEventEnv (also present in R-2.15.0 and R-3.1.0). > > > > o Fixed the following bug (also present in R-2.15.0 and R-3.0.2): > > > > x <- t(5) > > print (x %*% c(3,4)) > > print (crossprod(5,c(3,4))) > > > > The call of crossprod produced an error, whereas the > > corresponding use of %*% does not. > > > > In pqR-2013-12-29, this bug also affected the expression t(5) %*% > > c(3,4), since it is converted to the equivalent of > > crossprod(5,c(3,4)). > > > > o Fixed a problem in R_AllocStringBuffer that could result in a > > crash due to an invalid memory access. (This bug is also present > > in R-2.15.0 and R-3.0.2.) > > > > o The documentation for aperm now says that the default method does > > not copy attributes (other than dimensions and dimnames). > > Previously, it incorrecty said it did (as is the case also in > > R-2.15.0 and R-3.0.2). > > > > o Fixed the following bug (also present in R-2.15.0 and R-3.0.2): > > > > v <- c(1,2) > > m <- matrix(c(3,4),1,2) > > print(t(m)%*%v) > > print(crossprod(m,v)) > > > > in which crossprod gave an error rather than produce the answer > > for the corresponding use of %*%. > > > > o Raising -Inf to a large value (eg, (-Inf)^(1e16)) no longer > > produces an incomprehensible warning. As before, the value > > returned is Inf, because (due to their limited-precision > > floating-point representation) all such large numbers are even > > integers. > > > > o Fixed a bug (also present in R-2.15.0 and R-3.0.1) illustrated by > > the following code: > > > > > a <- list(x=c(1,2),y=c(3,4)) > > > b <- as.pairlist(a) > > > b$x[1] <- 9 > > > print(a) > > $x > > [1] 9 2 > > > > $y > > [1] 3 4 > > > >
Re: [Rd] operation on ‘numsels’ may be undefined
Dear all,
Thank you very much for this interesting discussion, I appreciate it.
I think that Kevin gave a very good explanation why my code is
ambiguous, although it is not clear to me why the C/C++ standard leaves
this case undefined. One last question:
If I would write
numsels = {++numsels;}
Is this also undefined or is this then allowed?
Best regards,
Christian
On 6/24/14 7:28 AM, Kevin Ushey wrote:
I don't see what's so surprising here.
That statement is identical to writing:
if (arrMask[i] == 1) {
numsels = ++numsels;
} else {
numsels = numsels;
}
and
numsels = ++numsels;
has two statements modifying the value of numsels (= and prefix-++) in
a single sequence point. (Do we increment then assign, or assign then
increment? The C / C++ standards leave this undefined.)
Imagine writing the operations out as functions: we have the `=`
function, and the `prefix-++` function -- both of these 'modify' (one
of) their arguments. Do we evaluate it as `=`(a, `prefix-++`(a)) or
`prefix-++`(`=`(a, a))? The C standard leaves this undefined, so
compilers are free to do what they wish (and the nice ones warn you
when there is such an ambiguity). I guess the net result of the
operation is the same in each case _here_, but this is of course not
the case for other functions that modify the value of their
operand(s). And, in truth, this is _undefined behaviour_ and so the
compiler could still rightly make demons fly out of your nose if it
wanted to upon program execution.
I highly recommend reading the slides at
http://www.slideshare.net/olvemaudal/deep-c, especially the bit on
sequence points.
Cheers,
Kevin
On Mon, Jun 23, 2014 at 9:22 PM, Kasper Daniel Hansen
wrote:
I am not an expert on this, but I note that the section on -Wsequence-point
at
http://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html
specifically mentions ? and :. Perhaps some more work on tracking down
their definitions and precedence might lead to insights.
Best,
Kasper
On Mon, Jun 23, 2014 at 6:42 PM, Hervé Pagès wrote:
On 06/23/2014 03:18 PM, Hervé Pagès wrote:
Hi Christian,
On 06/23/2014 11:54 AM, cstrato wrote:
Dear Romain,
I do not know enough about compilers, but as far as I remember, they
'work' from right to left,
Not necessarily. So you should not rely on that. This is what the
(somewhat obscure) warning you see on zin1 is trying to tell you.
Actually, I don't see an ambiguity in your code:
numsels = (arrMask[i] == 1) ? ++numsels : numsels;
Yes it's confusing and unnecessarily complicated but I don't see that
it relies on some undefined behavior. It's not like in the thread on
Bioc-devel where the expression was:
*p++ = tolower(*p);
In that case the left-value of the assignment is itself an expression
that needs to be evaluated and the outcome of the assignment depends
on whether the left-value is evaluated before the right expression or
not. But in your case the left-value is a variable name so there is
nothing to evaluate.
So I don't know. Looks like a false positive from the gcc compiler to
me. Someone on the list might have a better insight.
Cheers,
H.
Personally I would just do:
if (arrMask[i] == 1) numsels++;
which is the standard way to implement the "if (some condition)
then increment counter" idiom.
As Kasper mentioned, a similar issue was recently discussed here:
https://stat.ethz.ch/pipermail/bioc-devel/2014-June/005858.html
Cheers,
H.
so numsels = ++numsels should not confuse the
compiler. Anyhow I will change my code to your first suggestion since it
is more elegant.
Best regards,
Christian
On 6/23/14 7:13 PM, Romain François wrote:
Le 23 juin 2014 à 18:28, cstrato a écrit :
Dear Romain,
Thank you for your suggestions, I like especially the first one.
However, you did not explain why I have never got this warning
message on any compiler, and why only one of the two identical Ubuntu
compilers did give this warning message?
Best regards,
Christian
I don’t know, but this:
numsels = ++numsels ;
seems fishy to me, and so it keeps feeling weird with the addition of
the ternary operator.
There is obviously a difference of setup between these two machines,
but I don’t have time to sherlock that for you. One of the compilers
is getting more careful than the other. Getting warnings you did not
get before is a good thing, as it helps you update the code with that
new insight.
Welcome to my world, I’m sometimes thrown all kinds of new warnings
from esoteric compilers, all of them have value .
Romain
On 6/23/14 3:45 PM, Romain François wrote:
Le 23 juin 2014 à 15:20, cstrato a écrit :
Dear all,
Since many years the following C++ code does compile on ALL
Bioconductor servers (Linux, Windows, Mac) without any warnings:
Int_t numsels = 0; //number of selected entries
...
for (Int_t i=0; i
This is confusing. I would write the loop body like this:
numsels += (arrMask[i] == 1) ;
Re: [Rd] using C code to create data frame but always return as list
On Jun 24, 2014, at 9:21 AM, Romain Francois wrote:
> Hi,
>
> Can you give us what str on the returned object gives you?
>
> I think you need :
>
> SET_OBJECT(and, 1) ;
>
> at the end.
>
SET_OBJECT should not be used by user code in normal circumstances, it is set
by R automatically as part of the handling of the "class" attribute.
Cheers,
S
> Romain
>
> Le 24 juin 2014 à 08:57, Yu Gong a écrit :
>
>> there is my code, expect return value is a data frame but R say it is list:
>>
>> SEXP Julia_R_MD_NA_DataFrame(jl_value_t* Var)
>> {
>> SEXP ans,names,rownames;
>> char evalcmd[4096];
>> int i;
>> const char* dfname="DataFrameName0tmp";
>> jl_set_global(jl_main_module, jl_symbol(dfname), (jl_value_t*)Var);
>> //Get Frame cols
>> sprintf(evalcmd,"size(%s,2)",dfname);
>> jl_value_t* cols=jl_eval_string(evalcmd);
>> int collen=jl_unbox_long(cols);
>> jl_value_t* eachcolvector;
>> //Create VECSXP
>>
>> //Create SEXP for Each Column and assign
>> PROTECT(ans=allocVector(VECSXP,collen));
>> for (i=0;i> {
>> sprintf(evalcmd,"%s[%d]",dfname,i+1);
>> eachcolvector=jl_eval_string(evalcmd);
>> SET_VECTOR_ELT(ans,i,Julia_R_MD_NA(eachcolvector));
>> }
>> //set names attribute
>> sprintf(evalcmd,"names(%s)",dfname);
>> jl_value_t* ret=jl_eval_string(evalcmd);
>> jl_value_t* onesymbol;
>> if (jl_is_array(ret))
>> {
>> PROTECT(names=allocVector(STRSXP,collen));
>> for (i=0;i> {
>> onesymbol=jl_arrayref((jl_array_t*)ret,i);
>> if (jl_is_symbol(onesymbol))
>>SET_STRING_ELT(names,i,mkChar(((jl_sym_t*)onesymbol)->name));
>> }
>> setAttrib(ans,R_NamesSymbol,names);
>> UNPROTECT(1);
>> }
>> //set row names
>> sprintf(evalcmd,"size(%s,1)",dfname);
>> jl_value_t* rows=jl_eval_string(evalcmd);
>> int rowlen=jl_unbox_long(rows);
>> PROTECT(rownames=allocVector(INTSXP,rowlen));
>> for (i=0;i> INTEGER(rownames)[i]=i+1;
>> setAttrib(ans,R_RowNamesSymbol,rownames);
>> UNPROTECT(1);
>> //set class as data frame
>> setAttrib(ans,R_ClassSymbol,mkString("data.frame"));
>> UNPROTECT(1);
>> return ans;
>> }
>
> __
> 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] Unfixed bugs in latest R-patched
> Radford Neal
> on Mon, 23 Jun 2014 11:24:35 -0400 writes:
> A new version of pqR is now available at pqR-project.org, which fixes
> several bugs that are also present in the latest R Core patch release
> (r66002). A number of bugs found previously during pqR development
> are also unfixed in the latest R Core release. Here is the list of
> these bugs that are unfixed in r66002 (including documentation
> deficiencies), taken from the pqR bug fix and documentation update
> sections of the pqR NEWS file (pqR-project.org/NEWS.txt):
Duncan Murdoch has already mentioned that "unfixed bugs" is a
strong wording...
I'm commenting on one subtopic only:
[.]
> o Fixed the following bug (also present in R-2.15.0 and R-3.0.2):
> x <- t(5)
> print (x %*% c(3,4))
> print (crossprod(5,c(3,4)))
> The call of crossprod produced an error, whereas the
> corresponding use of %*% does not.
> In pqR-2013-12-29, this bug also affected the expression t(5) %*%
> c(3,4), since it is converted to the equivalent of
> crossprod(5,c(3,4)).
(I'm not getting this last para... but that may be unimportant)
[]
> o Fixed the following bug (also present in R-2.15.0 and R-3.0.2):
> v <- c(1,2)
> m <- matrix(c(3,4),1,2)
> print(t(m)%*%v)
> print(crossprod(m,v))
> in which crossprod gave an error rather than produce the answer
> for the corresponding use of %*%.
Both cases above concern %*%, crossprod() {and also
tcrossprod()}, and always when one at least one operand is a
vector...
As S and R's terminology has always been mathematically correct and
"knows" that a vector is not a 1-row matrix or 1-column matrix
(which some people call row-vector and column-vector), R has
indeed much more freedom to be lenient in how to promote vectors
to matrices, and it has always done so tolerantly for some cases
of "%*%", but even there is room for discussion, see below.
Since about January, I have a corresponding entry in the TODO
file of the Matrix package (which I maintain), and I (at least
partly) agree with you, that we should *consider* changing the
current behavior. The following is from my corresponding R
script :
### NOTA BENE: vector %*% Matrix _and_ Matrix %*% vector :
### - - -
## The k-vector is treated as (1,k)-matrix *or* (k,1)-matrix
## on both sides whenever it "helps fit" the matrix dimensions:
and one kind of reasoning would go to say that
crossprod() and tcrossprod() should do the same. This would
even make more cases work than (I think) your proposal.
However, one can argue that the current behavior is quite
consistent {there is more than one kind of consistency here; in
this case it's the consistency of underlying C code IIRC}, and
not strictly a bug.
It is something which I am grateful you bring up for discussion,
and I'm happy to settle here.
Note that the Matrix package and many other packages that
implement matrix multiplication methods, should then also follow
the new semantic, and so this is typically rather for R-devel
than R-patched.
Note that from your first case example, one could also argue
-- at least from my 'NOTA BENE' rule above --
that5 %*% 3:4
should work, since
5 %*% rbind(3:4)
does work, but
5 %*% cbind(3:4)
does not. So you see, there are quite a few cases one could
discuss, and have reasons pro and contra some of the changes.
I will be too busy till the end of 'useR! 2014' and would want
quite a bit of further thoughts before making a quick decision,
notably about the cases I have in the appended products.Rout
Martin Maechler,
(ETH Zurich and R Core team)
---
### NOTA BENE: vector %*% Matrix _and_ Matrix %*% vector :
### - - -
## The k-vector is treated as (1,k)-matrix *or* (k,1)-matrix
## on both sides whenever it "helps fit" the matrix dimensions:
## --- %*% -
## - v . v -
## We *could* consider allowing more even here: could argue
## from the 'NOTA BENE' above that
> 5 %*% 3:4## should work, since
> 5 %*% rbind(3:4) ## does work, but
> 5 %*% cbind(3:4) ## does not.
## - v . M -
> 1:3 %*% matrix(1:12, 3,4) ## (1, n) if n == nrow(.)
[,1] [,2] [,3] [,4]
[1,] 14 32 50 68
> 1:4 %*% matrix(1:12, 3,4)
Error in 1:4 %*% matrix(1:12, 3, 4) : non-conformable arguments
No suitable frames for recover()
> 1:4 %*% matrix(1:5, 1,5) ## (n, 1) if nrow(.) == 1
[,1] [,2] [,3] [,4] [,5]
[1,]12345
[2,]2468 10
[3,]369 12 15
[4,]48 12 16 20
## - M . v -
> matrix(1:4, 3,4) %*% 1:4 ## (n, 1) if n == ncol(.)
[,1]
[1,] 26
[2,] 28
[3,] 26
> matrix(1:4, 3
Re: [Rd] using C code to create data frame but always return as list
Le 24 juin 2014 à 14:58, Simon Urbanek a écrit : > On Jun 24, 2014, at 9:21 AM, Romain Francois wrote: > >> Hi, >> >> Can you give us what str on the returned object gives you? >> >> I think you need : >> >> SET_OBJECT(and, 1) ; >> >> at the end. >> > > SET_OBJECT should not be used by user code in normal circumstances, it is set > by R automatically as part of the handling of the "class" attribute. Ah ok, thanks. I vaguely recall that I had to use it at some point, perhaps in conjunction with a direct SET_ATTRIB call, but I guess I’m not supposed to use this either. Romain __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] mismatch warning in documentation
Hi all, I received a request from the R maintainers (kurt Hornik) to fix some problems arising in r-devel with my package mvmeta. Basically, the check returns a series of warnings about a mismatch in the documentation of some data sets between the code and the docs. See the results at: http://cran.r-project.org/web/checks/check_results_mvmeta.html The problem might be that I grouped the variables in lists separated by commas, as many of them are simply variances or covariances of the same matrix. A fix could be to create individual entries, but this would extend the documentation substantially and would create a less readable help pages. Does anyone have a solution? Please let me know. Best -Antonio Gasparrini Antonio Gasparrini, PhD Lecturer in Biostatistics and Epidemiology London School of Hygiene & Tropical Medicine Keppel Street, London WC1E 7HT, UK Office: 0044 (0)20 79272406 Mobile: 0044 (0)79 64925523 Skype contact: a.gasparrini http://www.ag-myresearch.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Unfixed bugs in latest R-patched
On 24/06/2014, 1:40 PM, Radford Neal wrote: > On Tue, Jun 24, 2014 at 09:20:30AM +0200, Duncan Murdoch wrote: >> It's hardly fair to call these "unfixed bugs". Most of them are better >> described as "unreported bugs", or, after this posting, "bugs reported >> with insufficient detail". We can't fix them if we don't know what they >> are, and it's not easy to determine that for most of the items below. > > I think most of them are pretty clear. For the ones referring to lack > of protection or argument error checking code, I suggesting doing a > "diff" on the source files to find where I made changes. > > If your complaint is that your time is more valuable than my time, so > I should be producing a nice patch for you, then I don't agree. I went > to the effort of verifing that the bugs are still present in r66002. > That's as much as I'm willing to do. It's up to you what you do. No, I don't think it's reasonable to expect you to write a patch, but reporting the bugs in the R bug reporting system isn't that hard to do, and does lead to fixes pretty rapidly in cases where the report contains sample code to reproduce the problem. I don't know if pqR has a similar bug reporting system, but if it does, a reference to a report there would also be fine. But something like "Fixed a problem in R_AllocStringBuffer that could result in a crash due to an invalid memory access" sounds serious, but is just too vague to follow up. I would expect that doing a diff on the source files is going to find all sorts of stuff: pqR isn't just R with bugs fixed, it has a lot of other changes too. I can understand that from your point of view saying "R has bugs that have been fixed in pqR" is a form of advertising, but it would be more helpful to the community if the bugs actually got fixed. I think all of the bugs that you reported last June got fixed within a couple of weeks (though not all of the speedups were incorporated). Why not report them more frequently than annually, and give the details you already have so they are easier to fix? Duncan Murdoch > >Radford Neal > > >> On 23/06/2014, 5:24 PM, Radford Neal wrote: >>> A new version of pqR is now available at pqR-project.org, which fixes >>> several bugs that are also present in the latest R Core patch release >>> (r66002). A number of bugs found previously during pqR development >>> are also unfixed in the latest R Core release. Here is the list of >>> these bugs that are unfixed in r66002 (including documentation >>> deficiencies), taken from the pqR bug fix and documentation update >>> sections of the pqR NEWS file (pqR-project.org/NEWS.txt): >>> >>> o The documentation for c now says how the names for the result are >>> determined, including previously missing information on the >>> use.names argument, and on the role of the names of arguments in >>> the call of c. This documentation is missing in R-2.15.0 and >>> R-3.1.0. >>> >>> o The documentaton for diag now documents that a diagonal matrix is >>> always created with type double or complex, and that the names of >>> an extracted diagonal vector are taken from a names attribute (if >>> present), if not from the row and column names. This information >>> is absent in the documentation in R-2.15.1 and R-3.1.0. >>> >>> o Incorrect information regarding the pointer protection stack was >>> removed from help(Memory). This incorrect information is present >>> in R-2.15.0 and R-3.1.0 as well. >>> >>> o There is now information in help(Arithmetic) regarding what >>> happens when the operands of an arithmetic operation are NA or >>> NaN, including the arbitrary nature of the result when one >>> operand is NA and the other is NaN. There is no discussion of >>> this issue in the documentation for R-2.15.0 and R-3.1.0. >>> >>> o Fixed lack of protection bugs in the equal and greater functions >>> in sort.c. These bugs are also present in R-2.15.0 and R-3.1.0. >>> >>> o Fixed lack of protection bugs in the D function in deriv.c. >>> These bugs are also present in R-2.15.0 and R-3.1.0. >>> >>> o Fixed argument error-checking bugs in getGraphicsEventEnv and >>> setGraphicsEventEnv (also present in R-2.15.0 and R-3.1.0). >>> >>> o Fixed the following bug (also present in R-2.15.0 and R-3.0.2): >>> >>> x <- t(5) >>> print (x %*% c(3,4)) >>> print (crossprod(5,c(3,4))) >>> >>> The call of crossprod produced an error, whereas the >>> corresponding use of %*% does not. >>> >>> In pqR-2013-12-29, this bug also affected the expression t(5) %*% >>> c(3,4), since it is converted to the equivalent of >>> crossprod(5,c(3,4)). >>> >>> o Fixed a problem in R_AllocStringBuffer that could result in a >>> crash due to an invalid memory access. (This bug is also present >>> in R-2.15.0 and R-3.0.2.)
Re: [Rd] Curious behavior of $ and lapply
Kevin,
Thanks for the explanation. Based on your analysis, I tried to reproduce
the problem without lapply, and sure enough:
(function(x,y) "$"(x,y)) (list(a=2),"a") => NULL
(function(x,...) "$"(x,...)) (list(a=2),"a") => NULL
although
"$"(list(a=2),"a") => 2
Looking for even simpler examples, I found
"$"(list(a=2),("a")) => ERROR invalid subscript type 'language'
"$"(list(a=2),`a`) => 2
So the real issue is that "$" does not evaluate its second argument. Which
makes perfect sense, but ought to be documented in the man page for $
(base::Extract).
Also, I'd think that $ should be giving an error in these cases:
"$"(list(a=2,b=4),...) => NULL
"$"(list(a=2,b=4),) => NULL
"$"(list(a=2),) => 2# strange...
âas it does for other illegal arguments:
ââ
"$"(list(a=2,b=4),2)
ââ =>
Error in list(a = 2, b = 4)$2 : invalid subscript type 'double'
"$"(list(a=2,b=4),2L)
â =>
Error in list(a = 2, b = 4)$2L : invalid subscript type 'integer'
"$"(list(a=2,b=4),c())
â =>
Error in list(a = 2, b = 4)$c() : invalid subscript type 'language'
"$"(list(a=2,b=4),TRUE)
â =>
Error in list(a = 2, b = 4)$TRUE : invalid subscript type 'logical'
-s
On Tue, Jun 24, 2014 at 2:28 AM, Kevin Ushey wrote:
> `lapply` basically takes its call and massages into calls of the following
> form:
>
> FUN(X[[1L]], ...)
> FUN(X[[2L]], ...)
> ...
>
> that get evaluated in the appropriate environment.
>
> For `lapply(list(list(a=3,b=4)),"$","b")`, you can imagine that a
> function `FUN` of the form:
>
> FUN <- function(x, ...) "$"(x, ...)
>
> is being generated, and then evaluated as
>
> FUN(list(list(a=3, b=4))[[1L]], "b") ## returns NULL
>
> and I can only guess that the non-standard evaluation of `$` is not
> interpreting `...` as you expect.
>
> Moral of the story -- lapply does non-standard evaluation, and does
> not compose nicely with other functions performing non-standard
> evaluation. This is discussed a bit in the Note: section of `?lapply`.
> Copied from there (emphasis mine):
>
> For historical reasons, the calls created by lapply are unevaluated,
> and code has been written (e.g. bquote) that relies on this. This
> means that the recorded call is always of the form FUN(X[[i]], ...),
> with i replaced by the current (integer or double) index. This is not
> normally a problem, but it can be if FUN uses sys.call or match.call
> or if it __is a primitive function that makes use of the call__. This
> means that it is often safer to call primitive functions with a
> wrapper, so that e.g. lapply(ll, function(x) is.numeric(x)) is
> required to ensure that method dispatch for is.numeric occurs
> correctly.
>
> Cheers,
> Kevin
>
>
> On Mon, Jun 23, 2014 at 3:04 PM, Stavros Macrakis (ΣÏαῦÏοÏ
> ÎακÏάκηÏ)
> wrote:
> > There seems to be a funny interaction between lapply and "$" -- also, "$"
> > doesn't signal an error in some cases where "[[" does.
> >
> > The $ operator accepts a string second argument in functional form:
> >
> >> `$`(list(a=3,b=4),"b")
> > [1] 4
> >
> > lapply(list(list(a=3,b=4)),function(x) `$`(x,"b"))
> > [[1]]
> > [1] 4
> >
> > ... but using an lapply "..." argument, this returns NULL:
> >
> >> lapply(list(list(a=3,b=4)),"$","b")
> > [[1]]
> > NULL
> >
> > Equally strangely, a symbol is an error in functional form:
> >
> >> `$`(list(a=3,b=4),quote(`b`))
> > Error in list(a = 3, b = 4)$quote(b) : invalid subscript type 'language'
> >
> > ... but not an error in lapply, where it returns NULL:
> >
> >> lapply(list(list(a=3,b=4)),`$`,quote(`b`))
> > [[1]]
> > NULL
> >
> > I wonder if lapply is failing to pass the second argument to $ correctly,
> > since $ with various unreasonable second arguments returns NULL
> (shouldn't
> > it given an error?):
> >
> > "$"(list(list(a=3,b=4)),) => NULL
> > lapply(list(list(a=3,b=4)),`$`,function(i)i) => NULL
> >
> > Compare
> >
> > "[["(list(list(a=3,b=4)),) => <>
> >
> > But with [[, lapply correctly gives an error:
> >
> > lapply(list(list(a=3,b=4)),`[[`,function(i)i) => <>
> >
> > [[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] Unfixed bugs in latest R-patched
> Duncan Murdoch: > > No, I don't think it's reasonable to expect you to write a patch, but > reporting the bugs in the R bug reporting system isn't that hard to do, > and does lead to fixes pretty rapidly in cases where the report contains > sample code to reproduce the problem. Sometimes. Sometimes not. For instance, PR #14985, a significant set of bugs, with an easy fix (patch provided), which took almost two years to make it to an R Core release - perhaps because you were more interested in trying to argue that they weren't really bugs at all... > "Fixed a problem in R_AllocStringBuffer that could result in a crash due > to an invalid memory access" sounds serious, but is just too vague to > follow up. I would expect that doing a diff on the source files is > going to find all sorts of stuff: pqR isn't just R with bugs fixed, it > has a lot of other changes too. You might expect that if it was really that difficult, I would have given more detail. I think if you actually looked at this procedure, which is about 30 lines long, you might, seeing as you've been warned that it has a bug, find the problem in about 30 seconds, even without looking at the pqR source code, which of course isn't difficult to do. > it would be more > helpful to the community if the bugs actually got fixed. Indeed. > I think all of > the bugs that you reported last June got fixed within a couple of weeks Actually, the last six in the list I just posted are from the original pqR release last June. Some of the six don't seem too crucial, but two of them seem reasonably serious (one leads to R crashing). > Why not report them > more frequently than annually, and give the details you already have so > they are easier to fix? I did report at least one bug not long ago (which got fixed), after seeing (as now) that an R Core release was imminent, and therefore thinking it would be best if a fix was put in before it went out. You're of course welcome to look at the NEWS file at pqR-project.org whenever you like. Radford Neal __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Unfixed bugs in latest R-patched
> > o Fixed the following bug (also present in R-2.15.0 and R-3.0.2):
>
> > x <- t(5)
> > print (x %*% c(3,4))
> > print (crossprod(5,c(3,4)))
>
> > The call of crossprod produced an error, whereas the
> > corresponding use of %*% does not.
>
> > o Fixed the following bug (also present in R-2.15.0 and R-3.0.2):
>
> > v <- c(1,2)
> > m <- matrix(c(3,4),1,2)
> > print(t(m)%*%v)
> > print(crossprod(m,v))
>
> > in which crossprod gave an error rather than produce the answer
> > for the corresponding use of %*%.
> As S and R's terminology has always been mathematically correct and
> "knows" that a vector is not a 1-row matrix or 1-column matrix
> (which some people call row-vector and column-vector), R has
> indeed much more freedom to be lenient in how to promote vectors
> to matrices, and it has always done so tolerantly for some cases
> of "%*%", but even there is room for discussion, see below.
> However, one can argue that the current behavior is quite
> consistent {there is more than one kind of consistency here; in
> this case it's the consistency of underlying C code IIRC}, and
> not strictly a bug.
If you look at help(crossprod), you'll see that it says that
crossprod(x,y) is equivalent to t(x) %*% y. But it's not, since
the latter works in some cases where the former gives an error.
So it's a bug.
Furthermore, crossprod(x,y) ought to be equivalent to t(x) %*% y,
even in cases where a vector needs to get promoted to a matrix,
because such cases can arise from inadvertant dropping of dimensions
when subscriptiong a matrix (eg, with 1:n, with n happening to be 1).
Sometimes, this problem gets fixed by the transpose.
Radford Neal
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] operation on ‘numsels’ may be undefined
Hi Kevin,
On 06/23/2014 10:28 PM, Kevin Ushey wrote:
I don't see what's so surprising here.
That statement is identical to writing:
if (arrMask[i] == 1) {
numsels = ++numsels;
} else {
numsels = numsels;
}
and
numsels = ++numsels;
has two statements modifying the value of numsels (= and prefix-++) in
a single sequence point. (Do we increment then assign, or assign then
increment? The C / C++ standards leave this undefined.)
Imagine writing the operations out as functions: we have the `=`
function, and the `prefix-++` function -- both of these 'mo dify' (one
of) their arguments. Do we evaluate it as `=`(a, `prefix-++`(a)) or
`prefix-++`(`=`(a, a))?
As the former? Isn't it that `prefix-++` has precedence over `=`? Also
according to the standard, `prefix-++` must perform the increment
*before* returning the incremented value. So I'm still a little bit
confused about this warning. Although I would understand it if
`suffix-++` was used instead of `prefix-++`:
numsels = numsels++;
In that case the incrementation happens *after* the right value
of the assignment is evaluated but it's undefined whether it will
happen before or after the assignment itself (on my machine it
happens after).
The C standard leaves this undefined, so
compilers are free to do what they wish (and the nice ones warn you
when there is such an ambiguity). I guess the net result of the
operation is the same in each case _here_, but this is of course not
the case for other functions that modify the value of their
operand(s). And, in truth, this is _undefined behaviour_ and so the
compiler could still rightly make demons fly out of your nose if it
wanted to upon program execution.
I highly recommend reading the slides at
http://www.slideshare.net/olvemaudal/deep-c, especially the bit on
sequence points.
Nice slides. Pretty entertaining! The numsels = numsels++ case is
actually discussed at slide 142. Thanks for the link!
H.
Cheers,
Kevin
On Mon, Jun 23, 2014 at 9:22 PM, Kasper Daniel Hansen
wrote:
I am not an expert on this, but I note that the section on -Wsequence-point
at
http://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html
specifically mentions ? and :. Perhaps some more work on tracking down
their definitions and precedence might lead to insights.
Best,
Kasper
On Mon, Jun 23, 2014 at 6:42 PM, Hervé Pagès wrote:
On 06/23/2014 03:18 PM, Hervé Pagès wrote:
Hi Christian,
On 06/23/2014 11:54 AM, cstrato wrote:
Dear Romain,
I do not know enough about compilers, but as far as I remember, they
'work' from right to left,
Not necessarily. So you should not rely on that. This is what the
(somewhat obscure) warning you see on zin1 is trying to tell you.
Actually, I don't see an ambiguity in your code:
numsels = (arrMask[i] == 1) ? ++numsels : numsels;
Yes it's confusing and unnecessarily complicated but I don't see that
it relies on some undefined behavior. It's not like in the thread on
Bioc-devel where the expression was:
*p++ = tolower(*p);
In that case the left-value of the assignment is itself an expression
that needs to be evaluated and the outcome of the assignment depends
on whether the left-value is evaluated before the right expression or
not. But in your case the left-value is a variable name so there is
nothing to evaluate.
So I don't know. Looks like a false positive from the gcc compiler to
me. Someone on the list might have a better insight.
Cheers,
H.
Personally I would just do:
if (arrMask[i] == 1) numsels++;
which is the standard way to implement the "if (some condition)
then increment counter" idiom.
As Kasper mentioned, a similar issue was recently discussed here:
https://stat.ethz.ch/pipermail/bioc-devel/2014-June/005858.html
Cheers,
H.
so numsels = ++numsels should not confuse the
compiler. Anyhow I will change my code to your first suggestion since it
is more elegant.
Best regards,
Christian
On 6/23/14 7:13 PM, Romain François wrote:
Le 23 juin 2014 à 18:28, cstrato a écrit :
Dear Romain,
Thank you for your suggestions, I like especially the first one.
However, you did not explain why I have never got this warning
message on any compiler, and why only one of the two identical Ubuntu
compilers did give this warning message?
Best regards,
Christian
I don’t know, but this:
numsels = ++numsels ;
seems fishy to me, and so it keeps feeling weird with the addition of
the ternary operator.
There is obviously a difference of setup between these two machines,
but I don’t have time to sherlock that for you. One of the compilers
is getting more careful than the other. Getting warnings you did not
get before is a good thing, as it helps you update the code with that
new insight.
Welcome to my world, I’m sometimes thrown all kinds of new warnings
from esoteric compilers, all of them have value .
Romain
On 6/23/14 3:45 PM, Romain François wrote:
Le 23 juin 2014 à 15:20, cstrato a écrit
[Rd] debug()/trace() to standard error?
Does anyone know of a simple/neat way to make debug() and/or trace() send output to the standard error stream (not standard output)? Thanks, Henrik __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Unfixed bugs in latest R-patched
On 24/06/2014, 10:26 PM, Radford Neal wrote: >> Duncan Murdoch: >> >> No, I don't think it's reasonable to expect you to write a patch, but >> reporting the bugs in the R bug reporting system isn't that hard to do, >> and does lead to fixes pretty rapidly in cases where the report contains >> sample code to reproduce the problem. > > Sometimes. Sometimes not. For instance, PR #14985, a significant set > of bugs, with an easy fix (patch provided), which took almost two > years to make it to an R Core release - perhaps because you were more > interested in trying to argue that they weren't really bugs at all... I've just re-read that thread (and I'd invite anyone else to do so, it's at https://bugs.r-project.org/bugzilla/show_bug.cgi?id=14985), and I don't think that's a completely fair characterization of it. That was a case where problems did sit around for about a year before being dealt with, but since it was a change to the interface that could affect third party front-ends, I didn't put it into R-patched right away, which means it waited most of another year before making it into a release. > >> "Fixed a problem in R_AllocStringBuffer that could result in a crash due >> to an invalid memory access" sounds serious, but is just too vague to >> follow up. I would expect that doing a diff on the source files is >> going to find all sorts of stuff: pqR isn't just R with bugs fixed, it >> has a lot of other changes too. > > You might expect that if it was really that difficult, I would have > given more detail. I think if you actually looked at this procedure, > which is about 30 lines long, you might, seeing as you've been warned > that it has a bug, find the problem in about 30 seconds, even without > looking at the pqR source code, which of course isn't difficult to do. I think it's fixed now. > >> it would be more >> helpful to the community if the bugs actually got fixed. > > Indeed. > >> I think all of >> the bugs that you reported last June got fixed within a couple of weeks > > Actually, the last six in the list I just posted are from the original > pqR release last June. Some of the six don't seem too crucial, but > two of them seem reasonably serious (one leads to R crashing). I imagine the reason they weren't dealt with was because we mistakenly thought they had been. Duncan Murdoch > >> Why not report them >> more frequently than annually, and give the details you already have so >> they are easier to fix? > > I did report at least one bug not long ago (which got fixed), after > seeing (as now) that an R Core release was imminent, and therefore > thinking it would be best if a fix was put in before it went out. > > You're of course welcome to look at the NEWS file at pqR-project.org > whenever you like. > >Radford Neal > __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] operation on ‘numsels’ may be undefined
Hi Hervé,
Glad you enjoyed the slides :)
Here's a bit more material discussing why 'i = ++i' and friends are
actually defined under the C++11 standard, but undefined before:
Why it might be well-defined in C++0x and above:
http://stackoverflow.com/questions/3852768/unsequenced-value-computations-a-k-a-sequence-points
Why i = i++ is undefined, and i = ++i is defined, for C++0x and above:
http://stackoverflow.com/questions/17400137/order-of-evaluation-and-undefined-behaviour
http://stackoverflow.com/questions/3690141/multiple-preincrement-operations-on-a-variable-in-cc/3691469#3691469
I would imagine this would translate into a similar undefined-ness for the
C standards, but would not be surprised if I were wrong... IIUC, though,
using the rules that
1. A variable may only be modified once between two sequence points, and
2. 'i = ++i' modifies 'i' twice without a sequence point to separate
them
means it's undefined there. IIUC (and I may not), precedence doesn't even
play in here -- if we modify a variable twice between two sequence points,
we have UB.
Anyway, I think I've gone too far down the rabbit hole into the language
lawyer land of C/C++ standards, so let's all just agree that, regardless of
what the correct interpretation is, 'i = i++' and 'i = ++i' are just things
you shouldn't write :)
Cheers,
Kevin
On Tue, Jun 24, 2014 at 3:38 PM, Hervé Pagès wrote:
> Hi Kevin,
>
>
> On 06/23/2014 10:28 PM, Kevin Ushey wrote:
>
>> I don't see what's so surprising here.
>>
>> That statement is identical to writing:
>>
>> if (arrMask[i] == 1) {
>> numsels = ++numsels;
>> } else {
>> numsels = numsels;
>> }
>>
>> and
>>
>> numsels = ++numsels;
>>
>> has two statements modifying the value of numsels (= and prefix-++) in
>> a single sequence point. (Do we increment then assign, or assign then
>> increment? The C / C++ standards leave this undefined.)
>>
>> Imagine writing the operations out as functions: we have the `=`
>> function, and the `prefix-++` function -- both of these 'mo dify' (one
>>
>> of) their arguments. Do we evaluate it as `=`(a, `prefix-++`(a)) or
>> `prefix-++`(`=`(a, a))?
>>
>
> As the former? Isn't it that `prefix-++` has precedence over `=`? Also
> according to the standard, `prefix-++` must perform the increment
> *before* returning the incremented value. So I'm still a little bit
> confused about this warning. Although I would understand it if
> `suffix-++` was used instead of `prefix-++`:
>
> numsels = numsels++;
>
> In that case the incrementation happens *after* the right value
> of the assignment is evaluated but it's undefined whether it will
> happen before or after the assignment itself (on my machine it
> happens after).
>
>
> The C standard leaves this undefined, so
>> compilers are free to do what they wish (and the nice ones warn you
>> when there is such an ambiguity). I guess the net result of the
>> operation is the same in each case _here_, but this is of course not
>> the case for other functions that modify the value of their
>> operand(s). And, in truth, this is _undefined behaviour_ and so the
>> compiler could still rightly make demons fly out of your nose if it
>> wanted to upon program execution.
>>
>> I highly recommend reading the slides at
>> http://www.slideshare.net/olvemaudal/deep-c, especially the bit on
>> sequence points.
>>
>
> Nice slides. Pretty entertaining! The numsels = numsels++ case is
> actually discussed at slide 142. Thanks for the link!
>
>
> H.
>
>
>> Cheers,
>> Kevin
>>
>> On Mon, Jun 23, 2014 at 9:22 PM, Kasper Daniel Hansen
>> wrote:
>>
>>> I am not an expert on this, but I note that the section on
>>> -Wsequence-point
>>> at
>>>http://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html
>>> specifically mentions ? and :. Perhaps some more work on tracking down
>>> their definitions and precedence might lead to insights.
>>>
>>> Best,
>>> Kasper
>>>
>>>
>>> On Mon, Jun 23, 2014 at 6:42 PM, Hervé Pagès wrote:
>>>
>>> On 06/23/2014 03:18 PM, Hervé Pagès wrote:
Hi Christian,
>
> On 06/23/2014 11:54 AM, cstrato wrote:
>
> Dear Romain,
>>
>> I do not know enough about compilers, but as far as I remember, they
>> 'work' from right to left,
>>
>>
> Not necessarily. So you should not rely on that. This is what the
> (somewhat obscure) warning you see on zin1 is trying to tell you.
>
>
Actually, I don't see an ambiguity in your code:
numsels = (arrMask[i] == 1) ? ++numsels : numsels;
Yes it's confusing and unnecessarily complicated but I don't see that
it relies on some undefined behavior. It's not like in the thread on
Bioc-devel where the expression was:
*p++ = tolower(*p);
In that case the left-value of the assignment is itself an expression
that needs to be evaluated and the outcome of the assignment depends
on whether the left-value
