Well put, you two. Exactly the same point I was trying to make, only to get accused of spouting "baloney".
---bb On Fri, Aug 2, 2013 at 10:44 AM, Peter Alexander < [email protected]> wrote: > On Friday, 2 August 2013 at 17:16:30 UTC, Andrei Alexandrescu wrote: > >> On 2013-08-02 15:44:13 +0000, Leandro Lucarella said: >> >>> I'm not say is right or wrong for people to have this reflex of thinking >>> about multipliers, I'm just saying if you care about transmitting the >>> message as clear as you can, is better to use numbers everybody can >>> intuitively think about. >>> >>> And this is in reply to Andrei too. I understand your POV, but if your >>> main goal is communication (instead of education about side topics), >>> I think is better to stick with numbers and language that minimizes >>> confusion and misinterpretations. >>> >>> Just a humble opinion of yours truly. >>> >> >> >> Fair enough. So what would have been a better way to convey the >> quantitative improvement? >> > > Not to speak on Leandro's behalf, but I think the obvious answer is > "Reduced compile times by 43%". > > It's much more useful to express it that way because it's easier to apply. > Say I have a program that takes 100 seconds to compile. Knowing that the > compilation time is reduced by 43% makes it easy to see that my program > will now take 57 seconds. Knowing that compilation is 75% faster doesn't > help much at all - I have to get out a calculator and divide by 1.75. > > It's always better to use a measure that is linear with what you care > about. Here, most people care about how long their programs take to > compile, not how many programs they can compile per second. >
