On Monday, 29 July 2013 at 10:15:31 UTC, JS wrote:
On Thursday, 25 July 2013 at 21:27:47 UTC, Walter Bright wrote:
On 7/25/2013 11:49 AM, Dmitry S wrote:
I am also confused by the numbers. What I see at the end of
the article is
"21.56 seconds, and the latest development version does it in
12.19", which is
really a 43% improvement. (Which is really great too.)
21.56/12.19 is 1.77, i.e. a >75% improvement in speed.
A reduction in time would be the reciprocal of that.
Actually, it is a 43% speed improvement. 0.43*21.56 = 9.27s
So if it is 43% faster, it means it's reduced the time by 9.27s
or, 21.56 - 9.27 = 12.28 seconds total.
Now, if we started at 12.28 seconds and it jumped to 21.56 then
it would be 21.56/12.19 = 1.77 ==> 77% longer.
21.56/12.19 != 12.19/21.56.
The order matters.
To make it obvious. Suppose the running time is 20 seconds. You
optimize it, it is 100% **faster**(= 1.0*20 = 20s seconds),
then it takes 0 seconds(20 - 20).
That is how you fail a physics class.
s = d/t => t = d/s
100% increase in s = 2*s
let s_new = 2*s
t_new = d / s_new
let d = 1 program (s is measured in programs / unit time_
therefore: t_new = 1 / s_new = 1 / (2 * s) = 0.5 * 1/s
= 0.5 * t
Seriously... Walter wouldn't have got his mechanical engineering
degree if he didn't know how to calculate a speed properly.
