similar to: Multiple comparison tests - Homogenous subsets (i.e. for Tukey)

Hello Everyone, *Question: *How do you calculate the sum of squares for a two-way _unbalanced_ ANOVA? *What I have done:* I have found many useful tutorials online for running a balanced two-way ANOVA but I haven't had much luck for running a unbalanced two-way ANOVA. From what I have read, the trouble with running an unbalanced two-way ANOVA, is that things get tricky when calculating

hi list, i have to ask you again, having tried and searched for several days... i want to do a TukeyHSD after an Anova, and want to get the adjusted p-values after the Tukey Correction. i found the p.adjust function, but it can only correct for "holm", "hochberg", bonferroni", but not "Tukey". Is it not possbile to get adjusted p-values after

A character device for accessing (in user-space) pages that have been granted by other domains. Signed-off-by: Derek Murray <Derek.Murray@cl.cam.ac.uk> _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel

Ever since xen-unstable cset 14308 ("pci back: Fix registration of of filters on subsections of config space") I''ve been getting an MCA on the *2nd* boot of a driver domain using an e1000 NIC. Cset 14308 allowed the proper setup of the PM control registers, so the NIC is put in the D3 power state when the driver domain shuts down. Unfortunately, pci_set_power_state()

On Wednesday 04 Apr 2012 13:27:07 Tim Northover wrote: > Putting that information in the InputArg/OutputArg and incorporating it the > CCAssignFn interface allows a more straightforward implementation in the > targets, in my view (for both our uses). It's also information that's > readily available when InputArg/OutputArgs are being constructed. In your > case: > >

Dear R-users, We expect to form N homogeneous groups of n features from an experimentation including N*n data. The aim is to prevent group effects. How to do that with R functionalitites ? Does anyone know any way enabling this ? Example : 100 patients are observed. 3 biochemical parameters are mesured for each one (Red and white globules ans glycemia). Patient RG RW

Hello and thanks in advance I am running a glm in R the code is as follows with residual diagnostic code below model4<-glm(Biomass~(Treatment+Time+Site)^2, data=bobB, family=quasi(link="log", variance="mu")) par(mfrow=c(2,2)) plot(model2) to test the effect of grazing exclusion of feral horses for a Phd with following factors: Treatment - 3 levels which are grazed

Hi Tim > I'm not sure I follow this point. Is preserving the source language a bad > thing for some reason I'm missing? Certainly, if it affects optimisation it > would be. Let's consider one example: union { float foo[4]; int bar[3]; }; This is definitely not a HFA. However, such a union can be represented via several different things in LLVM IR: [4 x float], [4 x

Hi all, I think that ABI of LLVM IR level is different from ABI on real architecture such as ARM or x86. ABI of LLVM IR level doesn't consider about register usage. It just describes parameters and padding information related to alignment of parameters. As Anton mentioned, LLVM have expressed ABI information on bitcode using front-end. If someone wants to maintain information from high level

Tim, > Opinions, anyone? (Hint hint). I think here stuff should be thought of from different points. While providing source type for argument might be beneficial, it might cause moving the code from frontend to backend. Consider e.g. passing struct by value including crazy padding inside. The ABI might specify that padding should be removed and struct is passed field-by-field. Also, note that

Hi Tim, > So I've come to the conclusion that the real flaw is LLVM > not exposing enough information to the target-dependent > backend code for it to do the right thing. We also had this problem. You might find this patch useful as a starting point: http://lists.cs.uiuc.edu/pipermail/llvmdev/2012-March/048266.html /Patrik Hägglund -----Original Message----- From: llvmdev-bounces

> I think that ABI of LLVM IR level is different from ABI on real architecture > such as ARM or x86. ABI of LLVM IR level doesn't consider about register > usage. It just describes parameters and padding information related to > alignment of parameters. I'm not sure what you mean here. LLVM's IR certainly doesn't care about registers and so on, but the LLVM backends

On Wednesday 04 Apr 2012 12:41:49 Patrik Hägglund H wrote: > Hi Tim, > > > So I've come to the conclusion that the real flaw is LLVM > > not exposing enough information to the target-dependent > > backend code for it to do the right thing. > > We also had this problem. You might find this patch useful as a starting > point:

Hi, (Forward from cfe-commits, where some backend stuff has come up). This is an issue I've been thinking about quite a bit recently, and I agree that the biggest problem is the one below: > * The big thing still missing here is that there is no logic to check how many VFP registers have already been used for other arguments. When deciding whether to pass an argument as a homogeneous