Re: fractional time values in an integer Schedule (sort of)

[cal]

hihi, all -

apparently, i was somewhat too cryptic again (it happens rather often 8-() -
my proposal for a solution has nothing particularly to do with swarm, since it
can be applied in many kinds of modeling of dynamic systems, when an integer
is needed and a non-integer is computed

in the original message (appended below), Andre Costa was computing a "number
of packets" to send out from a "network node" (these are all terms in his
model) in a unit time interval, but had a conflict between the integer number
of packets he wants to use for this "number", and the rate x(t) of packet
production, which was most likely a fraction - his equation is

        x(t+1) = x(t) +  k*F( ),

with F() a computed integer value and k a small positive real number

my solution was to use the integer part of x(t) and make the fractional part a
random integer with the right expected value, and add the two together, as in
the following example

if the number x(t) is not an integer (e.g., 2.43), then take the integer part
of the number (i.e., 2) and send out 2 packets in the usual way (what that
actually means depends on the details of Andre's simulation model) - then,
take the fractional part of the number (which is 0.43 in this example), and,
with that same probability (0.43), send out one more packet in that same time
interval - in this case, either 2 packets (with probability 0.57) or 3 packets
(with probability 0.43) will be sent

using this stochastic method, the actual number of packets sent in a unit time
interval is always an integer, and it also makes the actual rate have expected
value the same as the computed rate x(t) - therfore, in the long run, it
should work exactly rather than approximately (so if that level of long-term
expected accuracy doesn't matter very much, alex's method is much simpler)

finally, i would also record the actual values computed for the number of
packets sent, and use it to backcompute an "actual F()" for instrumentation
purposes

this "backcomputing" means solving the above equation for F(), given the
constant parameter k and the actual integer values that were computed from
x(t+1) and x(t) - that is, using the integer numbers of packets that were
sent, counting also the random part, instead of the (most likely) non-integer
values for x(t) originally computed from the equation above - i called it
"backcomputing" because the process is computing backwards - using an equation
(the one above) that was originally intended to be used in one particular
direction in the reverse direction - the method (though not the term) is
commonly used for instrumentation of complex dynamic systems

if the resulting time history or distribution of F() values is unreasonable
(which criterion can only be determined by knowing the rest of the model),
then there is a sensitivity in the model that needs to be examined more
carefully - these (most likely non-integer) F() values are the ones that would
have generated exactly the integer adjusted values actually used for the
number of packets sent in each time interval

i hope this clears up a bit what i had in mind

more later,
cal

andre costa's original message
> Hi,
>
> In my simulation, I have some source nodes in a network (TCP-like) which
> send out discrete packets, and the sources also update their source rates
> x(t) (packets/timestep) according to an adaptive rule
>
> x(t+1) = x(t) +  k*F( )
>
> where k is a "gain" parameter and F( ) is a function which returns an
> integer.
>
> Since x(t) is the number of packets which a source emits in one simulation
> time step, then the this number must be an integer.
>
> However, I need to have a fractional gain parameter, k, which may also
> be interpreted as a "learning rate". Currently, I am constrained to having
> integer values of k, but even k=1 is way too large for my purposes
> (oscillations, etc.)
>
> If x(t) were to be defined as a FLOAT instead of an INT, then what
> scheduling mechanism could deal with say, 2.5 packets per time step,
> whilst still scheduling an integer (by necessity) number of dicrete
> packets per timestep in some reasonable fashion ?
>
> I have thought about defining say, 100 basic Swarm time steps to
> represent 1 simulated time unit, and thus obtaining fractional values
> which resolve to 1/100 of a simulated time unit, but some kind of binning
> would still be required and I wonder if anybody knows of a better
> system....
>
>
> thanks,
> Andre Costa


                  ==================================
   Swarm-Modelling is for discussion of Simulation and Modelling techniques
   esp. using Swarm.  For list administration needs (esp. [un]subscribing),
   please send a message to <address@hidden> with "help" in the
   body of the message.
                  ==================================