Extension to Syntax of PEPA Models for General Distributions ------------------------------------------------------------ Activity rates are no described using an extended syntax. Previously we'd have somethink like r1, or s, as a part of (a,s), say. Now we extend this to allow a rate to look like Normal(m,d), so we can have activities like (a, Normal(m,d)). If a string only is presented, then it is assumed to be exponential. Choices: o Normal(m,d) [ N(m,d) ] o Exp(m) [ E(m) ] o Det(m) [ D(m) ] o Uniform(a,b) [ U(a,b) ] Only Normal and Exp are implemented at the moment (well, not yet - am about to implement them) Note that it's an error to include a passive tag inside *any* of these distribution labels. Passive multipliers are only used to resolve conflicts probabilistically. How to Resolve Races Between General Distributions -------------------------------------------------- 1. More than one derivative First note that there may be more than one derivative - consider the following processes (a,2) <a> ( (a,3T) + (a,2T) ) The passive activities won't have clocks set, and so when the (a,2) finishes, there'll always be two to choose from. 2. How about (a,2) <a> ( (a,8) + (a,9) ) The rules for PEPA dictate that the synchronisation must go ahead at either 2.(8/17) or 2.(9/17) depending on a probabilistic choice over the rates of the second process. This is time-independent due to the nature of the exponentials. What should we do in the general case? Well, we should decide that we always wait for the slowest, but how do we calculate this at a mathematical level? With PEPA, the slowest is always the one with the lower rate, even though in practise, this might not always finish first. These two ideas are not equivalent because of the exponential, because by the rules, min(2,3) should be 2. However, surely the 3 could contribute to being slower some of the time. So I conclude it's a rule imposed from above. It'd be nice to give the whole thing a race interpretation, cause then I'd code the whole general thing as a race too. But what happens in this case? 3. When are processes started? (b,3).(a,2) <a> ( (a,3) + (a,4) ) it's a coop, so do I set both sides off straight away? Then when the b's finished, the RHS will have completed some of its race. Do I then discard this used lifetimes by assuming the (a,2) will enforce the lifetime of the cooperation? This one isn't a problem, cause we can assume the RHS doesn't start to do anything until the left hand a becomes enabled. So we can guarantee, and we should, that when a cooperation is active, all activities start at the same point. Why is this argument correct? Because PEPA says that a cooperation must involve both parties - it's a communication, not just a "wait for me". 4. Not true. Consider this process (a,4) <a> ( (b,1).(a,2) <> (b,2).(a,3) ) each b will finish at different times. Say (b,1) finishes first. Then (a,2) is enabled (2 is less than 4). Then (b,2) might finish. Now we should enable (a,4), since 4 < 2+3 - and then choose probabilistically. Is this right? Part of (a,2)'s clock will have run down. Perhaps I should keep (a,2)'s clock value, make a draw for (a,3), and when the (a,4) finishes, make a prediction based on the clock draws...? Further question - can this result in oscillation? I suppose the dominant factor in any cooperation could change from side to side as more actions looking like the b above finish on either side. What should be the rule? So when a new one is enabled, we should count up the apparent rates on both sides of the cooperation. Perhaps this should be current What strategy can we use to ensure that Jane's "always the slowest" rule is obeyed? Use the example given above. Say (b,1) finishes first. I guess then we *immediately* enable both sides of the cooperation - the 4 and the 2. Jane's rule is that we choose with exponential parameter 2 - always the slowest. Certainly this isn't the same as racing them and taking the minimum, cause sometimes the 2 would win out, probabilistically. So it's an artificial restriction. However, this means we run both clocks, but we wait for the 2 ONLY (or we could only run 2's clock?) Now say (b,2) finishes. The slower becomes the 4, since the 2 and 3 sum to make 5. HOWEVER, also consider that 2's clock has been running down. We can choose many interpretations, so we should go with one, but flag the situation if we ever have to make this choice. [hmm, isn't it the case that since 4 is cooperating with 2 and 3, separately, that the race should still be between the 2 and 3? Well perhaps not due to the way it's bracketed. It's 4 with (2 or 3). Fair enough] 5. When is it an error situation? When a cooperation is enabled, a transition is made, and another cooperation is enabled, where part of one's clock has ran down. We have to make some decision about cooperations. Really, to follow PEPA, it should just be one clock running, the slower one. The faster one can run, but it firing doesn't make the whole process fire. 29/01/99 What if we just use a race interpretation, and that cooperating means the slowest decides? CVS Tags -------- peparoni-0-1 released experimentally! See the Pepa web page peparoni-150299-broken-symbolic-rates: 1.4 This version includes the model for the PAPM99 paper (a database), and improves Peparoni with the ability to include symbolic rate names (as long as the symbol is given a value using the % syntax, and also C++ style comments. The passive checking is still broken. peparoni-120299-broken-passives: 1.3 I discovered that there is a bug when considering passive activities. For example, what should happen in this case: (a,4) <a> ( (a,2T) + (a,3) ) The apparent rate has a n + T term on the denominator which can't be simplified. This example should flag a warning. However, see the comments in Process.pizza for more problems - race conditions, and how to interpret them... Also removed some huge commented out chunks of code. peparoni-260199-working-untidy: 1.3 Seems to be working, i.e. simulating with the use of interp.pl, but there are great swathes of code which should be removed. engine-working: 1.1.1.1
Name Last modified Size Description
COPYING 1999-05-14 15:02 18K INSTALL 1999-07-27 21:13 931 Makefile 1999-06-11 16:59 847 Makefile.config 1999-07-27 17:35 1.0K bin/ 1999-07-27 21:30 - models/ 1999-07-27 21:30 - pepa/ 1999-07-27 21:30 - simjavaextensions/ 1999-07-27 21:30 -