On 8/26/07, Joe Wells <[EMAIL PROTECTED]> wrote: > > "Kai Antweiler" <[EMAIL PROTECTED]> writes: > > Oh, I see. You meant something different. > > When you wrote: > > "Probably the time the globs take should be adjusted based on their > > speed to get instead the time the "average" glob _would_ have taken." > > > > Probably corresponding to my comment: > > "We can reduce this effect somewhat, if we (let's say) multiply the > > time by the speed of the globs and maybe divide by the average speed." > > > > Dividing by the speed of the glob would not achieve anything. We would > and > > up with the original time again. So I assume you meant we could skip > the > > normalizing, but keep the speed times time. > > Now I think: you want to skip both. > > I'm not sure I'm following. Anyway, this seems to be discussion of > very low level details that would no doubt need lots of tuning and > adjustment. So I'm not sure it is worthwhile for me to try to > understand. It would be easier to comment on a concrete > implementation.
Sounds like someone needs a genetic algorithm. >> Also, what about traffic congestion? > > > > I don't know. I always assume that globs always move and never stand > still > > if they have a spot they can go to. So traffic congestions would just > increase > > the length of the path. > > But now I think that is wrong, because unemployed globs are said to be > consuming > > less food. > > My point was that it doesn't help a globule to be faster if traffic > congestion causes it to spend lots of time moving back and forth > without making real progress. So we would not want to try to adjust > the actual time too much based on speed differences, because that > would lose valuable information about traffic conditions. > > -- > Joe > > > -- Extra cheese comes at a cost. Bradley Arsenault.
_______________________________________________ glob2-devel mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/glob2-devel
