similar to: stats::line() does not produce correct Tukey line when n mod 6 is 2 or 3

Tukey divides the points into three groups, not the x and y values separately. I'll try to get hold of the book for a direct quote, might take a couple of days. On Mon, May 29, 2017 at 8:40 AM, Duncan Murdoch <murdoch.duncan at gmail.com> wrote: > On 27/05/2017 9:28 PM, GlenB wrote: > >> Bug: stats::line() does not produce correct Tukey line when n mod 6 is 2 >> or

A usually trustworthy R correspondent posted a pure R implementation on SO at some point in his lost youth: https://stackoverflow.com/questions/3224731/john-tukey-median-median-or-resistant-line-statistical-test-for-r-and-line This one does indeed generate the line of identity for the (1:9, 1:9) case, so I do suspect that we have a genuine scr*wup in line(). Notice, incidentally, that >

Here is an attached patch. Best, Serguei. Le 29/05/2017 ? 12:21, Serguei Sokol a ?crit : > The problem or actual R implementation relies on an assumption > that median(x[i] | x[i] <= quantile(x, 1/3)) == quantile(x, 1/6) > which reveals not to be true despite very trustful appearance. > > If we continue with the example of x=y=1:9 > then quantile(x, 1/6)=2.5 (here quantile()

> Tukey divides the points into three groups, not the x and y values separately. > I'll try to get hold of the book for a direct quote, might take a couple of days. Ah well, I can't get it for a week. But the fact that it's often called Tukey's three group line (try a search on *tukey three group line* and you'll get plenty of hits) is pretty much a giveaway. On Mon,

The problem or actual R implementation relies on an assumption that median(x[i] | x[i] <= quantile(x, 1/3)) == quantile(x, 1/6) which reveals not to be true despite very trustful appearance. If we continue with the example of x=y=1:9 then quantile(x, 1/6)=2.5 (here quantile() is taken in C-code sens, not R's one) while median(y[i] | x[i] <= quantile(x, 1/3))=2 On the other sample's

Sorry, I have seen it too late that we had different tab width in the original file and my editor. Here is the patch with all white spaces instead of mixing tabs and white spaces. Serguei. Le 29/05/2017 ? 15:13, Serguei Sokol a ?crit : > Here is an attached patch. > > Best, > Serguei. > > Le 29/05/2017 ? 12:21, Serguei Sokol a ?crit : >> The problem or actual R

On 27/05/2017 9:28 PM, GlenB wrote: > Bug: stats::line() does not produce correct Tukey line when n mod 6 is 2 or > 3 > > Example: line(1:9,1:9) should have intercept 0 and slope 1 but it gives > intercept -1 and slope 1.2 > > Trying line(1:i,1:i) across a range of i makes it clear there's a cycle of > length 6, with four of every six correct. > > Bug has been

Seriously, if a method gives a wrong result, it's wrong. line() does NOT implement the algorithm of Tukey, even not after the patch. We're not discussing Excel here, are we? The method of Tukey is rather clear, and it is NOT using the default quantile definition from the quantile function. Actually, it doesn't even use quantiles to define the groups. It just says that the groups

Le 31/05/2017 ? 17:30, Serguei Sokol a ?crit : > > More thorough reading revealed that I have overlooked this phrase in the > line's doc: "left and right /thirds/ of the data" (emphasis is mine). Oops. I have read the first ref returned by google and it happened to be tibco's doc, not the R's one. The layout is very similar hence my mistake. The latter does not

OTOH, > sapply(1:9, function(i){ + sum(dfr$time <= quantile(dfr$time, 1./3., type = i)) + }) [1] 8 8 6 6 6 6 8 6 6 Only the default (type = 7) and the first two types give the result lines() gives now. I think there is plenty of reasons to give why any of the other 6 types might be better suited in Tukey's method. So to my mind, chaning the definition of line() to give sensible

>>>>> Serguei Sokol <sokol at insa-toulouse.fr> >>>>> on Mon, 29 May 2017 15:28:12 +0200 writes: > Sorry, I have seen it too late that we had different tab > width in the original file and my editor. Here is the > patch with all white spaces instead of mixing tabs and > white spaces. thank you - it still gives quite a few

>>>>> Serguei Sokol <sokol at insa-toulouse.fr> >>>>> on Tue, 30 May 2017 16:01:17 +0200 writes: > Le 30/05/2017 ? 09:33, Martin Maechler a ?crit : ... >> However, even after the patch, The example from the SO >> post differs from the result of Richie Cotton's >> function... > The explanation is quite simple.

>>>>> Serguei Sokol <sokol at insa-toulouse.fr> >>>>> on Wed, 31 May 2017 18:46:34 +0200 writes: > Le 31/05/2017 ? 17:30, Serguei Sokol a ?crit : >> >> More thorough reading revealed that I have overlooked this phrase in the >> line's doc: "left and right /thirds/ of the data" (emphasis is mine). >

> On 31 May 2017, at 16:40 , Joris Meys <jorismeys at gmail.com> wrote: > > And with "equally spaced" I obviously meant "of equal size". It's getting > too hot in the office here... We have a fair amount of cool westerly wind up here that I could transfer to you via WWTP (Wind and Weather Transport Protocol). If you open up a sufficiently large pipe,

And with "equally spaced" I obviously meant "of equal size". It's getting too hot in the office here... On Wed, May 31, 2017 at 4:39 PM, Joris Meys <jorismeys at gmail.com> wrote: > Seriously, if a method gives a wrong result, it's wrong. line() does NOT > implement the algorithm of Tukey, even not after the patch. We're not > discussing Excel here,

Le 31/05/2017 ? 16:39, Joris Meys a ?crit : > Seriously, if a method gives a wrong result, it's wrong. I did not understand why you and others were using term "wrong" based on something that I was considering as just "different" implementation. More thorough reading revealed that I have overlooked this phrase in the line's doc: "left and right /thirds/ of the

Le 30/05/2017 ? 18:51, Martin Maechler a ?crit : >>>>>> Serguei Sokol <sokol at insa-toulouse.fr> >>>>>> on Tue, 30 May 2017 16:01:17 +0200 writes: > > Le 30/05/2017 ? 09:33, Martin Maechler a ?crit : ... > >> However, even after the patch, The example from the SO > >> post differs from the result of Richie

Dear list members, I'm running some tests looking at differences between means for various levels of a factor, using Tukey's HSD method. I would like to plot the data as boxplots or dotplots, with horizontal significance lines indicating which groups are statistically significantly different, according to Tukey HSD. Here's a nice image showing an example of such a graphical

I have been trying to do tukey's test to no avail. This is what I have and the error produced: pen.df = data.frame(blend, treatment, y) source("tukey.1.r") tukey.1(aov.pen, pen.df) Error in tukey.1(aov.pen, pen.df) : the model must be two-way This is a two-way design. Therefore I am confused. Can anyone help? Raphael > pen.df blend treatment y 1 1 A 89 2

I am embarrassed to have to ask this but can anyone tell me of a Tukey multiple comparisons procedure available for R? I have looked through the search page, through the FAQ, and in the index of V&R (1999), and I still can't find such a thing. I see there is a ptukey function and a qtukey function but that is as far as I got. Do I need to roll my own? -- Douglas Bates