Ulrike Gromping – Design of Experiments in R

csgillespie

11 years ago

[This article was first published on Why? » R, and kindly contributed to R-bloggers]. (You can report issue about the content on this page here)

Want to share your content on R-bloggers? click here if you have a blog, or here if you don't.

Example: Car seat occupation:

Algorithm must decide whether airbag opens:

Must open for adult but not for small child or if the seat if empty
a few others I missed.

Key questions are:

What type of design: 32 run regular fractional factorial
Response measurement – depends on dummy position, so repeat for 3 different
dummy places
Precision – are 32 rounds enough

Use frf2 function in Ulrike’s package to generate experimental design.

Principals of DoE. Developed initially by Fisher. Key principles are blocking, randomization, replication. Repeated measurements are NOT replications.

In this example, there is high measurement error variance. Repeats done directly in sequence. Need to decide between replications and repeats – these are not the same! Balanced factorial experiments provide intrinsic replication.

George Box advocated that when creating experimental designs, you should proceed sequentially. Smaller initial screening. This does not apply to computer experiments.

Experimental Design Task View

Started in Feb 2008 and currently contains 37 packages. Maintainers need help, please point out relevant packages or complain about unhelpful packages. Of the 37 packages, only 18 have a dependency relation to others.

As with many packages, FrF2 and DOE.base were developed (in 2008) because someone needed them.

Package dependencies

DoE.base -> FrF2 -> DoE.wrapper -> Gui interface (R commander plugin).

DoE.base: for full factorial with blocking and orthogonal arrays
FrF2 2-level fractional factorials
DoE.wrapper – unify syntax.

Packages have a common output structure based on the White book. An R commander plugin has been developed and released, but it’s still in the early stages.

Guidance

Should the GUI give guidance with experimental design? This is tricky with such a flexible system. How can the software know the correct solution. Is there a middle ground? Solutions would be very work-intensive – who will do the work?

Call for activities

A lot is available, but there are still gaps in functionality. If you have the expertise, why not write a package? Other possibilities are bug reports, suggestions for improvement, wishes, GUI beta testing, internationalization (not quite ready yet).