similar to: Inconsistencies in wilcox.test

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

>>>>> Karolis Koncevi?ius >>>>> on Mon, 9 Dec 2019 23:43:36 +0200 writes: > So I tried adding Infinity support for all cases. > And it is (as could be expected) more complicated than I thought. "Of course !" Thank you, Karolis, in any case! > It is easy to add Inf support for the test. The problems start with conf.int=TRUE.

>>>>> 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))

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

Your second issue seems like a more or less unavoidable floating-point computation issue. The paired test operates by computing differences between corresponding values of x and y. It's not impossible to try to detect "almost-ties" (by testing for differences less than, say, sqrt(.Machine$double.eps)), but it's delicate and somewhat subjective/problem-dependent. Example:

>>>>> Martin Maechler >>>>> on Thu, 12 Dec 2019 17:20:47 +0100 writes: >>>>> Karolis Koncevi?ius >>>>> on Mon, 9 Dec 2019 23:43:36 +0200 writes: >> So I tried adding Infinity support for all cases. And it >> is (as could be expected) more complicated than I >> thought. > "Of course

But this might require a more detailed investigation. For example I just noticed that even with the patch `@` is still not listed in .S3_methods_table(). KK. > On Apr 29, 2023, at 4:44 PM, Karolis Koncevi?ius <karolis.koncevicius at gmail.com> wrote: > > Hello Kurt, > > With r84341 it now works on my side. > > Warm regards, > Karolis K. > >> On Apr 29,

>>>>> Karolis Koncevi?ius writes: > But this might require a more detailed investigation. For example I > just noticed that even with the patch `@` is still not listed in > .S3_methods_table(). Afaict base does not register any methods for @ or @<- ? -k > KK. >> On Apr 29, 2023, at 4:44 PM, Karolis Koncevi?ius <karolis.koncevicius at gmail.com> wrote:

Hello Kurt, With r84341 it now works on my side. Warm regards, Karolis K. > On Apr 29, 2023, at 1:24 PM, Kurt Hornik <Kurt.Hornik at wu.ac.at> wrote: > >>>>>> Karolis Koncevi?ius writes: > > Can you pls try again with r84341 or later? > > Best > -k > >> A more concrete example in order to correct my vague messages below. >> Writing

>>>>> Karolis Koncevi?ius writes: Can you pls try again with r84341 or later? Best -k > A more concrete example in order to correct my vague messages below. > Writing an R package that uses `@` and `@<-` as S3 generics. Line from manual pages in .Rd files: > \method{@}{newclass}(object, name) <- value > Throws this error during R CMD check ?as-cran >

A more concrete example in order to correct my vague messages below. Writing an R package that uses `@` and `@<-` as S3 generics. Line from manual pages in .Rd files: \method{@}{newclass}(object, name) <- value Throws this error during R CMD check ?as-cran Bad \usage lines found in documentation object ?code?: <unescaped bksl>method{@}{newclass}(object, name) <-

Thank you for such a quick reply, Gabriel, I am not too familiar with the package tools, so cannot speak too confidently, but below is how I see the issue currently. The issue is not for external packages to rely on unexported functions from tools::, rather the issue is that 'R CMD check ?as-cran' runs those functions from tools:: in order to check the validity of Rd files (from any

This issue might go deeper - I was not successful in passing R CMD checks for the usage files. R CMD check kept showing errors for `@` declarations, even thou they were identical to `$` declarations (which passed fine). Seems like the usage check functions are not prepared for `@` - also in tools:::.S3_method_markup_regexp > On Apr 28, 2023, at 10:34 PM, Karolis Koncevi?ius

Karolis, It seems likely, without having looked myself, that you could be correct about the issue, but it does seem worth noting that both of the functions you have mentioned are not exported, and thus not part of the API that extension packages are allowed to use and rely on. If retrieving the list of "internal S3 generics" is something package and user code is allowed to do, the real

I was building a package that uses the new generic @ and kept having errors with ?roxygen2? documentation. ?roxygen2? generated NAMESPACE added `@.newclass` as a newly exported function, not as a S3method. At first I thought this must be a bug in roxygen2 and they lag behind the new developments in R. But after some investigation I found that ?roxygen2? is using tools:::.get_internal_S3_generis()

In specific cases fligner.test() can produce a small p-value even when both groups have constant variance. Here is an illustration: fligner.test(c(1,1,2,2), c("a","a","b","b")) # p-value = NA But: fligner.test(c(1,1,1,2,2,2), c("a","a","a","b","b","b")) # p-value < 2.2e-16

Hello, I also want to report 2 missed cases of stringsAsFactors=TRUE in base: 1. grid.expand() still uses hard stringsAsFactors=TRUE in its arguments. 2. as.data.frame.table() also keeps factors after conversion from table. >>>>>> Duncan Murdoch >>>>>> on Sun, 12 Apr 2020 08:57:14 -0400 writes: > > > The NEWS for R 4.0.0 says "R now uses

Hi, I am using wilcox.test function to test the difference between the means of two samples. The data points are paired, so I am using a paired test. There is one strange case. Sample A has a higher mean than a sample B. However, wilcox.test function says that sample B has a significantly higher "mean rank" than sample A. How is it possible? Here is the code (data file is attached):

Hello, I recently stumbled on an unusual behaviour of any() and all() and have been adviced from StackOverflow to share it here [1]. df1 <- data.frame(A=TRUE, B=FALSE) df2 <- data.frame(A=1, B=0) > any(df1) Error in FUN(X[[i]], ...): only defined on a data frame with all numeric variables > any(df2) [1] TRUE Warning message: In any(c(1,

Thank you for such a quick reply, here are some points that I think might have been missed: > I would state the question the other way : why are NAs integer indices allowed? > In my experience, they are sometimes useful but they often delay the detection of bugs. However, due to backward compatibility, this feature cannot be removed. Adding this feature to character indices would worsen the