Other applications

The designs presented here have many uses, not just to nonadaptive group testing for pathogens. In this page I catalog some of those other uses:

Drug discovery

Imainge that we have an assay that detects if a small molecule activates a certain enzyme involved in a disease. We could screen every compound alone, or we could pool compounds. As an example, we could run 9 tests (m=9) on 12 compounds (n=12) in triplicate (r=3) using the S3 design if we pooled 4 samples per assay,

Pooled Clinical Trial Design

Imainge that we have 12 potential therapies that might help treat a disease. We could screen every therapy alone, or we could pool therapies. As an example, we could run a trial with 9 patients (m=9) on 12 treatments (n=12) in triplicate (r=3) using the S3 design if we pooled 4 treatments per patient.

Preference Ranking

Imagine that we are running a survey to get people's opinons on 9 jams (m=9). We might want to have have everyone try all 9 jams but that is a difficult thing to do. Most normal people may be able to only rank 2 or 3 jams. If we wanted to validate all pair wise comparisons =(9*8)/2 = 36, so we would need to recruit 36 people to cover our bases. However, if we used a disjunct design like S3, we could have each person test 3 jams, and need only 12 people (n=12).

Extedning the jam analogy further, imagine we wanted to get people's ranked opinions on 21 jams (m=21). If we had people just compare pairs of jams we would need 21*20/2=400 people to exhaustively cover the space. If we asked people to rank three jams we could use the M3 design (m=21) and require only 70 people (n=70, r=3).

For the 21 jam case, we could also have people just rank pairs and use the M2 design (n=231). This ranking would not fill in the full 400 exhaustive pairs, but we don't need all exhaustive pairs due to the transitive property . For example, if someone ranks A>B and someone else ranks B>C, then we can infer that A>C by the transitive property of rankings.

The ranking case is a little strange in that if we allow people to rank 4 items, then we get a total of 6 preferences. For example, by sayin A > B > C > D, we can infer the following pairs:

• A>B
• A>C
• A>D
• B>C
• B>D
• C>D

Thus to cover our 400 pairs for the 21 jam case we would need at least 400/6 = 66.66 people to do our ranking. Interestingly, the M4 design allow us to do this for 28 jams with data from 63 people ranking 4 jams--again due to the transitive property. Pretty slick! Note that the our efficiency rises as we force people to rank more jams, but not by a lot.

Note that for this rankig to work out, we need to assume we all agree on rankings, which won't happen, but that is where we get the compactnes. But the compactness then allows us to run multiple compact trials and validate what works and does not work.

Robust Packing

Imagine that we are sending out 12 parts (n=12) to make a machine. Each box we have can hold at most 4 different parts (=pool size). To make sure that the recipeient has enough parts to make up the machine, we decide to send the parts in triplicate (r=3). Rather than pack all of the boxes with the same part, we distribute the parts across boxes to maximize the probability that enough parts for a single machine will arrive. We can use an S3 design, and pack the items in 9 boxes (m=9).

Robust Supply Chain: Manufacturing

Imagine that we are a company that needs 12 parts (n=12) to make a machine. A factory can make at most 4 different kinds of parts (=pool size). To make sure that we have a robust supply chain to produce the machine, we decide to build factories so that there are three different places to build each part (r=3). We distribute production of the parts across factories to maximize the probability that enough parts for a single machine will always be available. We can use an S3 design, and make the parts in 9 factories (m=9).

Robust Manufacturing: Fast comparisons

Imagine that we are a company that needs 12 parts (n=12) to make a machine, and each part can be made by the current producer (0) or a new producer (1). We expect that parts from both producers will perform similarly, but we need to test. One way to test would be to build 9 prototypes, each using 4 parts from the new maunfacturer (pool size) as specified by an S3 design. If there is a manufacturer who makes a part that performs much bettter or worse, we should be able to detect that using this design as each new manufacturer's part.

Advertising optimization: Fast comparisons

Imagine that we are a company that has 12 parts (n=12) to our online ad, and each part can be the current version (0) or a new version (1). We expect that both versions of each part will perform similarly, but we need to test. One way to test would be to build 9 prototype ads, each using 4 parts from the new version (pool size) as specified by an S3 design. If there is a version of a part that performs much bettter or worse, we should be able to detect that.

Machine learning: Fast comparisons

Imagine that we are a robot that is performing a 12 part (n=12) process, and each part can be the current version (0) or a new version (1). We expect that both versions of each part will perform similarly, but we need to test. One way to test would be to build 9 prototype processes, each using 4 parts from the new version (pool size) as specified by an S3 design. If there is a version of a part that performs much bettter or worse, we should be able to detect that.

Directed Evolution of DNA sequences: Fast comparisons

Imagine that we are desiging a DNA sequence to respond to an imput. There are 12 bases we think might play a role (n=12), so we can try someting new in each of these bases while holding the rest constant. We expect that most changes will have no effect, but we need to test. We could design 9 sequences which each have 4 changes in them (pool size) as specified by the S3 design. If any version affects the performance of the sequence, we should be able to detect it.

A more extreme version would be the XL3 case, where we have 1426 different sites (n=1426) that could play a role in the DNA sequence response. We can test all of these in groups of 46 in 93 different constructs (m=93, pool size=46).

Efficient parameter sweeps

Imagine that we had a big computer model that took hours to run. We have 1426 variables and we are trying to see what variables most influnce our outcome. Rather than run 1426 simulations, w could run 93 simulations, with each simulation perturbing 46 parameters (m=93, pool size=46). This is the XL3 design.

Robust Data Storage

Imagine that we are storing 12 documents (n=12) on an array of hard drives. Each drive we have can hold at most 4 different documents (=pool size). To make sure that we have all of the documents, we decide to store the documents in triplicate (r=3). Rather than pack all of the drives with the same document, we distribute the document across drives to maximize the probability that enough documents will survive if some of the drives go offline. We can use an S3 design, and put the documents in 9 drives (m=9).

Human Resource Management: Job allocation for robustness

Imagine that we are a small company that needs people with skills to do 12 different tasks (n=12). We realize that people sometimes people get sick or go on vacation, so we want people to be skilled at multiple different tasks. It may be too much to ask everyone to be able to do everything, so we limit it to having everyone competent in 4 skills (=pool size). If our company has 9 employees (m=9) then each skill is known by 3 people (r=3) (S3 design). If on a given day 1 or 2 people are unavaialble, then we will still always have all of the skill sets present to do the day's work.

Software Resource Management: Software licence allocation for robustness

Imagine that we are company that has a bunch of software (n=1426 different packages), each of which can be licenced to a particular machine. Rather than licence everything to every machine, we distribute the licences across 93 machines (m=93) (XL3 design). Each machine has 46 packages on it (=pool size), and each software package just requires 3 licences (r=3). Assuming these packages are used fairly rarely and randomly, we should be able to find a machine with the package on it that is not overburdened.

Registration line management

Imagine that we are running a large conference where many people are arriving at once. To balance the load of lines, we have people go to the least full line based on the last letter of their name (m=26). We can approximate this by the M4 design, where we have m=28. In this system, the lists are divided between 63 tables (n=63), and each table is responsible for 4 letters. This way we expand the capacity of the line system to make 9 tables (=pool size) avaialble to each registrant, while minimzing the look up time for each table becaus they only manage a small part of the list.

Alarm Systems: beam breaks

Imagine that we have an alarm system of beam breaks. We want to set off the alarm when one or more of 12 doors opens (n=12), and we also want to know what door is open. Rather than install 12 beam breaks to detecte each door individually, we could use just 9 beam (m=9) breaks, each based off of 4 doors, with each door impinging on 3 beams (r=3). This is the S3 system.

Biological signal transduction

Imagine that we have an a receptor system with 12 different receptors (n=12) that transmit to 9 different intermeidate signaling proteins (m=9). If each receptor activated 4 different intermediates (pool size=4), and each intermediate were connected to 3 different receptors (r=3), we could still detect and resovle 0, 1, and 2 separate receptor signals.

Social lunch planning

Imagine that we are running a social group of 12 people (n=12), and want to send them out for lunch in groups of 4 (=pool size). We want each person to go out to lunch three times (r=3), and want everyone to mingle so that they never have lunch with the same people twice. Using the S3 design we can set up 9 lunches (m=9) to achive this.