[RC5] Stats suggestion

Herman Verkade Herman.Verkade at iqware.co.uk
Fri Jan 5 21:14:49 EST 2001


Can't that same value not be calculated through:

for (i = 0, avg = 0; i < maxdays; i++) avg += rate[i] * k2 * pow (k1, i);

where i==0 is today, i==1 is yesterday etc?? And maxdays refers to the
number of days that the project has been going.

Herman

BTW: If it's too much work to calculate the values, then maybe we can do it
as a distributed.net project? ;->

> -----Original Message-----
> From: Kelly Byrd [mailto:kbyrd at rotor.net]
> Sent: 05 January 2001 20:05
> To: rc5 at lists.distributed.net
> Subject: RE: [RC5] Stats suggestion
> 
> 
> I think the "catch up" period refers to getting a 
> "yesterdays_avg" today.
> You start somewhere and go thru all the historical data once. 
> The other
> option is to ignore our historical rates and start everyone's 
> average today.
> To do that use 0 as "yesterdays_avg"
> 
> KB
> 
> -----Original Message-----
> From: Dan Petrak [mailto:dpetrak at fct.com]
> Sent: Friday, January 05, 2001 11:56 AM
> To: rc5 at lists.distributed.net
> Subject: RE: [RC5] Stats suggestion
> 
> 
> The "catch up" that you're thinking of...  Does this mean you 
> can't just
> suppress the field until the participant has been active for 
> enough days to
> generate the first decay period?
> 
> Regards,
> Daniel C. Petrak
> Senior System Administrator
> The FCT Group of Companies
> ---------------------------
> This e-mail message and the information it contains are 
> confidential and are
> intended solely for the use of the intended addressee(s).  
> Any unauthorized
> disclosure, use or dissemination, either whole or in part, is 
> prohibited.
> If you are not the intended recipient(s) of the message, 
> please notify the
> sender immediately by e-mail reply.
> 
> 
> -----Original Message-----
> From: bwilson at fers.com [mailto:bwilson at fers.com]
> Sent: Friday, January 05, 2001 7:37 AM
> To: rc5 at lists.distributed.net
> Subject: Re: [RC5] Stats suggestion
> 
> 
> Wow, great idea.  That would solve all of my issues, and would only
> require one additional field per participant/team.  Thanks 
> also to Flower
> for suggesting the same thing, though yours was a lot easier to
> understand.
> 
> It sounds like there would be a somewhat complex "catch-up" 
> process to get
> all the averages into place.
> 
> Do you have a formula handy for calculating k1 and k2 to 
> obtain a given
> half-life?
> 
> Unfortunately, what I said about SBIII still holds... I don't think we
> should attempt this until we have a more robust and reliable 
> platform. But
> I can start designing it in my head.
> 
> Now I'm really glad I went to the trouble of explaining what I was
> thinking.
> __
> Bruce Wilson, Manager, FERS Business Services
> bwilson at fers.com, 312.245.1750, http://www.fers.com/
> PGP KeyID: 5430B995, http://www.lasthome.net/~bwilson/
> "A good programmer is someone who looks
> both ways before crossing a one-way street."
> 
> 
> 
> 
> Ben Clifford <benc at hawaga.org.uk>
> Sent by: owner-rc5 at lists.distributed.net
> 2001-01-05 06:04
> Please respond to rc5
> 
> 
>         To:     rc5 at lists.distributed.net
>         cc:
>         Subject:        Re: [RC5] Stats suggestion
> 
> 
> 
> Have you considered an "exponential decay" average?
> 
> This is a weighted average, where the more recent values have a bigger
> weight than values in the past - values in the distant past 
> have such a
> tiny weight that they are insignificant.
> 
> Its advantage from a distributed.net point of view is that it 
> only needs
> one piece of historical data, yesterdays exponential average.
> 
> It can be computed as:
> 
> todays_avg = k1 * yesterdays_avg + k2 * todays_count;
> 
> with suitably chosen (related) k1 and k2 constants.
> 
> Varying the constants changes the "decay rate" of the average 
> - I would
> think for distributed.net, half lives of 7-days, 30-days and 
> 60-days would
> probably be appropriate.
> 
> For people who use unix, this is how load averages from the 
> uptime command
> are computed.
> 
> This metric needs very little storage and is quick to compute. It
> gradually "forgets" about old data.
> 
> It is not as "jumpy" as a n-day average - if I have a spike, then my
> 30-day average will jump up and in 30 days will suddenly drop
> significantly. With this metric, it will gradually fade out.
> 
> I'm not sure how well I have explained this... please ask 
> questions :-)
> 
> Ben
> 
> --
> http://www.custom-networks.co.uk/
> 
> --
> To unsubscribe, send 'unsubscribe rc5' to 
> majordomo at lists.distributed.net
> rc5-digest subscribers replace rc5 with rc5-digest
> 
> 
> 
> 
> 
> --
> To unsubscribe, send 'unsubscribe rc5' to 
> majordomo at lists.distributed.net
> rc5-digest subscribers replace rc5 with rc5-digest
> --
> To unsubscribe, send 'unsubscribe rc5' to 
> majordomo at lists.distributed.net
> rc5-digest subscribers replace rc5 with rc5-digest
> --
> To unsubscribe, send 'unsubscribe rc5' to 
> majordomo at lists.distributed.net
> rc5-digest subscribers replace rc5 with rc5-digest
> 

--
To unsubscribe, send 'unsubscribe rc5' to majordomo at lists.distributed.net
rc5-digest subscribers replace rc5 with rc5-digest



More information about the rc5 mailing list