Re: [Rd] Inconsistencies in wilcox.test

[Karolis Koncevičius]

So I tried adding Infinity support for all cases.
And it is (as could be expected) more complicated than I thought.

It is easy to add Inf support for the test. The problems start with 
conf.int=TRUE.

Currently confidence intervals are computed via `uniroot()` and, in the 
case of infinities, we are computationally looking for roots over 
infinite interval which results in an error. I suspect this is the 
reason Inf values were removed in the first place.


Just a note, I found a few more errors/inconsistencies when requesting 
confidence intervals with paired=TRUE (due to Infinities being left in).


Current error in Inf-Inf scenario:

wilcox.test(c(1,2,Inf), c(4,8,Inf), paired=TRUE, conf.int=TRUE)
  Error in if (ZEROES) x <- x[x != 0] :
missing value where TRUE/FALSE needed



NaN confidence intervals:

wilcox.test(c(1:9,Inf), c(21:28,Inf,30), paired=TRUE, conf.int=TRUE)

  Wilcoxon signed rank test with continuity correction

  data:  c(1:9, Inf) and c(21:28, Inf, 30)
  V = 9.5, p-value = 0.0586
  alternative hypothesis: true location shift is not equal to 0
  0 percent confidence interval:
   NaN NaN
   sample estimates:
   midrange
NaN


The easiest "fix" for consistency would be to simply remove Infinity 
support from the paired=TRUE case.


But going with the more desirable approach of adding Infinity support 
for non-paired cases - it is currently not clear to me what confidence 
intervals and pseudomedian should be. Specially when Infinities are on 
both sides.


Regards,
Karolis Koncevičius.


On 2019-12-07 23:18, Karolis Koncevičius wrote:
Thank you for a fast response. Nice to see this mailing list being so 
alive.


Regarding Inf issue: I agree with your assessment that Inf should not 
be removed. The code gave me an impression that Inf values were 
intentionally removed (since is.finite() was used everywhere, except 
for paired case). I will try to adjust my patch according to your 
feedback.


One more thing: it seems like you assumed that issues 2:4 are all 
related to machine precision, which is not the case - only 2nd issue 
is.
Just wanted to draw this to your attention, in case you might have 
some feedback and guidelines about issues 3 and 4 as well.




On 2019-12-07 21:59, Martin Maechler wrote:

Karolis Koncevičius
   on Sat, 7 Dec 2019 20:55:36 +0200 writes:


  > Hello,
  > Writing to share some things I've found about wilcox.test() that seem a
  > a bit inconsistent.

  > 1. Inf values are not removed if paired=TRUE

  > # returns different results (Inf is removed):
  > wilcox.test(c(1,2,3,4), c(0,9,8,7))
  > wilcox.test(c(1,2,3,4), c(0,9,8,Inf))

  > # returns the same result (Inf is left as value with highest rank):
  > wilcox.test(c(1,2,3,4), c(0,9,8,7), paired=TRUE)
  > wilcox.test(c(1,2,3,4), c(0,9,8,Inf), paired=TRUE)

Now which of the two cases do you consider correct ?

IHMO, the 2nd one is correct: it is exactly one property of the
*robustness* of the wilcoxon test and very desirable that any
(positive) outlier is treated the same as just "the largest
value" and the test statistic (and hence the p-value) should not
change.

So I think the first case is wrong, notably if modified, (such
that the last  y  is the overall maximal value (slightly larger sample):


wilcox.test(1:7, 1/8+ c(9:4, 12))


Wilcoxon rank sum test

data:  1:7 and 1/8 + c(9:4, 12)
W = 6, p-value = 0.01748
alternative hypothesis: true location shift is not equal to 0


wilcox.test(1:7, 1/8+ c(9:4, 1))


Wilcoxon rank sum test

data:  1:7 and 1/8 + c(9:4, 1)
W = 6, p-value = 0.01748
alternative hypothesis: true location shift is not equal to 0


wilcox.test(1:7, 1/8+ c(9:4, Inf))


Wilcoxon rank sum test

data:  1:7 and 1/8 + c(9:4, Inf)
W = 6, p-value = 0.03497
alternative hypothesis: true location shift is not equal to 0

The  Inf  case should definitely give the same as the  10'000 case.
That's exactly one property of a robust statistic.

Thank you, Karolis, this is pretty embarrassing to only be detected now after 
25+ years of R in use ...

The correct fix starts with replacing the  is.finite()  by   !is.na() and keep 
the 'Inf' in the rank computations...
(but then probably also deal with the case of more than one Inf, notably the  Inf - Inf  
"exception" which is not triggered by your example...)


---

Ben addressed the "rounding" / numerical issues unavoidable for
the other problems.

  > 2. tolerance issues with paired=TRUE.

  > wilcox.test(c(4, 3, 2), c(3, 2, 1), paired=TRUE)
  > # ...
  > # Warning:  cannot compute exact p-value with ties

  > wilcox.test(c(0.4,0.3,0.2), c(0.3,0.2,0.1), paired=TRUE)
  > # ...
  > # no warning

  > 3. Always 'x observations are missing' when paired=TRUE

  > wilcox.test(c(1,2), c(NA_integer_,NA_integer_), paired=TRUE)
  > # ...
  > # Error:  not enough (finite) 'x' observations

  > 4. No indication if normal approximation was used:

  > # different numbers, but same "method" name
  > wilcox.test(rnorm(10), exact=

Re: [Rd] long vector support

[Will L]

Thank you both. I really appreciate your work developing R, and it is
exciting that long vector support may be coming to writeBin(). Next time, I
will come prepared with svn revision numbers to help track things down.

On Sat, Dec 7, 2019 at 6:17 AM Martin Maechler 
wrote:

> > Will L
> > on Fri, 6 Dec 2019 16:02:59 -0500 writes:
>
> > All, At first glance, a recent commit to R-devel (
> >
> https://github.com/wch/r-source/commit/2c182014ecc8c2407a89092c9162d86046bd18da
> )
> > appears to be related to long vector support.
>
> yes, for a very limited case, with a very nice minimal
> reproducible example and proper R bug report, where the change
> was very simple indeed , PR#17665, i.e.
> https://bugs.r-project.org/bugzilla/show_bug.cgi?id=17665
>
> > But as
> > Henrik Bengtsson points out at
> >
> https://github.com/HenrikBengtsson/Wishlist-for-R/issues/97#issuecomment-562659134
> ,
> > writeBin() still prohibits long vectors. Are there any
> > plans to add long vector support to R 4.0.0?
>
> well.. there *is* a lot of long vector support in R 3.x.y
> already.
>
> Where there are gaps,
> 1) we have to be told about (i.e. it should be a case where
>people at least have stumbled about it) -- preferably with
>form PR in R's bugzilla,  see https://www.r-project.org/bugs.html
>
> 2) sometimes a fix takes quite a bit of time, and we would close
>the case much more quickly if people looked at the case in
>detail and found *how* to fix it.
>
>[For the Matrix package and the case of sparse matrices,
> I'd be very happy if a C-savvy R developer would start
> collaborating with me to get this (incl interface to SuiteSparse)]
>
> In the present case, it may be that a change does not take much
> effort; my first try seems to work already .. and may just a bit
> more safeguarding ..
>
> So thank you, Will, for the reminder!
>
> Martin Maechler
> ETH Zurich  and  R Core Team
>
>
> > x <- raw(2^31)
> > writeBin(x, con = nullfile())
> > # Error in writeBin(x, con = nullfile()) :
> > #  long vectors not supported yet: connections.c:4430
>
> > x <- raw(2^31)
> > con <- rawConnection(raw(0L), "w")
> > writeBin(raw(2^31), con = con)
> > # Error in writeBin(raw(2^31), con = con) :
> > #  long vectors not supported yet: connections.c:4430
>
>
> > Will
>
> > [[alternative HTML version deleted]]
>
> > __
> > R-devel@r-project.org mailing list
> > https://stat.ethz.ch/mailman/listinfo/r-devel
>


-- 
wlandau.github.io
linkedin.com/in/wlandau
github.com/wlandau

[[alternative HTML version deleted]]

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] Inconsistent behavior for the C AP's R_ParseVector() ?

[Tomas Kalibera]

On 12/9/19 2:54 PM, Laurent Gautier wrote:
>
>
> Le lun. 9 déc. 2019 à 05:43, Tomas Kalibera  > a écrit :
>
> On 12/7/19 10:32 PM, Laurent Gautier wrote:
>> Thanks for the quick response Tomas.
>>
>> The same error is indeed happening when trying to have a
>> zero-length variable name in an environment. The surprising bit
>> is then "why is this happening during parsing" (that is why are
>> variables assigned to an environment) ?
>
> The emitted R error (in the R console) is not a parse (syntax)
> error, but an error emitted during parsing when the parser tries
> to intern a name - look it up in a symbol table. Empty string is
> not allowed as a symbol name, and hence the error. In the call
> "list(''=1)" , the empty name is what could eventually become a
> name of a local variable inside list(), even though not yet during
> parsing.
>
>
> Thanks Tomas.
>
> I guess this has do with R expressions being lazily evaluated, and 
> names of arguments in a call are also part of the expression. Now the 
> puzzling part is why is that at all part of the parsing: I would have 
> expected R_ParseVector() to be restricted to parsing... Now it feels 
> like R_ParseVector() is performing parsing, and a first level of 
> evalution for expressions that "should never work" (the empty name).
Think of it as an exception in say Python. Some failures during parsing 
result in an exception (called error in R and implemented using a long 
jump). Any time you are calling into R you can get an error; out of 
memory is also signalled as R error.
>
> There is probably some error in how the external code is handling
> R errors  (Fatal error: unable to initialize the JIT, stack
> smashing, etc) and possibly also how R is initialized before
> calling ParseVector. Probably you would get the same problem when
> running say "stop('myerror')". Please note R errors are
> implemented as long-jumps, so care has to be taken when calling
> into R, Writing R Extensions has more details (and section 8
> specifically about embedding R). This is unlike parse (syntax)
> errors signaled via return value to ParseVector()
>
>
> The issue is that the segfault (because of stack smashing, therefore 
> because of what also suspected to be an incontrolled jump) is 
> happening within the execution of R_ParseVector(). I would think that 
> an issue with the initialization of R is less likely because the 
> project is otherwise used a fair bit and is well covered by automated 
> continuous tests.
>
> After looking more into R's gram.c I suspect that an execution context 
> is required for R_ParseVector() to know to properly work (know where 
> to jump in case of error) when the parsing code decides to fail 
> outside what it thinks is a syntax error. If the case, this would make 
> R_ParseVector() function well when called from say, a C-extension to 
> an R package, but fail the way I am seeing it fail when called from an 
> embedded R.

Yes, contexts are used internally to handle errors. For external use 
please see Writing R Extensions, section 6.12.

Best
Tomas

> Best,
>
> Laurent
>
> Best,
> Tomas
>
>>
>> We are otherwise aware that the error is not occurring in the R
>> console, but can be traced to a call to R_ParseVector() in R's C
>> 
>> API:(https://github.com/rpy2/rpy2/blob/master/rpy2/rinterface_lib/_rinterface_capi.py#L509).
>>
>> Our specific setup is calling an embedded R from Python, using
>> the cffi library. An error on end was the first possibility
>> considered, but the puzzling specificity of the error (as shown
>> below other parsing errors are handled properly) and the
>> difficulty tracing what is in happening in R_ParseVector() made
>> me ask whether someone on this list had a suggestion about the
>> possible issue"
>>
>> ```
>> >>>  import  rpy2.rinterface  as  ri
>> >>>  ri.initr()
>> >>>  e  =  ri.parse("list(''=1+")  
>> 
>> ---
>> RParsingError  Traceback  (most  recent  
>> call  last)>>> e = ri.parse("list(''=123") R[write to console]: Error:
>> attempt to use zero-length variable name R[write to console]:
>> Fatal error: unable to initialize the JIT *** stack smashing
>> detected ***:  terminated ```
>>
>> Le lun. 2 déc. 2019 à 06:37, Tomas Kalibera
>> mailto:tomas.kalib...@gmail.com>> a
>> écrit :
>>
>> Dear Laurent,
>>
>> could you please provide a complete reproducible example
>> where parsing
>> results in a crash of R? Calling parse(text="list(''=123")
>> from R works
>> fine for me (gives Error: attempt to use zero-length variable
>> name).
>>
>> I don't think the problem you observed could be related to
>> the memory
>> leak. The 

Re: [Rd] Inconsistent behavior for the C AP's R_ParseVector() ?

[Laurent Gautier]

Le lun. 9 déc. 2019 à 05:43, Tomas Kalibera  a
écrit :

> On 12/7/19 10:32 PM, Laurent Gautier wrote:
>
> Thanks for the quick response Tomas.
>
> The same error is indeed happening when trying to have a zero-length
> variable name in an environment. The surprising bit is then "why is this
> happening during parsing" (that is why are variables assigned to an
> environment) ?
>
> The emitted R error (in the R console) is not a parse (syntax) error, but
> an error emitted during parsing when the parser tries to intern a name -
> look it up in a symbol table. Empty string is not allowed as a symbol name,
> and hence the error. In the call "list(''=1)" , the empty name is what
> could eventually become a name of a local variable inside list(), even
> though not yet during parsing.
>

Thanks Tomas.

I guess this has do with R expressions being lazily evaluated, and names of
arguments in a call are also part of the expression. Now the puzzling part
is why is that at all part of the parsing: I would have expected
R_ParseVector() to be restricted to parsing... Now it feels like
R_ParseVector() is performing parsing, and a first level of evalution for
expressions that "should never work" (the empty name).

There is probably some error in how the external code is handling R errors
> (Fatal error: unable to initialize the JIT, stack smashing, etc) and
> possibly also how R is initialized before calling ParseVector. Probably you
> would get the same problem when running say "stop('myerror')". Please note
> R errors are implemented as long-jumps, so care has to be taken when
> calling into R, Writing R Extensions has more details (and section 8
> specifically about embedding R). This is unlike parse (syntax) errors
> signaled via return value to ParseVector()
>

The issue is that the segfault (because of stack smashing, therefore
because of what also suspected to be an incontrolled jump) is happening
within the execution of R_ParseVector(). I would think that an issue with
the initialization of R is less likely because the project is otherwise
used a fair bit and is well covered by automated continuous tests.

After looking more into R's gram.c I suspect that an execution context is
required for R_ParseVector() to know to properly work (know where to jump
in case of error) when the parsing code decides to fail outside what it
thinks is a syntax error. If the case, this would make R_ParseVector()
function well when called from say, a C-extension to an R package, but fail
the way I am seeing it fail when called from an embedded R.

Best,

Laurent

> Best,
> Tomas
>
>
> We are otherwise aware that the error is not occurring in the R console,
> but can be traced to a call to R_ParseVector() in R's C API:(
> https://github.com/rpy2/rpy2/blob/master/rpy2/rinterface_lib/_rinterface_capi.py#L509
> ).
>
> Our specific setup is calling an embedded R from Python, using the cffi
> library. An error on end was the first possibility considered, but the
> puzzling specificity of the error (as shown below other parsing errors are
> handled properly) and the difficulty tracing what is in happening in
> R_ParseVector() made me ask whether someone on this list had a suggestion
> about the possible issue"
>
> ```
>
> >>> import rpy2.rinterface as ri>>> ri.initr()>>> e = ri.parse("list(''=1+") 
> >>> ---RParsingError
> >>>  Traceback (most recent call last)>>> e = 
> >>> ri.parse("list(''=123") R[write to console]: Error: attempt to use 
> >>> zero-length variable name
> R[write to console]: Fatal error: unable to initialize the JIT
>
> *** stack smashing detected ***:  terminated
> ```
>
>
> Le lun. 2 déc. 2019 à 06:37, Tomas Kalibera  a
> écrit :
>
>> Dear Laurent,
>>
>> could you please provide a complete reproducible example where parsing
>> results in a crash of R? Calling parse(text="list(''=123") from R works
>> fine for me (gives Error: attempt to use zero-length variable name).
>>
>> I don't think the problem you observed could be related to the memory
>> leak. The leak is on the heap, not stack.
>>
>> Zero-length names of elements in a list are allowed. They are not the
>> same thing as zero-length variables in an environment. If you try to
>> convert "lst" from your example to an environment, you would get the
>> error (attempt to use zero-length variable name).
>>
>> Best
>> Tomas
>>
>>
>> On 11/30/19 11:55 PM, Laurent Gautier wrote:
>> > Hi again,
>> >
>> > Beside R_ParseVector()'s possible inconsistent behavior, R's handling of
>> > zero-length named elements does not seem consistent either:
>> >
>> > ```
>> >> lst <- list()
>> >> lst[[""]] <- 1
>> >> names(lst)
>> > [1] ""
>> >> list("" = 1)
>> > Error: attempt to use zero-length variable name
>> > ```
>> >
>> > Should the parser be made to accept as valid what is otherwise possible
>> > when using `[[<` ?
>> >
>> >
>> > Best,
>> >
>> > Laurent
>> >
>> >
>> >
>> > Le sam. 30 n

[Rd] default col.names from data.frame not the same as as.data.frame

[Spencer Graves]

Hello, All:


  Consider:


> data.frame(matrix(1:2, 1))
  X1 X2
1  1  2
> as.data.frame(matrix(1:2, 1))
  V1 V2
1  1  2


  I ask, because I got different default names running the same 
numbers through BMA:::bic.glm.matrix and BMA:::bic.glm.data.frame, so I 
thought I'd ask this group what names you all prefer for examples like 
these.



  Thanks,
  Spencer Graves

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] What should dnorm(0, 0, -Inf) return?

[peter dalgaard]

I have committed a fix for r-devel (dnorm only).

-pd

> On 9 Dec 2019, at 08:49 , Martin Maechler  wrote:
> 
>> peter dalgaard 
>>on Sun, 8 Dec 2019 12:11:50 +0100 writes:
> 
>> Yes, that looks like a bug and an easily fixable one too.
> 
> agreed.
> 
>> However, I spy another issue: Why do we check the
>> !R_FINITE(x) && mu == x before checking for sd < 0 ? The
>> difference is whether we
> 
>> return ML_NAN; or ML_ERR_return_NAN;
> 
>> but surely negative sd should always be an error?
> 
>> I'd be inclined to do
> 
>> if (sigma < 0) ML_ERR_return_NAN;
>> if(!R_FINITE(sigma)) return R_D__0;
>> if(!R_FINITE(x) && mu == x) return ML_NAN;/* x-mu is NaN */
>> if (sigma == 0) 
>>   return (x == mu) ? ML_POSINF : R_D__0;
>> x = (x - mu) / sigma;
> 
> 
>> (Ping Martin...)
> 
> I think you are spot on, Peter.
> All of this code has a longish history, with incremental border
> case improvements.
> Let's hope (somewhat unrealistically) this is the last one for
> dnorm().
> 
> NB: dlnorm() and some of the gamma/chisq/.. may need a
>similar adjustment
> 
> Lastly, regression tests for this
> (either in  tests/d-p-q-r-tests.{R,Rout.save}
> or easier in reg-tests-1d.R)  should be added too.
> 
>> -pd
> 
>>> On 7 Dec 2019, at 23:40 , Wang Jiefei  wrote:
>>> 
>>> Good question, I cannot speak for R's developers but I would like to
>>> provide some information on the problem. Here are the first few lines of
>>> the dnorm function located at src\nmath\dnorm.c:
>>> 
>>> ```
>>> double dnorm4(double x, double mu, double sigma, int give_log)
>>> {
>>> #ifdef IEEE_754
>>> if (ISNAN(x) || ISNAN(mu) || ISNAN(sigma))
>>> return x + mu + sigma;
>>> #endif
>>> if(!R_FINITE(sigma)) return R_D__0;
>>> if(!R_FINITE(x) && mu == x) return ML_NAN;/* x-mu is NaN */
>>> if (sigma <= 0) {
>>> if (sigma < 0) ML_ERR_return_NAN;
>>> /* sigma == 0 */
>>> return (x == mu) ? ML_POSINF : R_D__0;
>>> }
>>> 
>>> }
>>> ```
>>> 
>>> You can clearly see where the problem is. I think either the document or
>>> the code needs a modification.
>>> 
>>> Best,
>>> Jiefei
>>> 
>>> On Sat, Dec 7, 2019 at 5:05 PM Weigand, Stephen D. via R-devel <
>>> r-devel@r-project.org> wrote:
>>> 
 Hi,
 Apropos of a recent Inf question, I've previously wondered if dnorm "does
 the right thing" with
 
 dnorm(0, 0, -Inf)
 
 which gives zero. Should that be zero or NaN (or NA)?
 
 The help says "'sd < 0' is an error and returns 'NaN'" and since -Inf < 0
 is TRUE, then... is this a bug?
 
 Thank you,
 Stephen
 Rochester, MN USA
 
 __
 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
> 
>> -- 
>> Peter Dalgaard, Professor,
>> Center for Statistics, Copenhagen Business School
>> Solbjerg Plads 3, 2000 Frederiksberg, Denmark
>> Phone: (+45)38153501
>> Office: A 4.23
>> Email: pd@cbs.dk  Priv: pda...@gmail.com

-- 
Peter Dalgaard, Professor,
Center for Statistics, Copenhagen Business School
Solbjerg Plads 3, 2000 Frederiksberg, Denmark
Phone: (+45)38153501
Office: A 4.23
Email: pd@cbs.dk  Priv: pda...@gmail.com

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] Inconsistent behavior for the C AP's R_ParseVector() ?

[Tomas Kalibera]

On 12/7/19 10:32 PM, Laurent Gautier wrote:
> Thanks for the quick response Tomas.
>
> The same error is indeed happening when trying to have a zero-length 
> variable name in an environment. The surprising bit is then "why is 
> this happening during parsing" (that is why are variables assigned to 
> an environment) ?

The emitted R error (in the R console) is not a parse (syntax) error, 
but an error emitted during parsing when the parser tries to intern a 
name - look it up in a symbol table. Empty string is not allowed as a 
symbol name, and hence the error. In the call "list(''=1)" , the empty 
name is what could eventually become a name of a local variable inside 
list(), even though not yet during parsing.

There is probably some error in how the external code is handling R 
errors  (Fatal error: unable to initialize the JIT, stack smashing, etc) 
and possibly also how R is initialized before calling ParseVector. 
Probably you would get the same problem when running say 
"stop('myerror')". Please note R errors are implemented as long-jumps, 
so care has to be taken when calling into R, Writing R Extensions has 
more details (and section 8 specifically about embedding R). This is 
unlike parse (syntax) errors signaled via return value to ParseVector()

Best,
Tomas

>
> We are otherwise aware that the error is not occurring in the R 
> console, but can be traced to a call to R_ParseVector() in R's C 
> API:(https://github.com/rpy2/rpy2/blob/master/rpy2/rinterface_lib/_rinterface_capi.py#L509).
>
> Our specific setup is calling an embedded R from Python, using the 
> cffi library. An error on end was the first possibility considered, 
> but the puzzling specificity of the error (as shown below other 
> parsing errors are handled properly) and the difficulty tracing what 
> is in happening in R_ParseVector() made me ask whether someone on this 
> list had a suggestion about the possible issue"
>
> ```
> >>>  import  rpy2.rinterface  as  ri
> >>>  ri.initr()
> >>>  e  =  ri.parse("list(''=1+")  
> ---
> RParsingError  Traceback  (most  recent  call  
> last)>>> e = ri.parse("list(''=123") R[write to console]: Error: 
> attempt to use zero-length variable name R[write to console]: Fatal 
> error: unable to initialize the JIT *** stack smashing detected ***: 
>  terminated ```
>
> Le lun. 2 déc. 2019 à 06:37, Tomas Kalibera  > a écrit :
>
> Dear Laurent,
>
> could you please provide a complete reproducible example where
> parsing
> results in a crash of R? Calling parse(text="list(''=123") from R
> works
> fine for me (gives Error: attempt to use zero-length variable name).
>
> I don't think the problem you observed could be related to the memory
> leak. The leak is on the heap, not stack.
>
> Zero-length names of elements in a list are allowed. They are not the
> same thing as zero-length variables in an environment. If you try to
> convert "lst" from your example to an environment, you would get the
> error (attempt to use zero-length variable name).
>
> Best
> Tomas
>
>
> On 11/30/19 11:55 PM, Laurent Gautier wrote:
> > Hi again,
> >
> > Beside R_ParseVector()'s possible inconsistent behavior, R's
> handling of
> > zero-length named elements does not seem consistent either:
> >
> > ```
> >> lst <- list()
> >> lst[[""]] <- 1
> >> names(lst)
> > [1] ""
> >> list("" = 1)
> > Error: attempt to use zero-length variable name
> > ```
> >
> > Should the parser be made to accept as valid what is otherwise
> possible
> > when using `[[<` ?
> >
> >
> > Best,
> >
> > Laurent
> >
> >
> >
> > Le sam. 30 nov. 2019 à 17:33, Laurent Gautier
> mailto:lgaut...@gmail.com>> a écrit :
> >
> >> I found the following code comment in `src/main/gram.c`:
> >>
> >> ```
> >>
> >> /* Memory leak
> >>
> >> yyparse(), as generated by bison, allocates extra space for the
> parser
> >> stack using malloc(). Unfortunately this means that there is a
> memory
> >> leak in case of an R error (long-jump). In principle, we could
> define
> >> yyoverflow() to relocate the parser stacks for bison and
> allocate say on
> >> the R heap, but yyoverflow() is undocumented and somewhat
> complicated
> >> (we would have to replicate some macros from the generated
> parser here).
> >> The same problem exists at least in the Rd and LaTeX parsers in
> tools.
> >> */
> >>
> >> ```
> >>
> >> Could this be related to be issue ?
> >>
> >> Le sam. 30 nov. 2019 à 14:04, Laurent Gautier
> mailto:lgaut...@gmail.com>> a
> >> écrit :
> >>
> >>> Hi,
> >>>
> >>> The behavior of
> >>> ```
> >>> SEXP R_ParseVector(SEXP, int, Pa

Re: [Rd] Inconsistencies in wilcox.test

[Pavel S. Ruzankin]

I'd like to ask the developers to include some exact computation for 
ties into wilcox.test(). Just try


wilcox.test(c(1,1,5),c(10,11))

wilcox.test(c(1,2,5),c(10,11))

The p-values differ significantly.

But if I try

library(exactRankTests)

wilcox.exact(c(1,1,5),c(10,11))

wilcox.exact(c(1,2,5),c(10,11))

then the p-values coincide as expected. (R is used by many 
non-mathematicians/non-engineers who pay no attention at warnings.)


__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel