Re: fractional time values in an integer Schedule

[Alex Lancaster]

>>>>> "AC" == Andre Costa <address@hidden> writes:

AC> Hi, My question is about how to deal with the limitations of an
AC> integer time step schedule in Swarm, although I am sure this is a
AC> generic simulation issue for any discrete-event scheduling
AC> simulator.

AC> In my simulation, I have some source nodes in a network (TCP-like)
AC> which send out discrete packets, and the sources also update their
AC> source rates x(t) (packets/timestep) according to an adaptive rule

AC> x(t+1) = x(t) + k*F( )

AC> where k is a "gain" parameter and F( ) is a function which returns
AC> an integer.

AC> Since x(t) is the number of packets which a source emits in one
AC> simulation time step, then the this number must be an integer.

AC> However, I need to have a fractional gain parameter, k, which may
AC> also be interpreted as a "learning rate". Currently, I am
AC> constrained to having integer values of k, but even k=1 is way too
AC> large for my purposes (oscillations, etc.)

AC> If x(t) were to be defined as a FLOAT instead of an INT, then what
AC> scheduling mechanism could deal with say, 2.5 packets per time
AC> step, whilst still scheduling an integer (by necessity) number of
AC> dicrete packets per timestep in some reasonable fashion ?

AC> I have thought about defining say, 100 basic Swarm time steps to
AC> represent 1 simulated time unit, and thus obtaining fractional
AC> values which resolve to 1/100 of a simulated time unit, but some
AC> kind of binning would still be required and I wonder if anybody
AC> knows of a better system....

Nope, you've hit the solution pretty much on the mark.  Swarm is a
discrete event simulator by design. The trick is choosing your
timestep magnification resolution to the most appropriate value, one
that gives you a minimal error due to the inherent roundoff of
truncating the non-integer timesteps, without being excessively
fine-grained.

There is a feature in the original design spec to be able to specify
relative timestep magnifications for Swarms-within-Swarms, but it's
currently unimplemented.  [If a number of SDG members were to begin
requesting these features, obviously they would go up in priority...]

Of course, choosing an optimum timestep magnification is pretty
application dependent.  [Of course all programs that run on a digital
computer are all ultimately discrete at some level, but that's another
discussion entirely... ;-)]

Alex
-- 
Alex Lancaster * address@hidden * www.santafe.edu/~alex * 505 984-8800 x242
Santa Fe Institute (www.santafe.edu) & Swarm Development Group (www.swarm.org)


                  ==================================
   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.
                  ==================================