Elevator Simulator

Introduction

The goal of our final project was to design an efficient elevator simulator that can accept input from a user and mechanically operate (on a small scale) a system of 4 floors and 3 elevators using pulleys and stepper motors.  Users enter input using physical pushbuttons or the computer.  This input is then processed by the MCU and orders are given to the elevators.  We attempted to devise an algorithm that can optimally handle any number of floors.  This project seemed like a fun challenge and something that had practical applications.  Both of us have been frustrated at times by the inefficiency of some of the elevators here at Cornell, and we wanted to see if we could do a better job.

Definition of Terms

Inside Button – A button on the inside of an elevator car.  A passenger would press this button after getting on an elevator.
Outside Button – A button outside the elevator cars.  There are at most two outside buttons on each floor (up and down).  In a real building there may be more for convenience, but the same functionality can be achieved with only two.
Request – A request to either get off on a floor (given to a specific elevator if an inside button has been pushed) or a request to be picked up on a floor going either up or down.  An outside button push will only assign a pick-up request to a single elevator.

High-level Design

The essence of our project was the high-level design.  Since it was our goal to simulate an efficient elevator system, designing the logic produce desirable results proved to be a challenge.  We decided the best way to control three separate elevators was to have each elevator respond optimally to any given set of requests (to pick up or drop off passengers).  We could then write an algorithm that would predict which elevator could respond the fastest to a passenger request and assign the request to that elevator.  While our physical elevator system only consists of 4 floors, the design can be scaled to any number of floors. 

Individual Elevator Behavior

The basis for our elevator’s behavior is the elevator algorithm, in which the elevator handles all requests in one direction before turning around.  Our code ensures that a single elevator will follow this behavior.  The logic that controls a single elevator is shown below.  Remember that in the case of outside buttons, a request is not necessarily the same as a button push (see definition of terms).  Handling these buttons is covered in the next section. 

Delegating Requests

In order to control our system of three elevators efficiently, we had to come up with a way to appropriately assign requests to each elevator.  Assigning requests from the inside button pushes was trivial, as an elevator must respond to its own inside buttons.  For each outside button pushed, only one elevator receives the request.  Our algorithm to assign requests favors the elevator with the fewest other requests in order to split traffic evenly among the elevators and minimize time spent waiting to get off.  In the case where two or more elevators have the same number of other requests, we compute the worst-case distance that each one must travel to answer the request.  The three scenarios are explained below. 

Case 1:  In this case, the elevator is traveling towards the floor that the request is on in the same direction that the request is in.  The worst-case distance (maximum number of floors) between the elevator and the request is just:
|requestFloor – currentFloor|
Where requestFloor is the floor that the request is on and currentFloor is the floor that the elevator is currently on.
Case 2:  In this case, the elevator is traveling in the opposite direction that the request is in.  The worst-case distance between the elevator is the distance from the elevator to end of the shaft in its current direction of travel plus the distance from the end of the shaft back to the request floor.  So, if the elevator is traveling upward, the distance is:
(floors-1-currentFloor)+(floors-1-requestFloor)
If the elevator is traveling downward, the distance is:
currentFloor + requestFloor
Where floors is the number of floors in the elevator system.
 Case 3:  In this case, the elevator is traveling away from the floor in the same direction that the request is in.  The worst-case distance is:
2*(floors – 1) – |requestFloor – currentFloor|.

Alternate Modes of Operation

We included several other modes of operation aside from the normal mode described above.  Below is a quick description of each mode.
Trivial Mode – Sends elevator 1 to do everything, ignores other elevators.
Simple Mode – All the elevators chase each outside button press and respond to their own inside button presses.  This is equivalent to having 3 separate elevators in trivial mode.
Sabbath Mode – Elevators ignore any button pushes.  They move up and down stopping at all floors along the way.  The elevators are staggered to minimize worst case waiting time.

Hardware Design

We built a 3-shaft, 4-story elevator model consisting of K’NEX and wooden dowels.  We added motors and pulleys to raise and lower the elevators.  The elevators are controlled using eighteen pushbuttons, twelve of which represent internal elevator buttons.  The other six outside buttons call elevators to particular floors.

Mechanical Design

Our elevator shafts are built from plastic K’NEX pieces.  We chose this material because it offered flexibility in design, ease of construction, and was available for free.  We added wooden guide dowels to align the elevator cars within the shafts.  The elevators are raised and lowered with twine using a pulley system.  The other end of the twine was attached to pulleys on each motor.  The motors were nailed to two parallel pieces of wood.

Electrical Design

We used three PF35T-48L4 stepper motors; one for each elevator.  The motors were logically controlled by the MCU but were powered using a standard 12V lab power supply.  Because the microcontroller cannot source enough current to run the motors, we added three ULN2003AN Darlington arrays, also attached to the power supply.  Below is the circuit used to connect the MCU port to the stepper motor using the Darlington array.

The stepper motors use a 4-state configuration.  Depending on the order of transitions between states, the motors either turn clockwise or counterclockwise.  Each state consists of a two-hot pin assignment.  Our program kept track of these states at alternated between them.  This is explained further in the software section.
Of our eighteen pushbuttons, six are on the STK500.  These 6 buttons are connected to pins 2 through 7 on port D of the MCU.  Because we also need pins D.0 and D.1 for the RS 232 serial connection, we needed to make an adapter that allowed both the STK500 pushbuttons and the RS 232 jumper to be connected to port D.  A picture of this adapter is shown below.

The other twelve buttons are mounted on a whiteboard and connected to VCC through 1 kW pull-up resistors on one end and to ground on the other end.  When the button is pushed down the port pin is driven low and the MCU detects a button push; otherwise it remains high.  The schematic for one set of four buttons is shown below.

_

Hardware Difficulties

We ran into two problems in hardware.  The first issue we came across was that the power supply we were using could not source enough current to power all 3 stepper motors.  The current was capped at 500 mA, while each stepper motor uses 350 mA.  To fix this issue, we simply switched to a larger power supply that can source more current.
Our second problem is that the stepper motors get very hot after being turned on for a while.  We did not find a solution to this problem, although it is not a major issue.  After several uncomfortable encounters with the motors, we decided to nail them to wooden boards rather than hold them.

Software Design
There are two parts to our software: the C code, which controls the elevator system, processes input from the user, and sends data to MATLAB, and the MATLAB code, which provides visual feedback as well as a secondary user interface.

C Code

The bulk of our C code implements the logic that is explained in the high-level design section.  To control each elevator, we use three structs (stored on the heap) of type Elevator with different fields such as the current direction, current floor, and any requests (inside and outside) assigned to the elevator.  This allows us to keep track of the current state of an elevator and determine appropriate behavior using a series of if statements in the oneStep function.  We also use these fields to calculate distances when assigning requests from outside buttons in the addRequests function.
When in normal operation, every pass through the main loop polls the pushbuttons, sends the button state through the serial connection to MATLAB (if buttons changed), delegates outside button requests, and calls the oneStep function.  Additionally, there is a TIMER0 interrupt that fires every millisecond.  This interrupt checks the serial port for data to output to MATLAB.  It also moves each elevator motor one step (by toggling pins on ports A, B, and C) every 50 milliseconds if the elevator is supposed to move.  The distance between floors is 38 motor steps, so by keeping track of how many steps have been taken the program knows where the elevator is.
Refer to the appendix for complete C code.

MATLAB Code

Our MATLAB program (elevator.m) constructs a GUI that communicates with the C program using the serial connection.  We drew several elevator components in MS Paint (buttons, doors, etc.)  The program places these images at appropriate locations to display the current state of the elevator system as a user would see it.  This is accomplished by parsing strings sent from the C code.
The MATLAB program also allows users to simulate button presses using the computer rather than actual hardware.  To do this, the input mode must first be set to computer in the C code.  Using this option, a user can simulate an elevator system with more (or less) than 4 floors.
Additionally, our program keeps statistics on the average wait time for a passenger to get on an elevator and off an elevator.  This is accomplished by timing how long a button remains on once pressed.

Refer to the appendix for the MATLAB code.

Software Difficulties

Our original algorithm did not appropriately separate single elevator operation from distributing requests among multiple elevators.  This made it very difficult to write correct code.  After adding several dozen hacks to deal with corner cases, we realized that our program was not scalable to multiple elevators.  We were forced to rewrite the code in a more modular fashion.
Scaling the MATLAB code an arbitrary number of floors required much trial and error to get the image placement correct.  Also, image placement used a different coordinate system from the MATLAB pushbuttons, complicating matters further.  To retrieve data from the serial port we originally used fgets, which is a blocking function.  This made the computer sluggish until we discovered the bytesavailable field of MATLAB serial objects, allowing us to poll for data before calling fgets.

Results

Performance and Accuracy

The best way for us to measure the results of our design is to put the elevator system in every conceivable situation and make sure it responds in the appropriate manner.  For every test case, our elevator demonstrated logical behavior.  Using our MATLAB GUI made testing much easier.  Additionally, we are able to measure performance using the statistics kept by the MATLAB code.  All of these statistics are reasonable and match our expectations, so we can be fairly certain that they are correct.
One interesting result is that Sabbath mode occasionally outperforms the normal mode of operation for a small number of floors.  However, increasing the number of floors in our simulation makes the wait time for Sabbath mode much worse.

Safety Considerations

Our elevator simulator is extremely safe.  There are no exposed sharp edges or high voltages that could injure a user.  There are two protruding nails in between the pieces of wood used to mount the motors.  Also, the motors run very hot to the touch.

Usability

Our design is user-friendly.  The interface simply consists of 18 physical pushbuttons (or MATLAB pushbuttons).  Using the elevator only requires pushing the appropriate button, much like an actual elevator.

Conclusions

Expectations

We met or exceeded most of the expectations that we had at the beginning.  We found ourselves continually adding new features to the project.  The result is a very efficient elevator system.  One area where we may have fallen a bit short is critical failure avoidance.  For example, we don’t have multiple strings supporting an elevator car or a backup system in case power is lost.  This is something that we could have improved on.  Also, we had the idea to write a MATLAB script that could send a series of commands to the elevator without any user input.  This would be useful for comparing algorithms across different usage patterns.  Finally, there is always room to improve upon the elevator algorithm.
Intellectual Property Considerations
All hardware and software design is our own. We did not borrow any code or sample any hardware.

Standards

Because our elevator system is meant only as a model for optimal elevator behavior and is not intended for actual use, we could not find any standards that apply to our project.  There are some safety standards that would be violated if our elevator were intended for passenger use, such as a lack of a backup system in the event of a power failure.

Ethical Considerations

We abided by all items listed in the IEEE Code of Ethics during our project design process.  Several of these items, such as rejecting bribes and malicious action, were not specifically relevant to this project, but are rather guidelines that we always adhere to. 
We made all of our decisions with welfare of the public and environment in mind.  As mentioned earlier, our design is very safe and does not harm the environment in any way.  Additionally, our elevator simulator is simple to use and it’s applications are well understood.
Throughout the design and testing process, we were open to suggestions from our peers and instructors.  Also, we listened to each other’s ideas and made compromises whenever there was a difference of opinion.  We helped other groups with issues they were having whenever possible.
Our elevator simulator does not discriminate based on race, religion, gender, age, or national origin.  In fact, we implemented a Sabbath mode to allow observant Jews to ride the elevator on Shabbat while refraining from using any electric devices.  However, the buttons that control our elevator are not marked with Braille, so it will be difficult for blind people to operate.  In a real version of this elevator, however, it would be easy to add Braille. 
 

Appendix

Schematics and Data Sheets

All schematics and links to data sheets can be found in their respective sections above.

Budget

Item	Cost
3 PF35T-48L4 stepper motors	$3.00
2 white boards	$12.00
1 STK500 w/ Atmel Mega32	$15.00
3 ULN2003AN Darlington arrays	$1.92
1 2-pin flat jumper cable	$1.00
1 12 Volt Power Supply	$5.00
12 Pushbuttons	Free (in lab)
K’NEX	Free (already owned)
2 Wooden Boards	$3.00
3 Wooden Dowels	$1.50
Twine	Free (Scavenged)
Nails	Free (Scavenged)
Total	$42.42

Specific Tasks

Building Elevators – Shared
MATLAB Code – Andrew
C Code – Shared
Circuit Design – Dylan
Testing and Debugging – Shared

Code

Elevator.c

Elevator.m

Sendbutton.m

Matlab GUI Images

Video
Here

References

Consulting: Prof. Bruce Land, Eric Okawa

Datasheets: ULN2003AN

Matrix Algebra in R

Matrix Algebra

Most of the methods on this website actually describe the programming of matrices. It is built deeply into the R language. This section will simply cover operators and functions specifically suited to linear algebra. Before proceeding you many want to review the sections on Data Types and Operators.

Matrix facilites

In the following examples, A and B are matrices and x and b are a vectors.

Operator or Function	Description
A * B	Element-wise multiplication
A %*% B	Matrix multiplication
A %o% B	Outer product. AB'
crossprod(A,B) crossprod(A)	A'B and A'A respectively.
t(A)	Transpose
diag(x)	Creates diagonal matrix with elements of x in the principal diagonal
diag(A)	Returns a vector containing the elements of the principal diagonal
diag(k)	If k is a scalar, this creates a k x k identity matrix. Go figure.
solve(A, b)	Returns vector x in the equation b = Ax (i.e., A-1b)
solve(A)	Inverse of A where A is a square matrix.
ginv(A)	Moore-Penrose Generalized Inverse of A. ginv(A) requires loading the MASS package.
y<-eigen strong="">	y$val are the eigenvalues of A y$vec are the eigenvectors of A
y<-svd strong="">	Single value decomposition of A. y$d = vector containing the singular values of A y$u = matrix with columns contain the left singular vectors of A y$v = matrix with columns contain the right singular vectors of A
R <- chol="" strong="">	Choleski factorization of A. Returns the upper triangular factor, such that R'R = A.
y <- qr="" strong="">	QR decomposition of A. y$qr has an upper triangle that contains the decomposition and a lower triangle that contains information on the Q decomposition. y$rank is the rank of A. y$qraux a vector which contains additional information on Q. y$pivot contains information on the pivoting strategy used.
cbind(A,B,...)	Combine matrices(vectors) horizontally. Returns a matrix.
rbind(A,B,...)	Combine matrices(vectors) vertically. Returns a matrix.
rowMeans(A)	Returns vector of row means.
rowSums(A)	Returns vector of row sums.
colMeans(A)	Returns vector of column means.
colSums(A)	Returns vector of coumn means.

Matlab Emulation

The matlab package contains wrapper functions and variables used to replicate MATLAB function calls as best possible. This can help porting MATLAB applications and code to R.

Solving school bus routing problem (SBRP) using gurobi solver in matlab interface

We have sbrp model to optimize:

min sum_{ij} D_{ij} . x_{ij}

subject to

for all i \in (1,2,...,n), sum_{j=1}^{n} x_{ji} <2 br="" column="" constraint="" linear="" matrix="" n="" nbsp="" of="" sum="" variable="">for all i \in (1,2,...,n), sum_{j=1}^{n} x_{ij} <2 br="" constraint="" linear="" matrix="" n="" nbsp="" of="" row="" sum="" variable="">for all i \in (1,2,...,n), sum_{j=1}^{n} x_{ji} + sum_{j=1}^{n} x_{ij} >=1 (row+column sum of variable matirx), n linear constraint
sum_{ij} x_{ij} = n-1 (matrix sum of variable matrix), 1 linear constraint

%so basically we have following for gurobi model:
        model.A = sparse(cm); % cm is a constraint matrix of 3n+1 linear constraint
        model.obj = ofun; % ofun is a vector of distance matrix
        model.rhs = rhs_val; % rhs_val is right hand side value of 3n+1 constraints
        for i=1:2*n
            sense_vec(i)='<'; %for first 2*n constraint
        end
        for i=2*n+1:3*n
            sense_vec(i)='>';% for next n constraint
        end
        sense_vec(num_cons)='='; for last 1 constraint
        model.sense = sense_vec;
        model.vtype = 'B';%Variable type is binary, x is either zero or one
        model.modelsense = 'min'; %minimization problem

        clear params;
        params.outputflag = 0;
        params.resultfile = 'gurobi_sbrp.lp';%save result        
        result = gurobi(model, params);%call gurobi optimizer
        disp(result)

% for given distance matrix D and bus stop numbered from 1 to 12 we have following output:

2 -> 1    3 -> 2    4 -> 3    5 -> 6    6 -> 5    7 -> 8    8 -> 4    9 -> 10    10 -> 9    11 -> 12    12 -> 11

% so here we are getting 3 cyclic route plus one acyclic e.i. 5->6->5, 9->10->9, 11->12->11, and 7->8->4->3->2->1

How to remove these cyclic routes (basically make active variables zero which are making cyclic route and search for another)

Please help me,

If anyone needs whole program and data set of this code, I will be happy to share it.

Thanking you,
Ajay
  

bengu

Jun 12

Pls look for sub-tour elimination constraints in vrp literature.

MATLAB Commands for Set Operations

SET_THEORY is a MATLAB library which demonstrates how set-theoretic operations can be carried out, primarily using built-in MATLAB commands.
We assume that a set is represented by a strictly ascending sequence of positive integers. We might think of a universal set U = 1 : N in cases where all our subsets will have elements between 1 and N.
Set theoretic operations include

• definition using a numeric property: A = find ( mod ( U, 3 ) = 1 );
• definition using an explicit list: A = [ 1, 3, 8];
• unique: creating a set from the unique elements of a list: A = unique ( [ 1, 3, 8, 3, 3, 1, 7, 3, 1, 1 ] );
• union: C = union ( A, B );
• intersection: C = intersect ( A, B );
• symmetric difference: C = setxor ( A, B );
• complement with respect to the universal set: B = setdiff ( U, A );
• complement with respect to another set: C = setdiff ( B, A );
• cardinality: n = length ( A );
• membership: true/false = ismember ( a, A );
• subset: true/false = ismember ( B, A );
• addition of one element: A = unique ( [ A; a ] );
• deletion of one element: A = setxor ( A, a );
• indexing one element: i = find ( A == a );

7 Ways to Make Presentations More Convincing

Presentations are more persuasive when they touch both mind and heart at multiple levels.

Getty

1,648
inShare

The point of a presentation is to convince decision-makers to make a public commitment to whatever you're selling, according to G. Richard Shell and Mario Moussa, co-authors of the excellent book The Art of Woo. Here's how:

1. Make it vivid.

Rather than abstract concepts ("reduces costs," "increases productivity") use concrete, real-life examples that carry emotional heft with the audience ("saved ABC $1 million," "prevented XYZ from going bankrupt.")

2. Put your heart into it. 

If you don't really believe in yourself, your firm, and its offerings, you'll persuade nobody.  And it's not enough to simply believe... it must be obvious to the audience that you're a true believer.

3. Tell a story. 

Humans use stories to order events so that they make sense to their daily lives. Your presentation should have a hero who overcomes obstacles to achieve a goal. BTW, the hero must be the customer, not you.

4. Personalize your examples.

A presentation should cause an emotional shift from being "undecided" to being "certain."  This is only possible if your presentation is relevant to your audience's work and life experiences.

5. Make it a puzzle. 

If there's some mystery to your presentation, your audience will get involved solving it. So don't reveal everything up front, especially when you're telling a story. Let the story evolve into a meaningful ending.

6. Use telling metaphors. 

Drawing parallels with the familiar helps the audience grasp complex ideas. Example: "Photolithography becomes problematic at 180nm." Or, in other words, "It's like trying to draw a blueprint with a hunk of chalk."

7. Force them to think.

True decision-makers are quickly bored by ideas and information that they already understand. Instead, they crave opportunities to exercise their brainpower to learn something new and insightful.
Like this post? If so, sign up for the free Sales Source newsletter.

AIC Vs BIC, I know that they try to balance good fit with parsimony, but beyond that I’m not sure what exactly they mean

I often use fit criteria like AIC and BIC to choose between models. I know that they try to balance good fit with parsimony, but beyond that I’m not sure what exactly they mean. What are they really doing? Which is better? What does it mean if they disagree?


As you know, AIC and BIC are both penalized-likelihood criteria. They are sometimes used for choosing best predictor subsets in regression and often used for comparing nonnested models, which ordinary statistical tests cannot do. The AIC or BIC for a model is usually written in the form [-2logL + kp], where L is the likelihood function, p is the number of parameters in the model, and k is 2 for AIC and log(n) for BIC.

AIC is an estimate of a constant plus the relative distance between the unknown true likelihood function of the data and the fitted likelihood function of the model, so that a lower AIC means a model is considered to be closer to the truth. BIC is an estimate of a function of the posterior probability of a model being true, under a certain Bayesian setup, so that a lower BIC means that a model is considered to be more likely to be the true model. Both criteria are based on various assumptions and asymptotic approximations. Each, despite its heuristic usefulness, has therefore been criticized as having questionable validity for realworld data. But despite various subtle theoretical differences, their only difference in practice is the size of the penalty; BIC penalizes model complexity more heavily. The only way they should disagree is when AIC chooses a larger model than BIC.

AIC and BIC are both approximately correct according to a different goal and a different set of asymptotic assumptions. Both sets of assumptions have been criticized as unrealistic. Understanding the difference in their practical behavior is easiest if we consider the simple case of comparing two nested models. In such a case, several authors have pointed out that IC’s become equivalent to likelihood ratio tests with different alpha levels. Checking a chi-squared table, we see that AIC becomes like a significance test at alpha=.16, and BIC becomes like a significance test with alpha depending on sample size, e.g., .13 for n = 10, .032 for n = 100, .0086 for n = 1000, .0024 for n = 10000. Remember that power for any given alpha is increasing in n. Thus, AIC always has a chance of choosing too big a model, regardless of n. BIC has very little chance of choosing too big a model if n is sufficient, but it has a larger chance than AIC, for any given n, of choosing too small a model.

So what’s the bottom line? In general, it might be best to use AIC and BIC together in model selection. For example, in selecting the number of latent classes in a model, if BIC points to a three-class model and AIC points to a five-class model, it makes sense to select from models with 3, 4 and 5 latent classes. AIC is better in situations when a false negative finding would be considered more misleading than a false positive, and BIC is better in situations where a false positive is as misleading as, or more misleading than, a false negative.

HMM R Code

	HMM-FDR.zip	14-Sep-2007 10:17	44K
	bwfw.hmm.R.txt	13-Sep-2007 16:37	3.8K
	bwfw1.hmm.R.txt	13-Sep-2007 16:37	3.3K
	em.hmm.R.txt	13-Sep-2007 16:55	2.7K
	em1.hmm.R.txt	30-Jun-2007 17:50	2.3K
	hivdata.txt	12-Jul-2007 17:06	78K
	mt.bh.R.txt	08-May-2007 22:27	688
	mt.gw.R.txt	26-Jul-2007 19:31	809
	mt.hmm.R.txt	30-Jun-2007 17:50	915
	rdata.hmm.R.txt	13-Sep-2007 15:48	1.4K
	rdata1.hmm.R.txt	30-Jun-2007 17:50	1.1K
	readme.txt	13-Sep-2007 18:03	4.6K

An example of EM for HMM, MLE for HMM and backward, forward algorithms for HMM

# This document contains four main files: 
  # function 'rdata.hmm' (rdata1.hmm) is the HMM data generator
  # function 'bwfw.hmm' (bwfw1.hmm) realizes the forward-backward procedure
  # function 'em.hmm' (em1.hmm) realizes the E-M algorithm
  # function 'mt.hmm' realizes the new multiple testing procedures 
    # (given the estimates of HMM parameters)

# Examples on how to use these functions are given below. 

# R codes for other multiple testing procedures are also included for the comprehensive Example 5:
  # function 'mt.bh' realizes the BH step-up procedure 
  # function 'mt.gw' realizes the adaptive p-value procedure

# More detailed instructions are given in each separate file. 

###############################
######   EXAMPLES   ###########
###############################

source("rdata1.hmm.R.txt")
source("rdata.hmm.R.txt")
source("bwfw1.hmm.R.txt")
source("bwfw.hmm.R.txt")
source("em1.hmm.R.txt")
source("em.hmm.R.txt")
source("mt.hmm.R.txt")
source("mt.gw.R.txt")
source("mt.bh.R.txt")

 # the number of observations
NUM1<-1000 0.05="" 0.2="" 0.3="" 0.80="" 0="" 1:="" 1:hiv.num="" 1="" 2:="" 2="" 3:="" 3="" 4:="" 5:="" a0.hiv="" a0="" a="" algorithm="" alternative="" analysis="" and="" ap="" b="" backward.var="" backward="" bh="" bw="" bwfw.hmm="" bwfw1.hmm="" byrow="TRUE)" c="" data="" de="" decision="" distribution="" e-m="" em.hmm="" em.res1="" em.res2="" em1.hmm="" em="" estimates="" example="" f0="" f1.v="" f1="" fb.res1="" fb.res2="" fdr="" for="" forward-backward="" forward.var="" fw="" generator="" gw.de="" gw.res="" hiv.ap="" hiv.bh="" hiv.lsi="" hiv.num="" hiv.pi="" hiv.pv="" hiv.res="" hiv="" hivdata.txt="" hmm="" hypotheses="" in="" indices="" initial="" interations="" j="" l="2," length="" level="" lf="" lsi.or="" lsi.pi="" lsi.var="" lsi="" matrix="" maxiter="500)" min="" mixture="" mt.bh="" mt.gw="" mt.hmm="" n1="" non-nulls="" normal="" nr="" null="" num="" number="" o="" observed="" of="" one-component="" or.de="" or.res="" or="" p-value="" p-values="" p0.hiv="" p0="" parameters="" pc="" pi.de="" pi.res="" pi="" pii="" pnorm="" pre="" prespecified="" procedure="" procedures="" proportion="" pv1="" q="" rdata.hmm="" rdata1="" rdata2="" re="" rejected="" rejections="" rule="" s="" scan="" set.seed="" state="" states="" th="" the="" theta1="" three-component="" threshold="" transition="" unobserved="" values="" variable="" x1="" x2="">
 
 
 
 
 
 Available at http://www-stat.wharton.upenn.edu/~tcai/paper/Softwares/FDR-HMM-R-Code/readme.txt