Looking at code before r16603:
double wu_est = result->estimated_duration(for_work_fetch); //seconds
double frac_est = (elapsed_time / fraction_done) - elapsed_time; //seconds
double fraction_left = 1-fraction_done; //0..1
double x = fraction_done*frac_est + fraction_left*fraction_left*wu_est;
f
Thanks :)
(and also :))) that the code _was_ right after all...)
J
On 7 Jul 2009, at 19:12, David Anderson wrote:
> I was thinking something like that, but actually it's right the way
> it is;
> frac_est is an estimate time remaining,
> and wu_est is an estimate of total job time
> (so that we
I was thinking something like that, but actually it's right the way it is;
frac_est is an estimate time remaining,
and wu_est is an estimate of total job time
(so that we need to multiply it by fraction_left
to make it into an estimate of time remaining).
-- DPA
James Wanless wrote:
> should that
Cancel previous msg - I don't see a bug after all.
If anyone wants to clarify or otherwise decrease the stupidity
of the code, feel free.
-- DPA
Nicolás Alvarez wrote:
> El Martes 07 Jul 2009 14:27:26 David Anderson escribió:
>> The weighting is actually quadratic; i.e., when the job is half done
should that penultimate line be just:
"double x = fd_weight*frac_est + wu_weight*wu_est;"
?
J
On 7 Jul 2009, at 18:27, David Anderson wrote:
> The weighting is actually quadratic; i.e., when the job is half done
> the estimate is 75% from the dynamic and 25% from the static.
>
> However, I think
El Martes 07 Jul 2009 14:27:26 David Anderson escribió:
> The weighting is actually quadratic; i.e., when the job is half done
> the estimate is 75% from the dynamic and 25% from the static.
>
> However, I think I see a serious bug in the code (see below).
> Anyone else see it?
Last time I looked
The weighting is actually quadratic; i.e., when the job is half done
the estimate is 75% from the dynamic and 25% from the static.
However, I think I see a serious bug in the code (see below).
Anyone else see it?
-- David
// Returns the estimated CPU time to completion (in seconds) of this task.
The only mechanism for changing it is to modify the duration correction
factor. The duration correction factor will correct itself over time
anyway, but it is possible to set it by hand to be closer to where it will
eventually stabilize.
Because some of the tasks are not linear in behavior, the r
On Jul 5, 2009, at 8:47 PM, David Anderson wrote:
> Should we add a "clear" button to the Messages tab?
Duh!
Of course ...
On the other hand, better not, this will lead some participants to
micromanage the content of the messages tab ... so perhaps we should
not do anything so radical that
Is it possible to edit the time to comletion? Right now I have an ABC unit
where the TTC goes down 1 second per 3 seconds. You could just calculate how
many second it takes to go down 1 minute, and divide the total time left by
that divided by 60, or add one hour if it goes up, and try again.
10 matches
Mail list logo
