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.

Reply via email to