On 7/30/13 2:59 AM, Leandro Lucarella wrote:
I just want to point out that being so much people getting this wrong
(and even fighting to convince other people that the wrong
interpretation is right) might be an indication that the message you
wanted to give in that blog is not extremely clear :)
That was my whole point. If you used some easier measure to understand
(like using time instead of speed) you could have avoided all this
I tend to disagree on this, and I think the title of the article is good
as is (I've reviewed it).
I'd say if a programmer doesn't have a clear notion of what speed is and
how comparisons go etc., they better learn it pronto. There's nothing
complicated here, and if something is not obvious to some readers this
is even better because the article serves as an educational tool in more
ways than one.
Speed involves time at the denominator, i.e. seconds come "to the power
of -1". I don't think it's fair to negotiate whether this is expected.
Every engineer must know this.
Percentage changes go as follows. If you "increase something by 100%" it
means you doubled it. If you "decrease something by 50%" it means you
halved it. Everything else can be easily derived from these. Again, I
consider this non-negotiable background knowledge.