On Monday, 29 July 2013 at 12:28:16 UTC, John Colvin wrote:

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 ofthe article is"21.56 seconds, and the latest development version does itin 12.19", which isreally 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.27sSo if it is 43% faster, it means it's reduced the time by9.27s or, 21.56 - 9.27 = 12.28 seconds total.Now, if we started at 12.28 seconds and it jumped to 21.56then 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 = 20sseconds), 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 * tSeriously... Walter wouldn't have got his mechanicalengineering degree if he didn't know how to calculate a speedproperly.

`I'm sorry but a percentage is not related to distance, speed, or`

`time.`

`A percentage if a relative quantity that depends on a base for`

`reference. Speed, time, nor distance are relative.`

let d = 1 program (s is measured in programs / unit time_

which is nonsense... programs / unit time?

`Trying to use distance and speed as a measure of performance of a`

`program is just ridiculous. The only thing that has any meaning`

`is the execution time and the way to compare them is taking the`

`ratio of the old to new. Which gives a percentage change. If the`

`change > 1 then it is an increase, if < 1 then it is a decrease.`

Btw, it should be t_new = d_new/s_new

`and the proper way to calculate a percentage change in time would`

`be`

`t_new/t_old = d_new/s_new*s_old/d_old = d_new/d_old /`

`(s_new/s_old)`

`If we assume the distance is constant, say it is the "distance"`

`the program must travel from start to finish, then d_new = d_old`

`and`

t_new/t_old = s_old/s_new or

`p = t_new/t_old = s_old/s_new is the percentage change of the`

`program.`

`Note that speed is the reciprocal of the time side, if you`

`interpret it wrong for the program(it's not time) then you'll get`

`the wrong answer).`

21.56/12.19 = 1.77 ==> 77% (if you dump the 1 for some reason) 12.19/21.56 = 0.56 ==> 56% but only one is right... Again, it should be obvious:

`Starting at 21.56, let's round that to 20s. Ended at 12.19s,`

`let's round that to 10s. 10 seconds is half of 20s, not 75%(or`

`25%). Note how close 50% is to 56% with how close the rounding`

`is. It's no coincidence...`

`It seems some people have to go back to kindergarten and study`

`percentages!`

`(again, if we started with 12 second and went to 21 seconds, it`

`would be a near 75% increase. But a 75% increase is not a 75%`

`decrease!!!!!!!!)`

`Please study up on basic math before building any bridges. I know`

`computers have made everyone dumb....`