swarm-support
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: static vars


From: Rick Riolo
Subject: Re: static vars
Date: Mon, 28 Sep 1998 17:48:07 -0400 (EDT)

I think I begin to see what you want.
I think you want static in a method to act like static in a function,
*except* you also want it to be unique for each instance...is that it?
I don't know what the specs for objective-C say about
static storage inside methods, but I'd be surprised
if it would say its supposed to be unique for each instance.
So I'm not so sure this is a problem with a particular implementation.
 - r

Rick Riolo                           address@hidden
Program for Study of Complex Systems (PSCS)
4477 Randall Lab                
University of Michigan         Ann Arbor MI 48109-1120
Phone: 734 763 3323                  Fax: 734 763 9267
http://www.pscs.umich.edu/PEOPLE/rlr-home.html

On Mon, 28 Sep 1998, donalson wrote:

> Date: Mon, 28 Sep 1998 14:34:13 -0700
> From: donalson <address@hidden>
> To: address@hidden
> Subject: Re: static vars
> 
> Sorry,
> 
>    My last post wasn't clear, it was just a warning to Cygnus users.
> The background is this:
> 
> I realized that I had a Swarm "movie player" if I just played my data
> files back through my simulation (with some slight mods to my sim.)  In
> fact it needed only one object, plus model and observer.  It also helped
> solve a second problem.  I have a HUGH amount of data per sim run, one
> file for each of 440 cells and each cell saves 61 variables per time step
> for 3000 timesteps.  I use the data player to also make stripped down data
> sets of particular variables I am investigating.
> 
> Agents can enter or leave cells to 20 nearest neighbors and I keep track
> of where they come from and where they go.  Unfortunatly, rather stupidly,
> I keep a running sum instead of just the number per time step.  The
> obvious solution to this is to read in the array (size 20 ints) save it,
> read in the same array for the next time step, subtract them, and then
> save the new array as the old, and repeat.
> 
> I started by making "oldData[20]" static, but I discovered that the data
> in it was getting changed from one iteration to the next.  I could verify
> that it was correct just prior to exiting the method, but at next access,
> it had changed.  It is not improbable that this is caued by mishandling of
> static vars when there are multiple insances of the same object.  This is
> just a guess but the incorrect data was all within the expected range of
> the variables, just the incorrect for that instance.  I tried it with a
> single variable and found the same problem.  I should note that these vars
> are not accessed outside the object, and the variable names are used
> nowhere else in the simulation.
> 
> Since I needed a persistent variable, my next thought was to move the
> static variables to the object definition (removing the "static" part of
> the definition).  The make consisted only of the data object (I had
> changed nothing else) and the result was that the schedule did not run!
> It went through initialization and put up the displayes and then just sat
> there.
> 
> I finally got it to run correctly by doing a "make clean" prior to
> recompile.  I think the moral of the story may be Cygnus has some trouble
> with static variables.
> 
> Cheers,
> 
>    D3
> 
> Marcus Daniels wrote:
> 
> > >>>>> "D3" == donalson  <address@hidden> writes:
> >
> > D3> It is not happening.
> >
> > What is not happening?  You need to explain what you want and expect
> > to happen, identify some common reference frame, and show us the
> > suspect mechanics before we can possibly help.
> >
> > I guess you want to do some processing based on some vector state
> > change, apparently chunking from some input file, but it is hard to
> > tell with the information you've provided.
> >
> > D3>   Since you and I agree on that, I have to believe that there is
> > D3> something weird in Cygnus.
> >
> > You mean contrasted against some other environment?
> >
> >                   ==================================
> >    Swarm-Support is for discussion of the technical details of the day
> >    to day usage of Swarm.  For list administration needs (esp.
> >    [un]subscribing), please send a message to <address@hidden>
> >    with "help" in the body of the message.
> >                   ==================================
> 
> --
> *********************************************************************
> * Doug Donalson                 Office: (805) 893-2962
> * Ecology, Evolution,           Home:   (805) 961-4447
> * and Marine Biology            email address@hidden
> * UC Santa Barbara
> * Santa Barbara Ca. 93106
> *********************************************************************
> *
> *   The most exciting phrase to hear in science, the one that
> *   heralds new discoveries, is not "EUREKA" (I have found it) but
> *   "That's funny ...?"
> *
> *       Isaac Asimov
> *
> *********************************************************************
> 
> 
> 
>                   ==================================
>    Swarm-Support is for discussion of the technical details of the day
>    to day usage of Swarm.  For list administration needs (esp.
>    [un]subscribing), please send a message to <address@hidden>
>    with "help" in the body of the message.
>                   ==================================
> 

                  ==================================
   Swarm-Support is for discussion of the technical details of the day
   to day usage of Swarm.  For list administration needs (esp.
   [un]subscribing), please send a message to <address@hidden>
   with "help" in the body of the message.
                  ==================================


reply via email to

[Prev in Thread] Current Thread [Next in Thread]