[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: fractional time values in an integer Schedule
From: |
Alex Lancaster |
Subject: |
Re: fractional time values in an integer Schedule |
Date: |
23 Jun 2000 00:12:29 -0600 |
User-agent: |
Gnus/5.0803 (Gnus v5.8.3) Emacs/20.6 |
>>>>> "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.
==================================