Profilo di BenNo Brain, No PainFotoBlogElenchiAltro Strumenti Guida

Blog


28 luglio

Better gas mileage with a clean air filter, right? Read on...

"Install a new air filter to maximize your gas mileage!!!"  I swear I hear that at least a couple of times a week these days.  It's on YouTube.  Auto parts stores suggest it.  Even the government advise you to do it.
 
But it turns out, they're completely misguided.
 
I can almost hear you thinking, "The hell you say?!?!?!  Of course a clean air filter will help with fuel economy, since it's obvious an engine would have to work harder to draw air through a dirty filter as compared to a clean filter."
 
Now, there was a time when a new air filter would improve fuel economy.  Back in the days of non-feedback carburetors, the amount of gas metered into an engine was dependent on the absolute pressure differential between the carburetor venturi and atmospheric pressure.  Anything that would lower the pressure in the venturis--the most obvious example being the choke on top of the carburetor--would case the air fuel mix to go rich very quickly.  And a dirty air filter acted identical to a partially closed choke.  I don't think it would be unreasonable to see an MPG decrease of 10-20% with a dirty air filter.
 
But that was a loooong time ago; the last open-loop carburetor car I drove was a 1979 Trans Am.  Since the 80's fuel systems have gone to closed-loop, which simply means they continually sample the exhaust gas in order to calculate how much fuel to inject into the engine.  The pressure of the air upstream of the throttle no longer affects the amount of fuel metered into the engine.
 
Ah yes, the throttle--that's the part people always forget about when they're trying to envision their engine struggling to pull air through the dirty air filter.  Because if you think it's hard to pull air through a dirty piece of paper, imagine how tough it is to pull air through a solid plate of metal!  And the vast majority of the time you're driving down the road, the throttle plates are just partially open--that is what's limiting the amount of air entering the engine, not the dirty air filter.
 
It turns out it doesn't matter where in the intake tract the restriction happens--throttle, dirty air filter, a narrow piece of intake tubing--they all have an identical effect.  Basically, as your air filter gets dirtier, you'll compensate by opening the throttle more.  But since the amount of gas metered into an engine is determined by the exhaust, you'll still end up with exactly the same engine power output and identical fuel consumption.  Nifty, eh?
 
Actually, I'd contend that the dirtier your air cleaner gets, your fuel economy will improve!  Crazy?  Well, a dirty air filter has the same effect as a throttle that doesn't fully open.  Think about this:  would you get better mileage if you drove around full-throttle all the time?  Or if you never opened your throttle more than halfway?  This actually explains why people say devices like "the Tornado" improve gas mileage.  It's not about swirling the air entering the engine, it's about putting a restriction in the intake tract that effectively prevents the driver from going full throttle.
 
So, is there any downside to a dirty air filter?
 
Just one that I can think of:  it absolutely, undoubtably reduces full-throttle power.
 
Anyway, something to think about next time someone tells you that you should change your air filter to maximize your fuel economy.
02 luglio

Software entropy, revisited

Dreaming in Code had a great story about Apple's legendary Bill Atkinson and using lines of code (LOC) as a productivity metric.  In summary:  Bill rewrote a section of the Quickdraw code to be faster and more efficient, but in the rewriting process he reduced the total lines of code by 2,000.  So, when he filled out his weekly management form, he entered -2000 as the number of lines of code written.  So much for using LOCs to measure productivity!
 
Obviously Bill's new version was better than his old version.  But how do you quantify that objectively?  LOCs certainly doesn't work, but as I continued to think about the problem, I kept returning to the concept of software entropy as a potential solution.  So here's some continuations on my original thoughts; the concept still isn't fully flushed out yet, but I think I'm making some progress.  Consider this:
1) The entropy of a function is determined by how predictable the output of the function is, based on its inputs.  In other words, I think we can we can take the basic concepts of statistical thermodynamics and apply it to software.
 
2) Every function can be assigned an entropy value between zero and one.  The following is a zero-entropy function (as it doesn't change the input parameters at all):
int func0(int x)
{
     return x;
}
Conversely, the following function has an entropy of one (output is completely independent of the input):
int func1(int x)
{
     return rand();
}
(Actually, this function would have an entropy slightly less than 1.0, since any software random number generator isn't completely random, but... you get the basic gist.  In any case, the point is I'm assigning arbitrary values to define a range of possible entropy values)
Now, here comes the heavier stuff:
3) Any two functions which have identical return values for identical inputs, have the same entropy.
In other words, if two functions generate identical output for identical inputs, either could be used by a calling program with no change in functionality.  Seems intuitive, no?
4) The entropy of a function is not equal to the sum of the entropy of each line that comprises the function.
 
Proof:
 
By #2, the following function has zero entropy:
int func0(int x)
{
     return x;
}
Conversely, these functions have positive, non-zero (albeit small), entropy:
int func1(int x)
{
    return x + 1;
}

int func2(int x)
{
     return x - 1;
}
Now, consider the following function:
int func3(int x)
{
     int y = func1(x);
     return func2(y);
}

By #3 the func3() has the same entropy as func0(), since the output of both functions is identical (they both return the original value passed to the function).  Thus the entropy of func3() is zero, even though the lines the comprise the function have positive entropy.

Given all of these, I propose the following statement:

5) The efficiency of a function is the entropy of the function, divided by the sum of entropy of each statement that make up the function.

Therefore, func0() is more efficient that func3(), even though equivalent, entropy-wise.
 
I think that if you were to apply these principals to Atkinson's revised code, you'd find the efficiency of his new functions objectively higher than that of the original ones.
 
Certainly, there's still a lot of work to be done--namely, I still need to figure out how to calculate absolute entropy values for an arbitrary function or statement.  But I think I'm heading in the right direction.
 
Ben