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-comput
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
>> sampl
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
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 mod
> > 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 fol
> 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. Somet
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 example
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
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://
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
> 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
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 a
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 = {++numse
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
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_valu
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 Murdo
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;
cha
17 matches
Mail list logo
