similar to: [Suggested patch] to fligner.test - constant values can produce significant results

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

Full_Name: Karel Zvara Version: 1.8.1 OS: MS Winows 2000 Submission from: (NULL) (195.113.30.163) The test statistics of the fligner.test (ctest package) depends on the order of cases: > fligner.test(count~spray,data=InsectSprays) Fligner-Killeen test for homogeneity of variances data: count by spray Fligner-Killeen:med chi-squared = 14.4828, df = 5, p-value = 0.01282 >

I've made fligner test with the same data, changing the orders of the variables, and this what i get > fligner.test(rojos~edadysexo*zona*ano*estacion) Fligner-Killeen test of homogeneity of variances data: rojos by edadysexo by zona by ano by estacion Fligner-Killeen:med chi-squared = 15.7651, df = 2, p-value = 0.0003773 > fligner.test(rojos~ano*edadysexo*zona*estacion)

Can anybody tell me if there is an R implementation of the Fligner-Policello robust rank test? Thanks, Elisabetta

Hi, I'm a new user of R. My background is Electrical Engineering, so please bear with me if this is a silly question. I'm trying to assess whether the results of an experiment satisfy the hypothesis of homoscedasticity (my ultimate goal is to use ANOVA). The result of the experiment is mean delay (dT), which depends on three factors, topology, drift, and lambda. The first two factors are

I am testing the homogeneity of variances via bartlett.test and fligner.test. Using the following example, how should I interpret the p-value in order to accept or reject the null hypothesis ? set.seed(5) x <- rnorm(20) bartlett.test(x, rep(1:5, each=4)) Bartlett test of homogeneity of variances data: x and rep(1:5, each = 4) Bartlett's K-squared = 1.7709, df = 4, p-value =

Hello, I investigate survival until the following year (0,1) and I wish to test if the variance in survival for two or more groups are significantly different from each other. I read that the Fligner-Killeen test is a non-parametric test which is very robust against departures from normality but is it correct (valuable technique for publication) to use it on binary data? In other

That's not an R question but a stats question, but I wouldn't do it. For one thing: The variance of binary data is a function of the mean, so the research question is dubious in the first place. Secondly, the test is based on ranking and comparing absolute differences from the group median, which for binary data is generally 0 or 1, so all absolute differences will be 1.... Put

Hi R users! I have the following problem: how appropriate is my aov model under the violation of anova assumptions? Example: a<-c(1,1,1,1,1,1,1,1,1,1,2,2,2,3,3,3,3,3,3,3) b<-c(101,1010,200,300,400, 202, 121, 234, 55,555,66,76,88,34,239, 30, 40, 50,50,60) z<-data.frame(a, b) fligner.test(z$b, factor(z$a)) aov(z$b~factor(z$a))->ll TukeyHSD(ll) Now from the aov i found that my model

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

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,

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

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

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

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.

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)