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 Makefile 1999-06-11 16:59 847 Makefile.config 1999-07-27 17:35 1.0K INSTALL 1999-07-27 21:13 931 bin/ 1999-07-27 21:30 - models/ 1999-07-27 21:30 - pepa/ 1999-07-27 21:30 - simjavaextensions/ 1999-07-27 21:30 -